Related: #3067 and the closed PR #3068. I would like to ask whether maintainers want an opt-in, per-tool policy for this behavior, while preserving the existing 2.x default. If this is better discussed in #3067, I am happy to consolidate it there.
On current main (91941ed4d3985d59def99e090baa3f880c626cc8), I reproduced a misspelled argument being silently ignored through an in-memory Client call:
import anyio
from mcp import Client
from mcp.server import MCPServer
mcp = MCPServer("repro")
@mcp.tool()
def list_records(limit: int = 10) -> int:
"""Return at most limit records."""
return limit
async def main() -> None:
async with Client(mcp) as client:
result = await client.call_tool("list_records", {"limti": 1})
print(result.is_error, result.structured_content)
anyio.run(main)Observed: False {'result': 10}. The tool runs with its default, so the caller receives no indication that the supplied parameter was not applied.
Would a configuration along these lines be useful?
@mcp.tool(extra_arguments="forbid") # proposed API, not implemented
def list_records(limit: int = 10) -> int:
return limit
- Default remains
extra_arguments="ignore" for compatibility.
- Opted-in tools publish root
additionalProperties: false and reject unknown top-level argument names before executing the handler.
- Rejection uses the existing
is_error=True tool-result path, allowing the model to correct its call.
- Existing type coercion and nested model/dictionary behavior remain unchanged.
- Programmatic
add_tool registration would expose the same option.
I am not proposing a global default change or automatic spelling correction. Would maintainers consider this worth supporting in 2.x, and is a per-tool option the right scope? No implementation has been started.
Prepared with AI assistance; the reported behavior was reproduced locally.
Related: #3067 and the closed PR #3068. I would like to ask whether maintainers want an opt-in, per-tool policy for this behavior, while preserving the existing 2.x default. If this is better discussed in #3067, I am happy to consolidate it there.
On current main (
91941ed4d3985d59def99e090baa3f880c626cc8), I reproduced a misspelled argument being silently ignored through an in-memory Client call:Observed:
False {'result': 10}. The tool runs with its default, so the caller receives no indication that the supplied parameter was not applied.Would a configuration along these lines be useful?
extra_arguments="ignore"for compatibility.additionalProperties: falseand reject unknown top-level argument names before executing the handler.is_error=Truetool-result path, allowing the model to correct its call.add_toolregistration would expose the same option.I am not proposing a global default change or automatic spelling correction. Would maintainers consider this worth supporting in 2.x, and is a per-tool option the right scope? No implementation has been started.
Prepared with AI assistance; the reported behavior was reproduced locally.