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
{{ message }}
Repository navigation
Tool contract drift across server-filesystem and server-everything releases (receipts, plus a PR diff action) #5218
We pin MCP tool contracts ({name, description, inputSchema} over a canonical form, plus prompts and resources) and diff them across published versions. Two reference servers drift more than the reference role suggests, and none of it is per-tool visible in changelogs.
@modelcontextprotocol/server-filesystem, 0.2.0 -> 2.0.0: 14 findings, 8 BREAKING.read_file, read_multiple_files, write_file, create_directory, list_directory, move_file, search_files, get_file_info all tightened their inputSchema. 9 -> 14 tools (+ read_text_file, read_media_file, edit_file, list_directory_with_sizes, directory_tree). The diff is identical at the 2026.8.31, 1.0.0 and 2.0.0 endpoints: the 2.0.0 bump changed nothing in the tool surface. 456K npm installs/week (week ending 2026-10-18). Receipts + repro: filesystem.md.
@modelcontextprotocol/server-everything, 0.1.0 -> 2.0.0: 43 findings.echo LOOSENED; add, longRunningOperation, sampleLLM, getTinyImage GONE; 15 new tools (three of them added by the 2.0.0 release of 2026-10-19); the prompt and resource demo surfaces replaced wholesale (2 prompts and 10 resources gone, 4 prompts and 7 resources appeared). 5 -> 16 tools. Receipts + repro: everything.md.
Version note: 2.0.0 (2026-10-19) is the newest release and carries the latest tag; the untagged calver snapshots (2026.x) are semver-higher but published earlier.
If per-PR visibility would help review, we released a GitHub Action that diffs every PR against a committed baseline and posts the contract diff (tools, prompts, resources, direction-graded, advisory-scored) as a PR comment: rugsnare-pr-diff v1.3.0. Live example on a real PR, including a deliberately planted rug pull: rugsnare#14. Happy to open PRs that add the workflow + baselines for either server.
Severity 2: no defect in a server; the report is about how visible tool-interface changes are across releases. The everything server's interface is already diffed on every PR (everything-mcp-diff.yml, from Adopt MCP interface-diff CI for the everything server (decide on PR #3260) #4860), and changesets record each TypeScript server's changes per release.
Urgency 1: no time pressure
Bonuses: none
Board: Servers V2 (#43), Status Incoming, awaiting maintainer review (no milestone yet).
Thanks for the triage - and for your #4860: the per-PR interface diff on everything is the right in-repo pattern, glad it exists.
One scope note, not a priority argument: both mechanisms serve the repo - changesets and PR diffs tell maintainers what changed. Our report's class is one step downstream: consumers install published packages and can't run the repo's CI, and a changelog line is prose, not a verifiable surface. A committed pin per release ({name, description, inputSchema} hashes, one file per server) would make the published surface verifiable at install time by anyone - the filesystem findings in the report (BREAKING read_file, read_text_file appearing alongside it) read as a changelog line to a maintainer but as concrete breakage to a client that pinned the old shape.
Happy to contribute a release-pin workflow sketch if the board ever wants the consumer half - no push on priority from our side.
Activity
cliffhall commentedon Oct 28, 2026
Triage: Priority Low (total 3)
everythingserver's interface is already diffed on every PR (everything-mcp-diff.yml, from Adopt MCP interface-diff CI for the everything server (decide on PR #3260) #4860), and changesets record each TypeScript server's changes per release.Board: Servers V2 (#43), Status
Incoming, awaiting maintainer review (no milestone yet).Paraphern commentedon Oct 29, 2026
Thanks for the triage - and for your #4860: the per-PR interface diff on
everythingis the right in-repo pattern, glad it exists.One scope note, not a priority argument: both mechanisms serve the repo - changesets and PR diffs tell maintainers what changed. Our report's class is one step downstream: consumers install published packages and can't run the repo's CI, and a changelog line is prose, not a verifiable surface. A committed pin per release (
{name, description, inputSchema}hashes, one file per server) would make the published surface verifiable at install time by anyone - the filesystem findings in the report (BREAKINGread_file,read_text_fileappearing alongside it) read as a changelog line to a maintainer but as concrete breakage to a client that pinned the old shape.Happy to contribute a release-pin workflow sketch if the board ever wants the consumer half - no push on priority from our side.