feat(keycardai-fastmcp): rename keycardai-mcp-fastmcp via bridge package (ACC-233)#102
Merged
Merged
Conversation
…age (ACC-233) The current name carries a redundant -mcp suffix (FastMCP only speaks MCP, so the protocol tag adds no information). Renames to keycardai-fastmcp per the revised KEP, with keycardai-mcp-fastmcp preserved as a deprecation bridge so the customer in production on the old name keeps working indefinitely. What ships: * New keycardai-fastmcp package at packages/fastmcp/, full implementation under the keycardai.fastmcp namespace. Tests, examples, README move with the source. Wired into the workspace and the release.yml tag filter. * Deprecated keycardai-mcp-fastmcp now depends only on keycardai-fastmcp and re-exports every public symbol at the original keycardai.mcp.integrations.fastmcp.* paths. Importing the top-level module emits a DeprecationWarning pointing at the canonical name. * Bridge contract test (test_bridge.py, 4 tests) asserts the DeprecationWarning fires and that bridge symbols are identity-equal to the canonical ones. The full behavioral suite lives in keycardai-fastmcp going forward. Customer impact: pip install keycardai-mcp-fastmcp keeps working; the package transitively pulls keycardai-fastmcp. No forced removal timeline, the bridge ships until every known caller migrates. Verified: ruff clean. fastmcp 51/51, mcp-fastmcp bridge 4/4, mcp 560/560, oauth 208/208, starlette 49/49. Supersedes the canceled ACC-195 (which used the now-rejected keycardai-fastmcp-mcp name).
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
📦 Release PreviewThis analysis shows the expected release impact: 📈 Expected Version Changes📋 Package Details[
{
"package_name": "keycardai-fastmcp",
"package_dir": "packages/fastmcp",
"has_changes": true,
"current_version": "0.1.0",
"next_version": "0.2.0",
"increment": "MINOR"
}
]📝 Changelog PreviewThis comment was automatically generated by the release preview workflow. |
Review caught that the bridge provider.py only re-exported a hand-enumerated subset of the canonical surface, dropping documented public symbols (get_token_debug_info, introspect, INTROSPECT, AuthProviderConfigurationError, AuthProviderInternalError, AuthProviderRemoteError). Importing any of those from keycardai.mcp.integrations.fastmcp.provider raised ImportError, breaking the bridge contract for downstream callers using less common symbols. Fixes: - Add __all__ to keycardai.fastmcp.provider listing the 28-name public surface. Stdlib/typing helpers (logging, os, urlparse, wraps, Any, Callable, etc.) are deliberately excluded. - Replace the bridge provider.py hand-enumeration with ``from keycardai.fastmcp.provider import *``, plus a re-export of __all__ so future symbol additions to the canonical module flow through automatically. - Add test_bridge_provider_exposes_full_public_surface: iterates the canonical __all__, asserts every symbol is present at the bridge path and identity-equal to the canonical reference. Regression test for the symbol-drop class of bug. - Scrub em dashes from the renamed example READMEs (pre-existing prose, but new file paths shipping under our review). Verified: fastmcp 51/51, mcp-fastmcp bridge 5/5 (was 4 + 1 new). Smoke: the six previously-missing symbols now import cleanly from the old path.
📦 Release PreviewThis analysis shows the expected release impact: 📈 Expected Version Changes📋 Package Details[
{
"package_name": "keycardai-fastmcp",
"package_dir": "packages/fastmcp",
"has_changes": true,
"current_version": "0.1.0",
"next_version": "0.2.0",
"increment": "MINOR"
}
]📝 Changelog PreviewThis comment was automatically generated by the release preview workflow. |
kamil-keycard
approved these changes
Apr 27, 2026
…ai-fastmcp # Conflicts: # uv.lock
The action stopped resolving "latest" sometime today and started failing with `no release for just matching version specifier`. Pinning unblocks PR validation and the post-merge bump-and-publish pipeline. 1.50.0 is the current stable just release (April 2026).
extractions/setup-just@v2 is currently broken for both unpinned and
explicit-version requests ("no release for just matching version
specifier"). Pinning to 1.50.0 did not help because the action regression
is in its release lookup, not its version resolution.
Switch to the just.systems install script (the project owners ship and
maintain it). Runs as a plain bash step with no third-party action
dependency and is unaffected by setup-just regressions.
📦 Release PreviewThis analysis shows the expected release impact: 📈 Expected Version Changes📋 Package Details[
{
"package_name": "keycardai-agents",
"package_dir": "packages/agents",
"has_changes": true,
"current_version": "0.1.1",
"next_version": "0.2.0",
"increment": "MINOR"
},
{
"package_name": "keycardai-fastmcp",
"package_dir": "packages/fastmcp",
"has_changes": true,
"current_version": "0.1.0",
"next_version": "0.2.0",
"increment": "MINOR"
}
]📝 Changelog PreviewThis comment was automatically generated by the release preview workflow. |
3 tasks
Larry-Osakwe
added a commit
that referenced
this pull request
Apr 27, 2026
…-fastmcp (#103) Empty commit to trigger the auto-bump pipeline for keycardai-mcp-fastmcp. The actual bridge code (depends on keycardai-fastmcp, re-exports every public symbol at the original keycardai.mcp.integrations.fastmcp.* paths, emits DeprecationWarning on top-level import) shipped in #102. That PR landed scoped (keycardai-fastmcp), so cz only bumped the new package and keycardai-mcp-fastmcp on PyPI is still the pre-rename version. This commit gives cz a (keycardai-mcp-fastmcp)-scoped feat to recognize so the bridge ships as the next published version and customers on the old name see the deprecation warning.
This was referenced Apr 28, 2026
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
2 participants
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.
Summary
Closes ACC-233. The current name carries a redundant
-mcpsuffix (FastMCP only speaks MCP, so the protocol tag adds no information). Per the revised KEP this renames tokeycardai-fastmcp, withkeycardai-mcp-fastmcppreserved as a deprecation bridge so the customer in production on the old name keeps working indefinitely.What ships
keycardai-fastmcppackage at packages/fastmcp/, full implementation under thekeycardai.fastmcpnamespace. Tests, examples, README move with the source.[tool.uv.sources]in the root pyproject and to the*-keycardai-fastmcptag filter inrelease.yml.keycardai-mcp-fastmcpnow depends only onkeycardai-fastmcpand re-exports every public symbol at the originalkeycardai.mcp.integrations.fastmcp.*paths. Importing the top-level module emits aDeprecationWarningpointing at the canonical name.packages/mcp-fastmcp/tests/test_bridge.py, 4 tests) asserts theDeprecationWarningfires and that bridge symbols are identity-equal to the canonical ones. The full behavioral suite lives inkeycardai-fastmcpgoing forward.Customer impact
pip install keycardai-mcp-fastmcpkeeps working; the package transitively pullskeycardai-fastmcp. Existing imports work with a runtimeDeprecationWarning. No forced removal timeline, the bridge ships until every known caller migrates.Test plan
cd packages/fastmcp && uv run --extra test pytest→ 51/51cd packages/mcp-fastmcp && uv run --extra test pytest→ 4/4 (bridge contract)cd packages/mcp && uv run --extra test pytest→ 560/560 (unaffected)cd packages/oauth && uv run --extra test pytest→ 208/208 (unaffected)cd packages/starlette && uv run --extra test pytest→ 49/49 (unaffected)uv run ruff checkcleanpython -W default::DeprecationWarning -c "import keycardai.mcp.integrations.fastmcp"emits the warningPyPI requirement before first release tag
keycardai-fastmcpis a new PyPI project. Before the first*-keycardai-fastmcptag fires throughrelease.yml, set up a pending Trusted Publisher under the keycard org (same setup we used forkeycardai-starlette):keycardai/python-sdkrelease.ymlpypi-releasekeycardai-fastmcpThe first tag will create the project on PyPI under the org.
keycardai-mcp-fastmcpkeeps its existing publisher; the bridge release uses that.Supersedes
keycardai-fastmcp-mcpname; rejected in 2026-04-23 KEP revision in favor of dropping the protocol suffix).