modelcontextprotocol / modelcontextprotocol/python-sdk

Server.call_tool()'s input-validation error result discards jsonschema.ValidationError's structured fields, leaving only free-text prose

未關閉
#3,351 1 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

還沒有人認領這個 Issue。

v1 v2
主要語言
Python
星號
24.3k
分支
4k
平均合併
1 天 1 小時
30 天內合併 PR
31

描述

Summary

Server.call_tool()'s low-level dispatch validates tool arguments against tool.inputSchema and, on failure, builds the error result like this:

try:
    jsonschema.validate(instance=arguments, schema=tool.inputSchema)
except jsonschema.ValidationError as e:
    return self._make_error_result(f"Input validation error: {e.message}")

_make_error_result produces CallToolResult(content=[TextContent(text=error_message)], isError=True) — no code, no structured data, nothing beyond the interpolated message string. jsonschema.ValidationError carries several structured attributes that would make a good stable identifier — e.validator (e.g. "type", "required", "enum", "additionalProperties"), e.schema_path, e.json_path — but all of them are discarded before the text crosses the transport (stdio, in our case).

Why this matters

A client that wants to programmatically distinguish why a tool call was rejected (missing required field vs. wrong type vs. enum mismatch, etc.) currently has no option but to regex e.message. That's brittle by construction: jsonschema's message wording already varies per validator keyword ("'X' is not of type 'Y'", "'X' is a required property", "'X' is not one of [...]", ...) with no shared machine-readable code across them, and nothing upstream commits to keeping that wording stable across jsonschema versions.

We hit this trying to classify tool-call failures from an MCP server (google-analytics-mcp, built on this SDK's low-level Server class) into "agent-fixable bad input" vs. "genuine server fault" for log-severity purposes, and had to give up — there's no code or structured field anywhere in the CallToolResult to key on, only the interpolated message. Confirmed this isn't something a well-behaved MCP client (or our own client's JSON-RPC handling) is dropping — the schema-validation error result is a normal JSON-RPC success envelope wrapping isError: true, and _make_error_result simply never puts anything but a message string into it.

Suggested fix

Forward e.validator (and ideally e.schema_path/e.json_path) into a structured data field on the error result, alongside the existing human-readable message — e.g. _make_error_result(message, data={"validator": e.validator, "schema_path": list(e.schema_path)}) — so any server built on the low-level Server class gets locale-stable, machine-readable input-validation errors "for free," without every server author having to reimplement schema validation themselves to get one.

Happy to provide a full repro (raw JSON-RPC request/response) if useful.

貢獻指南

開啟貢獻指南

從這裡開始

  1. 先讀完整個 Issue,再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫,在一個分支上完成修改。
  4. 送出 Pull Request,並在描述裡引用這個 Issue 編號。

研究方向

從 Server.call_tool() 和 _make_error_result() 開始,接著追蹤 JSON-RPC 傳輸使用的 CallToolResult 結構。檢查現有的 input-schema 驗證與錯誤結果測試。完成的標準是:驗證失敗保留目前的人類可讀訊息,同時公開穩定的結構化欄位,例如驗證器和 schema 路徑。

由索引模型根據 Issue 內容生成。

評估

技術堆疊
python
領域
api, backend
Issue 類型
功能
難度
3/5
預估耗時
1-2 天
活躍度
活躍
描述清晰度
基本清楚
新手友好度
55/100

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。