A tool returning a non-finite float puts invalid JSON in the text content block

[jayhemnani9910]

Initial Checks

• I confirm that I'm using the newest release of my line (the latest 2.x, or the latest 1.x if I'm still on v1)
• I confirm that I searched for my issue in https://github.com/modelcontextprotocol/python-sdk/issues before opening this issue

Release line

2.x (current stable), and it reproduces on the latest 1.x too.

Description

This is a different code path from #3341, which I filed for the structured-output case. Same input, different failure, and the two behave inconsistently with each other, so I am reporting it separately. Happy to fold it into #3341 if you would rather track them together.

When a tool has no return annotation, no output schema is generated and the result is rendered to a text block by pydantic_core.to_json(result, fallback=str, indent=2) (func_metadata.py:669 on 2.1.0). to_json writes non-finite floats as the bare tokens NaN and Infinity. RFC 8259 does not allow either, so the text block is not valid JSON. is_error is False, so the call reports success.

The text block sent to the client:

{
  "mean": 1.5,
  "stddev": NaN,
  "max": Infinity
}

Python's json.loads accepts this, because it is lenient about those tokens by default. A spec-compliant parser does not. Node:

> JSON.parse('{"mean":1.5,"stddev":NaN,"max":Infinity}')
SyntaxError: Unexpected token 'N', ..."stddev":NaN,"max":"... is not valid JSON

So the same tool result is readable from a Python client and breaks a TypeScript one.

What I expected: a text content block holding JSON should be parseable by any JSON parser, or the SDK should fail at the server with an error that names the serialisation problem.

Worth noting alongside #3341: for the same input, the structured path silently converts the value to null and the text path emits invalid JSON. Whatever the fix is, it would be good if those two agreed.

The same to_json(..., fallback=str, indent=2) call is used in resources/types.py:103, and prompts/base.py:206 follows the same pattern, so the fix probably wants to cover those too.

Example Code

import json
import math

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

server = MCPServer("stats")


@server.tool()
def summarise():
    """No return annotation, so the result goes out as a text block."""
    return {"mean": 1.5, "stddev": math.nan, "max": math.inf}


async def main() -> None:
    async with Client(server) as client:
        result = await client.call_tool("summarise")
        text = result.content[0].text
        print("is_error:", result.is_error)
        print("text block:", text)
        # Reject NaN/Infinity the way a spec-compliant parser does.
        json.loads(text, parse_constant=lambda c: (_ for _ in ()).throw(ValueError(f"invalid JSON token: {c}")))


anyio.run(main)

Output:

is_error: False
text block: {
  "mean": 1.5,
  "stddev": NaN,
  "max": Infinity
}
ValueError: invalid JSON token: NaN

Python & MCP Python SDK

Python 3.13.11, Linux.

mcp 2.1.0  (latest 2.x): func_metadata.py:669
mcp 1.29.1 (latest 1.x): fastmcp/utilities/func_metadata.py:558
Also reproduces on main at d8b63830.

Reported with AI assistance; I ran the reproduction above and read the output.

[jayhemnani9910]

I have a patch ready locally.

pydantic_core.to_json takes an inf_nan_mode argument. The default is constants, which is what writes the bare tokens. Both other values produce valid JSON:

• null gives {"stddev": null}, matching what the structured path does today
• strings gives {"stddev": "NaN"}, valid and lossless

My patch uses strings at the two call sites that render user values, _convert_to_content in func_metadata.py and FunctionResource.read in resources/types.py. The reasoning is that a text block has no declared schema to satisfy, so there is no reason to drop the value the way #3341 objects to. It is a one-argument change if you would rather have null, and that choice is yours to make.

I left prompts/base.py alone. It uses the same call, but its branch is unreachable in tests, so I could not cover a change there.

The tests assert the rendered text parses to the expected values. ./scripts/test passes on d8b6383, 100% coverage and strict-no-cover clean.

I would like to fix this one myself if you are taking an outside PR for it.

AI-assisted; I ran the reproduction and the suite.