# Reported issues for reference-data-mcp-server

Pod holds 21 of 39 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.

Back to [reference-data-mcp-server](/mcp/reference-data-mcp-server).

## Most discussed

### feat(responses): surface match_strategy in ref_constant_lookup and fuzzy-match notice in ref_geo_lookup

Two lookup tools perform fuzzy matching but return results with no indication of how the match was made. An agent that queried "Planck" and received the Planck constant (h) can't tell whether the service matched exactly on the symbol or picked h from among multiple fuzzy candidates that also matched. Similarly, an agent querying "brasil" (misspelled) and receiving Brazil's full record has no signal that the match was fuzzy — it cannot tell whether to normalize the canonical name in follow-up cal

[Read the thread](https://github.com/cyanheads/reference-data-mcp-server/issues/27) · 2026-05-29 · closed · 2 comments

### bug(ref_unit_convert): "mph" and "BTU" in parameter describe and error recovery are unrecognized units

### Server version

0.1.6

### mcp-ts-core version

0.9.13

### Runtime

Bun

### Runtime version

Bun 1.3.x

### Transport

stdio

### Description

The \`ref_unit_convert\` tool contains three locations where \`mph\` and/or \`BTU\` are given as example unit abbreviations, but neither is recognized by the underlying \`convert-units@2.3.4\` library. Calling the tool with these inputs returns \`unknown_unit\` errors, directly contradicting the documentation that offers them as examples.

Issue #12

[Read the thread](https://github.com/cyanheads/reference-data-mcp-server/issues/25) · 2026-05-29 · closed · 2 comments

### bug(ref_http_status): float query (e.g., "404.5") silently truncates to integer via parseInt

### Server version

0.1.2

### mcp-ts-core version

0.9.9

### Runtime

Bun

### Runtime version

Bun 1.3.11

### Transport

HTTP (Streamable HTTP)

### OS

macOS 25.1.0

### Description

`ref_http_status` silently returns a valid result when given a float query like `"404.5"` or `"503.5"`. `parseInt("404.5", 10)` returns `404`, so the service finds and returns the `404` record — as if the input was the valid code `404`. A float is not a valid HTTP status code; the tool should return not-found r

[Read the thread](https://github.com/cyanheads/reference-data-mcp-server/issues/24) · 2026-05-25 · closed · 2 comments

### bug(ref_mime_type): MIME type query with parameters (e.g., text/plain; charset=utf-8) returns not-found instead of stripping parameters

### Server version

0.1.2

### mcp-ts-core version

0.9.9

### Runtime

Bun

### Runtime version

Bun 1.3.11

### Transport

HTTP (Streamable HTTP)

### OS

macOS 25.1.0

### Description

`ref_mime_type` fails with a not-found error when the query includes MIME type parameters (the `;` suffix common in HTTP `Content-Type` headers). Agents frequently encounter full content-type strings like `text/plain; charset=utf-8` or `application/json; charset=utf-8` and pass them directly as the query — the 

[Read the thread](https://github.com/cyanheads/reference-data-mcp-server/issues/23) · 2026-05-25 · closed · 2 comments

### bug(ref_unit_convert): below_absolute_zero error misrepresents the Kelvin equivalent as absolute zero

### Server version

0.1.2

### mcp-ts-core version

0.9.9

### Runtime

Bun

### Runtime version

Bun 1.3.11

### Transport

HTTP (Streamable HTTP)

### Description

The `below_absolute_zero` error message is misleading. The parenthetical `(≈ -26.85 K)` reads as "absolute zero is approximately -26.85 K", when it is actually meant to convey "your input temperature in Kelvin is -26.85 K". This is factually wrong to a reader parsing the message quickly.

A secondary issue: `-459.67 F` (which equals

[Read the thread](https://github.com/cyanheads/reference-data-mcp-server/issues/22) · 2026-05-25 · closed · 2 comments

### bug(ref_element_lookup): elements known since antiquity render 'Ancient by Ancient' in format output

### Server version

0.1.2

### mcp-ts-core version

0.9.9

### Runtime

Bun

### Runtime version

Bun 1.3.11

### Transport

HTTP (Streamable HTTP)

### Description

When looking up elements known since antiquity (Carbon, Iron, Copper, Gold, etc.), the `content[]` formatted text shows "**Discovered:** Ancient by Ancient". This happens because both `discovery_year` (null → fallback "Ancient") and `discovery_scientists` (value "Ancient") both render to "Ancient", producing a nonsensical compound p

[Read the thread](https://github.com/cyanheads/reference-data-mcp-server/issues/21) · 2026-05-25 · closed · 2 comments

### bug(ref_element_search): category filter uses substring match, causing 'transition metal' to return post-transition metals

### Server version

0.1.2

### mcp-ts-core version

0.9.9

### Runtime

Bun

### Runtime version

Bun 1.3.11

### Transport

HTTP (Streamable HTTP)

### Description

`ref_element_search` with `category: "transition metal"` returns 50 elements — 34 actual transition metals plus 16 post-transition metals. The category filter uses `String.includes()` (substring match), so "transition metal" matches "post-transition metal". This creates incorrect results when users provide exact category names from 

[Read the thread](https://github.com/cyanheads/reference-data-mcp-server/issues/20) · 2026-05-25 · closed · 2 comments

### bug(ref://timezones): unencoded slash in URI returns generic framework error with no encoding guidance

### Server version

0.1.2

### mcp-ts-core version

0.9.9

### Runtime

Bun

### Runtime version

Bun 1.3.11

### Transport

HTTP (Streamable HTTP)

### Description

Reading `ref://timezones/America/New_York` (with an unencoded slash) returns a generic framework-level "Resource not found" error with code `-32602` and no actionable guidance. The resource description says to use `%2F` encoding, but a client that gets this error has no way to understand what went wrong — the error message doesn't m

[Read the thread](https://github.com/cyanheads/reference-data-mcp-server/issues/19) · 2026-05-25 · closed · 2 comments

## Most recent

### feat(ref_unit_convert): accept "mph"/"kph" aliases and document the mile-per-hour unit

`ref_unit_convert` cannot convert miles per hour as documented. The description's speed set is "m/s, km/h, knot, ft/s" — omitting mile-per-hour entirely — while the underlying [convert-units](https://github.com/convert-units/convert-units) library does support it under the abbreviation `m/h`. So `"mph"` is rejected (`Unrecognized unit "mph". Use plain abbreviations: "C" … "km", "kg", "kWh", "Pa"` — no speed unit among the examples), and the working spelling `m/h` appears only as an incidental ex

[Read the thread](https://github.com/cyanheads/reference-data-mcp-server/issues/40) · 2026-08-21 · open · 0 comments

### docs(README): ref_constant_lookup entry count overstated as "~360"

Two README lines describe the CODATA 2022 physical constants dataset as "~360 entries" — \`src/data/physical-constants.ts\` currently defines 32 (\`constants.length === 32\`), roughly a 10x overstatement.

### Location

- Line 110: "Look up CODATA 2022 physical constants (~360 entries)."
- Line 175: "constants (CODATA 2022, ~360 entries)"

### Expected

Correct the count to the actual dataset size, or if ~360 is meant to describe the full CODATA 2022 standard (this dataset's header comment says 

[Read the thread](https://github.com/cyanheads/reference-data-mcp-server/issues/39) · 2026-07-17 · closed · 1 comment

### bug(ref_constant_lookup): name queries report match_strategy "exact_symbol" instead of "exact_name"

`ref_constant_lookup` returns `match_strategy: "exact_symbol"` for queries that are full constant **names**, when it should return `"exact_name"`. The looked-up constant is correct — only the reported match provenance is wrong.

### Reproduction
`{ query: "Rydberg constant" }` →

```json
{ "name": "Rydberg constant", "symbol": "R∞", "value": 10973731.568157, "match_strategy": "exact_symbol", ... }
```

Expected `match_strategy: "exact_name"` — the query is the exact name, not the symbol `R∞`.

T

[Read the thread](https://github.com/cyanheads/reference-data-mcp-server/issues/38) · 2026-07-17 · closed · 1 comment

### bug(ref_timezone_convert): DST spring-forward gap datetimes convert to a non-invertible result

Related: #11, #32

### Server version

0.1.12

### mcp-ts-core version

0.10.9

### Runtime

Bun

### Runtime version

1.3.x

### Transport

stdio

### OS

macOS

### Description

`ref_timezone_convert` silently accepts local datetimes that fall in a DST "spring-forward" gap — a wall-clock moment that never physically occurs because the clock jumps forward (e.g., 02:00 → 03:00 in `America/New_York` on 2026-03-08). `TimezoneService.convert()`'s two-step offset refinement (added for #11) picks an 

[Read the thread](https://github.com/cyanheads/reference-data-mcp-server/issues/37) · 2026-07-17 · closed · 1 comment

### bug(ref_constant_lookup): related[] returns near-identical lists for "constant"-suffixed entries via generic-word token collision

Related: #33

### Server version

0.1.12

### mcp-ts-core version

0.10.14

### Runtime

Bun

### Runtime version

1.3.x

### Transport

stdio

### OS

macOS

### Description

`ConstantsService.findRelated()` (rewritten in #33 to use whole-token name matching) still produces near-arbitrary `related[]` results for any constant whose name contains the literal word "constant" — 14 of the dataset's 32 entries. Because "constant" is a length-8, non-stopword token shared across all 14, any two of them

[Read the thread](https://github.com/cyanheads/reference-data-mcp-server/issues/36) · 2026-07-17 · closed · 1 comment

### enhancement(ref_unit_convert): disambiguate "t" (US short ton) vs "mt" (metric tonne) in description

### Use case

`ref_unit_convert`'s description lists mass units as "mcg, mg, g, kg, oz, lb, mt, t" with no gloss. In [convert-units](https://github.com/convert-units/convert-units), `mt` = metric tonne (1000 kg) and `t` = US short ton (907.18 kg). Since `t` is the common symbol for "tonne" internationally, an agent converting `1 t` expecting 1000 kg silently gets 907 kg.

```
ref_unit_convert { "value": 1, "from": "t",  "to": "kg" } → 907.18
ref_unit_convert { "value": 1, "from": "mt", "to": "kg

[Read the thread](https://github.com/cyanheads/reference-data-mcp-server/issues/35) · 2026-06-30 · closed · 1 comment

### enhancement(ref_element_lookup): accept international/IUPAC spellings (Aluminium, Caesium, Sulphur)

### Use case

`ref_element_lookup` resolves American spellings only. The element dataset (`src/data/periodic-table.ts`) stores `Aluminum`, `Cesium`, `Sulfur`, and the name fuzzy-fallback is `storedName.startsWith(query)`, which can't bridge a spelling difference. So the IUPAC-preferred spellings **Aluminium** and **Caesium**, and British **Sulphur**, all fail:

```
ref_element_lookup { "query": "Aluminium" } → No element matched "Aluminium". ... check the IUPAC name or symbol spelling.
ref_eleme

[Read the thread](https://github.com/cyanheads/reference-data-mcp-server/issues/34) · 2026-06-30 · closed · 1 comment

### bug(ref_constant_lookup): related[] returns unrelated constants via single-letter substring match

### Server version

0.1.12

### mcp-ts-core version

0.10.9

### Runtime

Bun

### Runtime version

1.3.x

### Transport

stdio

### OS

macOS

### Description

Related: #14

`ref_constant_lookup` returns semantically-unrelated constants in `related[]`. `ConstantsService.findRelated()` scores relatedness with `allTerms.some((t) => t.includes(term) || term.includes(t))` over each constant's name, symbol, and aliases. Single-letter symbols (`e`, `g`) and 2-char aliases (`me`) match as substrings o

[Read the thread](https://github.com/cyanheads/reference-data-mcp-server/issues/33) · 2026-06-30 · closed · 1 comment

### bug(ref_timezone_convert): out-of-range datetimes (e.g. 2026-02-30) silently roll over

### Server version

0.1.12

### mcp-ts-core version

0.10.9

### Runtime

Bun

### Runtime version

1.3.x

### Transport

stdio

### OS

macOS

### Description

`ref_timezone_convert` validates the datetime *format* with a regex (`/^\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}$/`) but not the component *ranges*. Impossible dates pass validation, then `Date.UTC()` in `timezone-service.convert()` normalizes the overflow — so the tool silently returns a result for a different date than the one requested, in

[Read the thread](https://github.com/cyanheads/reference-data-mcp-server/issues/32) · 2026-06-30 · closed · 1 comment

### bug(ref_constant_lookup): molar volume value is the 1 atm figure but labeled "100 kPa"

### Server version

0.1.12

### mcp-ts-core version

0.10.9

### Runtime

Bun

### Runtime version

1.3.x

### Transport

stdio

### OS

macOS

### Description

The `molar volume of ideal gas (STP)` constant in `src/data/physical-constants.ts` has an internally inconsistent value/label. Value is `0.022413996 m³ mol⁻¹`, but `description` and `uncertainty_relative` both state STP = "0 °C, 100 kPa". `0.0224140` is the molar volume at **1 atm (101.325 kPa)**, not at 100 kPa.

Ideal gas law, `V = RT/

[Read the thread](https://github.com/cyanheads/reference-data-mcp-server/issues/31) · 2026-06-30 · closed · 1 comment

### bug(ref_geo_lookup): United Kingdom returns tld ".gb" instead of ".uk"

### Server version

0.1.12

### mcp-ts-core version

0.10.9

### Runtime

Bun

### Runtime version

1.3.x

### Transport

stdio

### OS

macOS

### Description

`ref_geo_lookup` returns the wrong country-code TLD for the United Kingdom. `src/services/geo/geo-service.ts` synthesizes the TLD from the alpha-2 code: `tld: \`.${alpha2.toLowerCase()}\``. That assumes a country's ccTLD always equals its ISO alpha-2 code, which is false for the UK — alpha-2 `GB`, ccTLD `.uk`. The tool returns `.gb` (an 

[Read the thread](https://github.com/cyanheads/reference-data-mcp-server/issues/30) · 2026-06-30 · closed · 1 comment

### bug(ref_http_status): cacheable flag wrong for 204, 405, 304 vs RFC 9110 §15.1

### Server version

0.1.12

### mcp-ts-core version

0.10.9

### Runtime

Bun

### Runtime version

1.3.x

### Transport

stdio

### OS

macOS

### Description

`ref_http_status` exposes a `cacheable` field documented as "whether the code is cacheable by default" — i.e. the *heuristically cacheable* set defined in [RFC 9110 §15.1](https://www.rfc-editor.org/rfc/rfc9110#section-15.1). The data in `src/data/http-status-codes.ts` deviates from that set on three codes.

RFC 9110 §15.1 heuristically-

[Read the thread](https://github.com/cyanheads/reference-data-mcp-server/issues/29) · 2026-06-30 · closed · 1 comment

### feat(unicode): add ref_unicode_lookup for codepoint + invisible-character reference

### Use case

`reference-data` covers developer-reference lookups (HTTP status, MIME types, elements, constants) but nothing for Unicode characters. The highest-value gap is **identifying invisible and confusable characters** — a zero-width space, non-breaking space, bidi control, or a homoglyph hiding in a string — a recurring debugging pain (broken parsers, failed string comparisons, spoofed identifiers) with no offline tool to resolve it. Basic codepoint metadata (name, category, block, scrip

[Read the thread](https://github.com/cyanheads/reference-data-mcp-server/issues/28) · 2026-06-28 · open · 0 comments

The remaining reports are on [the project's issue tracker](https://github.com/cyanheads/reference-data-mcp-server.git/issues).