A tool returning a non-finite float fails on the client with an error naming the tool

[jayhemnani9910]

Initial Checks

• I confirm that I'm using the newest release of my line (verified on 2.0.0)
• I confirm that I searched for my issue before opening this issue

Release line

2.x (current stable). Also reproduces on 1.29.0.

Bug description

A tool returning a non-finite float fails on the client with an error that names
the tool. float("inf"), float("-inf") and float("nan") all reproduce it. A
finite float is fine.

The handler returned an ordinary Python float. The value that fails validation is
produced by the SDK's own outbound serialization.

Steps to reproduce

import anyio
from mcp.client import Client
from mcp.server.mcpserver import MCPServer

server = MCPServer("probe")


@server.tool()
def ratio(a: float, b: float) -> float:
    """Divide a by b."""
    return a / b if b else float("inf")


async def main() -> None:
    async with Client(server) as client:
        print(await client.call_tool("ratio", {"a": 1.0, "b": 2.0}))
        print(await client.call_tool("ratio", {"a": 1.0, "b": 0.0}))


anyio.run(main)

Actual behaviour

The first call returns structured_content={'result': 0.5}. The second raises:

RuntimeError: Invalid structured content returned by tool ratio: None is not of type 'number'

Failed validating 'type' in schema['properties']['result']:
    {'title': 'Result', 'type': 'number'}

On instance['result']:
    None

Uncaught, this arrives as two nested ExceptionGroups out of Client.__aexit__,
84 lines in total, with the line naming the tool last. Catching the RuntimeError
leaves the session usable and later calls succeed.

The value cannot be recovered. validate_tool_result runs unconditionally for any
non-error result (client/session.py:1109, client/client.py:828) with no opt-out,
so the caller never reaches the CallToolResult to read either
structured_content or the text block.

Expected behaviour

Either the value survives the round trip, or the failure names the real cause. At
present the message directs the reader to the handler, which is the one component
behaving correctly.

The SDK already rejects non-finite floats explicitly elsewhere, at
server/request_state.py:128, so refusing them at the point of return with a clear
message would match existing practice.

Root cause

1. func_metadata.convert_result builds structured_content = {'result': inf}.
   Correct so far.
2. _dump_result (server/runner.py:118) serializes with
   model_dump(by_alias=True, mode="json", exclude_none=True). Pydantic's JSON mode
   writes non-finite floats as null, since JSON has no Infinity or NaN and
   ser_json_inf_nan defaults to "null". The SDK does not set that setting
   anywhere.
3. The client validates {"result": null} against the generated output schema
   {"result": {"type": "number"}}, which rejects it.
4. client/session.py:1155 raises, interpolating the tool name.

This is server-side and independent of transport, so it is not specific to the
in-memory client used above.

The emitted JSON stays valid, so this is not an interoperability problem. The
problem is that the value is dropped silently and the diagnostic points at the
wrong component.

Non-finite floats arise from ordinary arithmetic, including division by zero,
overflow, statistics on degenerate input, and numpy interop, so a handler can
produce one without ever writing float("inf").

Why the tests do not catch it

No test returns a non-finite float from a tool. math.inf appears in the suite
only as an unbounded stream buffer size (tests/client/test_stdio.py:149,
tests/interaction/transports/_bridge.py:120) and as a rejected TTL input
(tests/server/test_request_state.py:355). The one -> float division helper,
tests/server/mcpserver/test_tool_manager.py:838, is marked # pragma: no cover.

Not a duplicate of #3100 or PR #3118

#3100 reports the same end state, an output schema that rejects the SDK's own
structured result, but its cause is validation and serialization shapes differing
on aliases and computed fields. This reproduces with a plain -> float return and
no Pydantic model.

PR #3118 moves output schema generation into serialization mode. That does not
change this case: a float serializes as number either way, so null still
fails the schema.

#3224 is also distinct. It concerns nulls injected for absent NotRequired
TypedDict keys, not values destroyed by JSON serialization.

Python & MCP Python SDK

Python 3.13.11
mcp 2.0.0            (also reproduced on main @ 0d921927 and on mcp 1.29.0)
pydantic 2.12.5
Linux x86_64

---

AI assistance was used to investigate and draft this report.

[anneheartrecord]

The null comes from a second model_dump(mode="json"), not the first. Worth pinning down because it moves where a fix goes.

Reproduced on 0d92192 (the SHA in the report), Python 3.13.11 / pydantic 2.12.5.

In dict mode, pydantic treats a non-finite float differently depending on the field's declared type:

class Declared(BaseModel): v: float
class AnyField(BaseModel): v: Any

Declared(v=inf).model_dump(mode="json")   # {'v': inf}   survives
AnyField(v=inf).model_dump(mode="json")   # {'v': None}  nulled

A declared float keeps the Python object; an Any-typed field is routed through the JSON-value serializer, which applies ser_json_inf_nan. Only model_dump_json() nulls the declared field too.

The value crosses two dumps, and dies in the second:

1. convert_result (func_metadata.py:161) dumps the generated output model, where result is a declared float. inf survives, {'result': inf} — as the report says.
2. _dump_result (runner.py:118) dumps the CallToolResult, where structured_content is dict[str, Any]. The Any serializer nulls it.

Instrumenting _dump_result on your repro:

[_dump_result] in=CallToolResult out={'content': [{'type': 'text', 'text': 'Infinity'}],
                                     'structuredContent': {'result': None}, 'isError': False, ...}

Two things that follow, neither in the report:

• The text block keeps the value ('Infinity'). So this isn't loss, it's structured/unstructured divergence — a client that ignores structuredContent reads the right answer off the same payload.
• convert_result already validates server-side at func_metadata.py:148 and passes, because pydantic validation accepts inf for a float. Server and client validation disagree only because a lossy dump sits between them. Same shape as Generated output schema uses Pydantic's validation shape while structured output uses its serialization shape #3100 on a different axis: there it's validation vs serialization schema, here it's validation vs serialization value.

On the two outcomes you offer — I don't think "the value survives" is reachable inside the SDK. ser_json_inf_nan="constants" emits bare Infinity, which RFC 8259 doesn't allow; "strings" emits "Infinity", which then fails the generated {"type": "number"} schema. Either one is a spec question rather than an SDK one.

That leaves rejecting at the point of return, which is the precedent you cite (request_state.py:128 guards ttl with math.isfinite). Concretely: scan for non-finite floats in convert_result after the first dump and raise there, naming the field and the tool, so the message points at the handler that produced the value instead of at the tool boundary that noticed it.

Happy to put that together if it's the shape you want. Two calls I'd rather not make on my own: whether this should also land on v1.x (both line labels are on the issue), and whether hard-failing is acceptable versus keeping the null and only fixing the client-side message — the first is a behaviour change for anyone currently tolerating the null.