You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
requirements.txt pins mcp>=1.2.0,<2.0.0 (PR #49). That pin exists to restore a reproducible CI build after mcp 2.0.0 removed mcp.server.fastmcp, and it is explicitly a holding measure — this issue exists so the pin does not become permanent by default.
What needs to change
mcp_server.py:23 imports:
frommcp.server.fastmcpimportFastMCP
That import path does not exist in mcp 2.0.0. Migration requires establishing the 2.0 equivalent, updating the server construction, and confirming the exposed tool surface is unchanged.
Why this is not a mechanical find-and-replace
mcp_server.py is a shipped M7 surface. It exposes check_governance, which runs the Pi Script resolver pipeline as an MCP tool. Per Continuum's spec-first principle, a change to a shipped surface is not a refactor of convenience:
The tool's name, input schema, and output shape are the contract. Any drift in them is a governance-visible change, not an implementation detail.
The resolver's behavior — deterministic, fail-loud, no silent defaults — must be preserved exactly across the migration. A 2.0 API that changes error propagation or serialization semantics would need that difference stated, not absorbed.
tests/test_mcp_server.py must continue to pin the same guarantees. If the 2.0 API forces a test rewrite, the rewrite must be shown to test the same properties.
Definition of done
2.0 API equivalent for FastMCP server construction identified against real mcp 2.0 documentation, not inferred
mcp_server.py migrated; check_governance name, input schema, and output shape verified unchanged (or any change explicitly called out for operator review)
tests/test_mcp_server.py passes and still pins the same guarantees
Full suite green
Upper bound removed from requirements.txt, together with the explanatory comment that references this issue
Any behavioral difference between 1.x and 2.0 relevant to determinism or error propagation recorded in the PR
Broader unresolved question, deliberately out of scope here: every other requirement is >=-unpinned, so this class of break can recur. The same CI run pulled pytest 9.1.1, torch 2.13.0, transformers 5.14.1, starlette 1.3.1, sentence-transformers 5.6.1. Whether to constrain the rest is its own decision.
requirements.txtpinsmcp>=1.2.0,<2.0.0(PR #49). That pin exists to restore a reproducible CI build aftermcp2.0.0 removedmcp.server.fastmcp, and it is explicitly a holding measure — this issue exists so the pin does not become permanent by default.What needs to change
mcp_server.py:23imports:That import path does not exist in
mcp2.0.0. Migration requires establishing the 2.0 equivalent, updating the server construction, and confirming the exposed tool surface is unchanged.Why this is not a mechanical find-and-replace
mcp_server.pyis a shipped M7 surface. It exposescheck_governance, which runs the Pi Script resolver pipeline as an MCP tool. Per Continuum's spec-first principle, a change to a shipped surface is not a refactor of convenience:tests/test_mcp_server.pymust continue to pin the same guarantees. If the 2.0 API forces a test rewrite, the rewrite must be shown to test the same properties.Definition of done
FastMCPserver construction identified against realmcp2.0 documentation, not inferredmcp_server.pymigrated;check_governancename, input schema, and output shape verified unchanged (or any change explicitly called out for operator review)tests/test_mcp_server.pypasses and still pins the same guaranteesrequirements.txt, together with the explanatory comment that references this issueRelated
>=-unpinned, so this class of break can recur. The same CI run pulledpytest9.1.1,torch2.13.0,transformers5.14.1,starlette1.3.1,sentence-transformers5.6.1. Whether to constrain the rest is its own decision.