What happened?

Opening an MCP server's settings page in the LiteLLM UI throws an uncaught TypeError and the page fails to render:

Uncaught TypeError: e.default_cost_per_query.toFixed is not a function

The trigger is a reasonable-looking config.yaml value — default_cost_per_query: 7e-05 — that PyYAML (correctly) parses as a string, not a float. LiteLLM never validates or coerces the value on the way in, persists it through the stack as a string, and the UI crashes when it tries to format it.

Minimal repro config.yaml:

mcp_servers:
  google_maps:
    url: 'https://mapstools.googleapis.com/mcp'
    transport: 'http'
    mcp_info:
      mcp_server_cost_info:
        default_cost_per_query: 7e-05   # parsed as STRING by PyYAML (YAML 1.1)

Independent confirmation that the YAML value is a string, not a float:

>>> import yaml
>>> yaml.safe_load("x: 7e-05")    # {'x': '7e-05'}   <-- str, crashes UI
>>> yaml.safe_load("x: 7.0e-05")  # {'x': 7e-05}     <-- float, works
>>> yaml.safe_load("x: 1e-5")     # {'x': '1e-5'}    <-- str, crashes UI
>>> yaml.safe_load("x: 0.00007")  # {'x': 7e-05}     <-- float, works

Why PyYAML is not the bug

PyYAML is a YAML 1.1 parser, and YAML 1.1's float schema explicitly requires a decimal point in the mantissa — so 7e-5, 7e-05, 1e-5, 7E-05 all correctly resolve to strings under that spec. YAML 1.2 relaxed this, but PyYAML has never adopted 1.2 and that is a documented, deliberate upstream position, not a defect. The YAML parser is behaving as specified.

Why this is a LiteLLM bug

LiteLLM has four boundaries at which it could catch a non-numeric value being used where a float is required, and enforces none of them:

1. Type declaration. MCPServerCostInfo is a TypedDict (litellm/types/mcp.py:121) — zero runtime validation. The annotation default_cost_per_query: Optional[float] is documentation only.
2. Config loader. MCPServerManager.load_servers_from_config (litellm/proxy/_experimental/mcp_server/mcp_server_manager.py:204) copies mcp_info through to the in-memory server with no shape checking on cost fields.
3. Persistence. _prepare_mcp_server_data (litellm/proxy/_experimental/mcp_server/db.py:30) calls safe_dumps(data.mcp_info) on whatever it's handed and writes it to the mcp_info JSONB column verbatim. A stringified "7e-05" round-trips through the DB unchanged.
4. UI render. ui/litellm-dashboard/src/components/mcp_tools/mcp_server_cost_display.tsx (lines 38 and 67) and mcp_server_cost_config.tsx (lines 140 and 149) call .toFixed(4) directly on default_cost_per_query, and line 52 does the same for each value in tool_name_to_cost_per_query. The TypeScript type is number | null, but that is a compile-time promise — at runtime the value is whatever the server returned.

Any single one of those being enforced would have turned this into a clear config error or a non-issue. Since none are, a user who writes 7e-05 in their YAML ends up with an unopenable settings page and no signal about what's wrong.

Expected behavior

Either (a) the config loader rejects a non-numeric default_cost_per_query at startup with a clear message pointing at the YAML line and suggesting the fix, or (b) the value is coerced to float at ingest and the UI can trust it. The settings page must not be rendered unopenable by a round-trip-valid config value.

Suggested fix (defense in depth, backend-first)

1. Primary — promote MCPServerCostInfo from TypedDict to a Pydantic BaseModel in litellm/types/mcp.py, with default_cost_per_query: Optional[float] and tool_name_to_cost_per_query: Optional[Dict[str, float]]. Pydantic will coerce stringified floats ("7e-05" → 7e-05) automatically and reject genuinely non-numeric input. This covers both config-file and API-call ingest paths.
2. Belt-and-suspenders in config load — in load_servers_from_config, validate/coerce mcp_info.mcp_server_cost_info via that model and emit a clear startup error pointing at the offending server name if coercion fails. The YAML scientific-notation footgun deserves an explicit hint (e.g. "YAML 1.1 requires a decimal point in scientific notation; write 7.0e-5 instead of 7e-5").
3. UI, defensive — in mcp_server_cost_display.tsx and mcp_server_cost_config.tsx, use a toFiniteNumber(v: unknown): number | null helper to coerce before .toFixed(4), applied to default_cost_per_query and each entry in tool_name_to_cost_per_query. This keeps the settings page openable for users with pre-existing bad data in the DB.
4. Docs — a one-liner in the MCP cost-tracking docs mentioning the YAML 1.1 scientific-notation rule would save a lot of future confusion.

Steps to Reproduce

1. Put the minimal repro config above in config.yaml and start the proxy.
2. Open the UI → MCP Servers → click the google_maps server.
3. Page does not render; browser console shows Uncaught TypeError: e.default_cost_per_query.toFixed is not a function.

Relevant log output

Uncaught TypeError: e.default_cost_per_query.toFixed is not a function
    at mcp_server_cost_display.tsx:38

What part of LiteLLM is this about?

Proxy (config parsing / type validation) and UI Dashboard

What LiteLLM version are you on?

v1.83.14

Also verified present at tip of the following upstream branches (files unchanged since PR #12526 + prettier reformat; mcp_server_cost_display.tsx MD5 d5bd7800500a31e22ea75c785f3cf0c6, mcp_server_cost_config.tsx MD5 e1ecdaf379a9ef6560d6ef6415a3718d on all of them):

• main @ 934ecdca78
• litellm_internal_staging @ c011a7e3ba
• litellm_oss_staging @ 50ef2d51a2
• litellm_thursday_release_staging @ 6956c76d02
• litellm_oss_staging_06_06_2026 @ 7a9a9f0c79