modelcontextprotocol / modelcontextprotocol/python-sdk
Tool input schemas carry a pydantic-derived title on every property
まだ誰も着手していません。
- 主要言語
- Python
- スター
- 24.3k
- フォーク
- 4k
- 平均マージ
- 1日 1時間
- マージ済み PR(30日)
- 31
説明
Description
Every tool's inputSchema carries a title on every property, derived by pydantic from the field name. A parameter named exercise_id gets "title": "Exercise Id" — a restatement of the key it already sits under. Tool schemas are re-sent to the model on every request, so this is paid for in context on every turn.
I ran into this running a local 27B model against the wger MCP server, where context is genuinely scarce. Measuring its live tools/list:
| bytes | share | |
|---|---|---|
| whole payload, 49 tools | 43,710 | 100% |
| tool descriptions (prose) | 10,904 | 25% |
auto-derived title keys (297 of them) |
8,333 | 19% |
anyOf null-wrapping on optionals |
1,869 | 4% |
My agent is granted 43 of those tools, which is ~11,100 tokens of schema against a 32k window — 42% of the context gone before the first message, once the system prompt is counted. Roughly 2,000 of those tokens are titles.
Reproduction — any tool at all:
from mcp.server.mcpserver import MCPServer
mcp = MCPServer("demo")
@mcp.tool()
def log_set(exercise_id: str, reps: int) -> str:
"""Log a set."""
return "ok"
inputSchema.properties is:
{
"exercise_id": {"title": "Exercise Id", "type": "string"},
"reps": {"title": "Reps", "type": "integer"}
}
I'd expect the titles not to be there, since they add nothing a model can act on that the property name doesn't already say.
GenerateJsonSchema has a hook for exactly this — field_title_should_be_set — and Tool.from_function already passes a custom generator elsewhere in the file, so it's a small change. Suppressing the automatic titles leaves an explicit Field(title=...) intact, which seems like the right line to draw: an explicit title is the author's choice, an auto-derived one is a default nobody asked for.
Two things I'd want a maintainer's call on before this is worth doing:
- Default or opt-in. Changing the default updates 12 test expectations in this repo (mostly
snapshot(...)intests/docs_src/), so it's visible. An opt-in flag onMCPServer(...)avoids that but adds public API. - Scope. Output schemas, prompts and resource templates generate titles the same way. Output schemas alone are another 61 titles in the payload I measured. Worth doing together, or separately?
Happy to open a PR if it's useful — I have the change and the test updates working locally against main, full suite green. Equally happy to leave it if you'd rather write it yourselves.
Disclosure: I used an AI agent to take the measurements and draft the change. The problem is one I actually hit, and I've read and can explain the result.
References
field_title_should_be_set— https://docs.pydantic.dev/latest/api/json_schema/#pydantic.json_schema.GenerateJsonSchema.field_title_should_be_set- Server measured — https://github.com/wger-project/mcp-server
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
調査の方向性
Tool.from_function と既存のカスタムジェネレーターから始め、次に Pydantic のフック GenerateJsonSchema.field_title_should_be_set を確認します。tests/docs_src/ のスナップショットの期待値を確認し、この変更の対象を入力スキーマだけにするのか、その他の生成スキーマも含めるのかを maintainer と決めます。自動のプロパティタイトルが削除され、明示的な Field タイトルが維持され、影響を受けるテストが更新されてパスすれば完了です。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- python
- 領域
- api, backend
- issue の種類
- 機能追加
- 難易度
- 3/5
- 見積もり時間
- 1〜2日
- 活発さ
- 活発
- 明瞭さ
- おおむね明確
- 初心者へのやさしさ
- 52/100