fix: handle bare MCP request types for fastmcp 3.x compatibility#1813
fix: handle bare MCP request types for fastmcp 3.x compatibility#1813alexmojaki merged 2 commits intomainfrom
Conversation
…compatibility The MCP integration assumed requests always have a `.root` attribute (RootModel wrappers like ClientRequest), but fastmcp 3.x can send bare request types directly (e.g. ReadResourceRequest) when OTel context propagation is active. This caused AttributeError crashes. Use getattr fallback to handle both cases - RootModel wrappers use `.root`, bare request types fall back to themselves. https://claude.ai/code/session_01BRaoRh5qKYjqJxMrxDpxJQ
Deploying logfire-docs with
|
| Latest commit: |
47c5342
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://d3a6643f.logfire-docs.pages.dev |
| Branch Preview URL: | https://claude-slack-session-oai1n.logfire-docs.pages.dev |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
…n for fastmcp 3.x compatibility
There was a problem hiding this comment.
🚩 No tests added for the bare request type (fastmcp 3.x) code path
The PR adds defensive getattr guards to handle bare request types sent by fastmcp 3.x, but there are no new tests exercising this code path. The existing tests in test_openai_agents_mcp.py and test_pydantic_ai_mcp.py use the standard MCP library which sends RootModel wrappers. If fastmcp 3.x is not a test dependency, this fallback path is untested. While the logic is straightforward, a test with a mock bare request type would increase confidence.
Was this helpful? React with 👍 or 👎 to provide feedback.
There was a problem hiding this comment.
(Claude) Noted, tracking in questions.md — the getattr fallback is straightforward but testing the fastmcp 3.x bare-type path would require adding it as a test dependency, which is beyond scope for this compatibility fix.
Summary
AttributeError: 'ReadResourceRequest' object has no attribute 'root'when usinglogfire.instrument_mcp()with fastmcp 3.x.rootattribute (RootModel wrappers likeClientRequest), but fastmcp 3.x can send bare request types directly when OTel context propagation is activegetattr(request, 'root', request)fallback to handle both RootModel wrappers and bare request typesTest plan
Slack thread: https://pydantic.slack.com/archives/C08KLDX918V/p1774633203047079?thread_ts=1774364407.066059&cid=C08KLDX918V
https://claude.ai/code/session_01BRaoRh5qKYjqJxMrxDpxJQ