Bump MCP dependencies across templates - #19
Merged
Conversation
Two Python templates are broken on a fresh resolve today. keycardai-mcp 0.26.0 declares an unbounded "mcp>=1.13.1", so `uv lock --upgrade` pulls mcp 2.0.0, which deleted mcp.server.fastmcp and makes keycardai-mcp fail to import outright. The committed lockfiles pinned mcp 1.27.1 and hid it, so only someone regenerating a lock or starting fresh hits it. Pinned mcp<2.0 in mcp-server-python-mcp and mcp-brokered-credentials-python and refreshed both locks; they now resolve keycardai-mcp 0.26.0 with mcp 1.29.0, and the entrypoint imports cleanly. Drop the pin once a keycardai-mcp targeting mcp 2.0 ships. Both Go templates still imported github.com/keycardai/credentials-go, the pre-rename module path, at v0.13.0. Moved to github.com/keycardai/go-sdk v0.18.1 across go.mod, main.go, README and SPEC, and bumped modelcontextprotocol/go-sdk v1.6.1 -> v1.7.0, which carries protocol revision 2026-07-28. Note that sessions still negotiate 2025-11-25: upstream caps the initialize path there because initialize is itself deprecated as of the new revision. mcp-server-go's SPEC troubleshooting entry described /.well-known/oauth-protected-resource omitting authorization_servers unless the client sent MCP-Protocol-Version: 2025-03-26. That branch no longer exists; the field now comes from the issuer passed to AuthMetadataHandler and is omitted only when no issuer is configured. Rewrote it, since as written it pointed at a cause that cannot occur and promised a fix that already shipped. Three TypeScript templates sat on @keycardai/mcp ^0.4.0, eight minors behind, missing among other things the JWKS-error mapping that returns 401/503 instead of 500. Bumped to ^0.12.1. They stay on @modelcontextprotocol/sdk ^1.0.0: MCP v2 is a package split rather than a version bump, and the @keycardai/mcp release targeting it is not published yet. Verified: both Go templates build and vet clean, all three TypeScript templates typecheck, and both Python templates import.
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Currency pass across all six templates that depend on a Keycard SDK. Ready to merge — not a draft.
Prompted by wanting a live-test surface for the MCP v2 work, but two of these turned out to be broken today, which is the part worth reviewing first.
The Python templates are broken on a fresh resolve
keycardai-mcp0.26.0 declares an unboundedmcp>=1.13.1. Sincemcp2.0.0 published on 2026-07-28, a fresh resolve pulls it — and 2.0 deletedmcp.server.fastmcp, sokeycardai-mcpfails to import outright:The committed lockfiles pinned
mcp1.27.1 and hid this, so it only bites someone runninguv lock --upgradeor starting from scratch — which is exactly what a template is for. Reproduced in bothmcp-server-python-mcpandmcp-brokered-credentials-python.Pinned
mcp<2.0in both and refreshed the locks. They now resolvekeycardai-mcp 0.26.0+mcp 1.29.0, and the entrypoint imports cleanly. The pin comes out once akeycardai-mcptargeting mcp 2.0 ships (keycardai/python-sdk#218).Go templates were on the pre-rename module path
Both imported
github.com/keycardai/credentials-goat v0.13.0. Moved togithub.com/keycardai/go-sdkv0.18.1 acrossgo.mod,main.go, README and SPEC, and bumpedmodelcontextprotocol/go-sdkv1.6.1 → v1.7.0.v1.7.0 carries protocol revision 2026-07-28, but worth stating plainly: sessions still negotiate 2025-11-25. Upstream caps the initialize path there because
initializeis itself deprecated as of the new revision. A bare v1.7.0 server with no Keycard code behaves the same way.A stale SPEC entry that pointed at a non-existent cause
mcp-server-go's troubleshooting section said/.well-known/oauth-protected-resourceomitsauthorization_serversunless the client sendsMCP-Protocol-Version: 2025-03-26, called it an SDK limitation, and promised a fix "lands SDK-side."That branch is gone.
authorization_serversnow comes from the issuer passed toAuthMetadataHandlerand is omitted only when no issuer is configured — the SDK regression-tests exactly that. Rewrote the entry, since as written it sent people chasing a cause that can't occur.TypeScript templates were eight minors behind
Three templates sat on
@keycardai/mcp ^0.4.0→^0.12.1. Among other things that picks up the JWKS-error mapping that returns 401/503 instead of 500.They stay on
@modelcontextprotocol/sdk ^1.0.0deliberately. MCP v2 is a package split rather than a version bump — the client moved to@modelcontextprotocol/client— and the@keycardai/mcprelease targeting it is not published yet (keycardai/typescript-sdk#139).Verification
mcp-server-gogo build+go vetcleanmcp-delegated-access-gogo build+go vetcleanmcp-server-typescript-expresstsc --noEmit+npm run buildcleanmcp-brokered-credentials-typescripttsc --noEmitcleanautonomous-agent-snowflake-wiftsc --noEmitcleanmcp-server-python-mcpmcp-brokered-credentials-pythonNo
credentials-goreferences remain anywhere outsidego.sum.What this does not do
It does not get any template onto MCP v2. That needs the two SDK PRs above to merge and publish first; this PR clears the stale pins and the live Python break so that follow-up is a clean one-line bump per template. Running the
evalharness against a real zone is the actual v2 live test, and it needs credentials this change can't supply.🤖 Generated with Claude Code