You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
When a tool exposes an optional nullable parameter (e.g. int | None = None in Python), the Inspector's JSON argument editor mishandles edits to the default null value. Instead of allowing normal deletion or replacement, each keystroke (e.g. Backspace) progressively re-escapes the value, corrupting it into invalid JSON. This appears to be a JSON editor/state-handling issue in the Inspector UI itself, not an issue with the underlying MCP server or tool schema.
To Reproduce
Steps to reproduce the behavior:
Create a tool with an optional nullable parameter:
fromfastmcpimportFastMCPmcp=FastMCP(name="Demo")
@mcp.tooldefadd_numbers(a: int, b: int|None=None) ->int:
""" Add two numbers and return the result """returna+bif__name__=="__main__":
mcp.run()
Launch the Inspector via fastmcp dev inspector file_name.py
Open the add_numbers tool in the Inspector UI
Observe the auto-generated JSON input:
{
"b": null
}
Click into the null value field
Press Backspace repeatedly
Observe the value progressively accumulate escape characters instead of deleting cleanly:
null → "nul" → \"nul" → \\\"nul ...
(see attached screen recording for the live progression)
Screen.Recording.2026-08-01.120224.mp4
Expected behavior
One of the following:
Backspace/Delete should remove characters normally without introducing escape sequences.
Clicking into a null value should allow direct replacement by typing a new value (e.g. an integer).
Optional/nullable fields should be rendered with a more editor-friendly representation (e.g. an empty input with a placeholder of null, or a toggle for "no value") rather than as a literal, in-place-edited null token.
Logs
fastmcp dev inspector file_name.py
Starting MCP inspector...
MCP Inspector Web is up and running at:
http://localhost:6274?MCP_INSPECTOR_API_TOKEN=<token>
Sandbox (MCP Apps): http://localhost:29822/sandbox
Auth token: <token>
Opening browser...
Additional context
Changing the parameter to a non-nullable field with a non-null default (e.g. b: int = 30) reproduces normal, expected editor behavior — no escaping issue occurs. This suggests the bug is specific to how the editor handles/serializes null as the initial or current value, rather than an issue with numeric fields in general.
This makes it difficult to test or interact with any tool that has optional nullable parameters through the Inspector's JSON editor, which is a common and idiomatic pattern in typed Python (and TypeScript) tool definitions.
Screen recording attached showing the live escaping progression as Backspace is pressed repeatedly on the null value.
Reproduction code (shown above) attached/included for convenience.
Environments:
@modelcontextprotocol/inspector version: 2.0.0
FastMCP Version : 3.4.5
Python Version: 3.14.6
Node Version: 22.19.0
npm version: 10.9.3
OS: Windows 11 Home Single Language, Version 10.0.26200 (Build 26200).
Describe the bug
When a tool exposes an optional nullable parameter (e.g.
int | None = Nonein Python), the Inspector's JSON argument editor mishandles edits to the defaultnullvalue. Instead of allowing normal deletion or replacement, each keystroke (e.g. Backspace) progressively re-escapes the value, corrupting it into invalid JSON. This appears to be a JSON editor/state-handling issue in the Inspector UI itself, not an issue with the underlying MCP server or tool schema.To Reproduce
Steps to reproduce the behavior:
Create a tool with an optional nullable parameter:
Launch the Inspector via
fastmcp dev inspector file_name.pyOpen the
add_numberstool in the Inspector UIObserve the auto-generated JSON input:
{ "b": null }Click into the
nullvalue fieldPress Backspace repeatedly
Observe the value progressively accumulate escape characters instead of deleting cleanly:
(see attached screen recording for the live progression)
Screen.Recording.2026-08-01.120224.mp4
Expected behavior
One of the following:
nullvalue should allow direct replacement by typing a new value (e.g. an integer).null, or a toggle for "no value") rather than as a literal, in-place-editednulltoken.Logs
Additional context
b: int = 30) reproduces normal, expected editor behavior — no escaping issue occurs. This suggests the bug is specific to how the editor handles/serializesnullas the initial or current value, rather than an issue with numeric fields in general.nullvalue.Environments: