Found while implementing #542; separately recorded and deferred at the user's request. This does not expand that issue's bounded whole-signature/generic-profile repair into a cross-module framework resolver.
Problem and reproduction
_is_python_context_symbol recognizes every Context under each supported framework module prefix, independently of which framework constructed the registered server. The static reader therefore publishes framework_injected with no signature limitation for both of these synthetic signatures:
from mcp.server.fastmcp import FastMCP
from fastmcp import Context
server = FastMCP('fixture')
@server.tool()
def lookup(ctx: Context) -> str:
return 'fixture'Replacing the Context import with from mcp.server.fastmcp.application import Context produces the same exclusion, although the reader established neither that export nor its ancestry. These were read with scan_source; no target module or tool was executed. The #542 whole-signature repair retains this inherited class-provenance limitation rather than claiming to solve it.
Evidence
- The SDK 1.27.2 selector tests ancestry against its own Context class.
- Standalone FastMCP 2.14.5 Context is declared as a separate
class Context, not a subclass of the SDK's Context. The two canonical package names do not establish interchangeable injected types.
inputs/mcp_idioms.py::_python_site, _python_signature, _python_class_identity, and _is_python_context_symbol carry registration and class evidence separately. The server index proves a server binding but does not associate the selected Context with that server family and exact export.
This reproduces an incorrect parameter-exclusion claim, not an unsafe release or runtime exploit.
Bounded follow-up
Carry the already-established constructor family into signature selection, distinguish exact supported Context exports from arbitrary prefixed imports, and retain unknown or mixed-family provenance as an explicit coverage limitation. A re-export or imported subclass requires actual bounded class evidence; do not import the target, treat a package prefix as proof, or build a general Python evaluator.
Acceptance
Refs #542, #539, #431. Medium extraction confidence and static-only operation remain unchanged; no new release verdict or automatically expanded support claim.
Found while implementing #542; separately recorded and deferred at the user's request. This does not expand that issue's bounded whole-signature/generic-profile repair into a cross-module framework resolver.
Problem and reproduction
_is_python_context_symbolrecognizes everyContextunder each supported framework module prefix, independently of which framework constructed the registered server. The static reader therefore publishesframework_injectedwith no signature limitation for both of these synthetic signatures:Replacing the Context import with
from mcp.server.fastmcp.application import Contextproduces the same exclusion, although the reader established neither that export nor its ancestry. These were read withscan_source; no target module or tool was executed. The #542 whole-signature repair retains this inherited class-provenance limitation rather than claiming to solve it.Evidence
class Context, not a subclass of the SDK's Context. The two canonical package names do not establish interchangeable injected types.inputs/mcp_idioms.py::_python_site,_python_signature,_python_class_identity, and_is_python_context_symbolcarry registration and class evidence separately. The server index proves a server binding but does not associate the selected Context with that server family and exact export.This reproduces an incorrect parameter-exclusion claim, not an unsafe release or runtime exploit.
Bounded follow-up
Carry the already-established constructor family into signature selection, distinguish exact supported Context exports from arbitrary prefixed imports, and retain unknown or mixed-family provenance as an explicit coverage limitation. A re-export or imported subclass requires actual bounded class evidence; do not import the target, treat a package prefix as proof, or build a general Python evaluator.
Acceptance
Refs #542, #539, #431. Medium extraction confidence and static-only operation remain unchanged; no new release verdict or automatically expanded support claim.