Commit activity
Last 12 weeks · 1026 commits
Community health
5 of 6 standards met
Recent PRs & issues
Fetch is one of the MCP project's own reference servers — the implementation much of the ecosystem learned from — which is why it fills the reference-server slot in Verity's external bench cohort. In our independent screen of 16,341 MCP servers, 81.5% of scored servers passed and 3,022 of 16,362 in-scope package rows (18.5%) did not install as published; a verified record for a reference implementation anchors what "as published" should mean. We know a result here carries extra weight, in either direction, so the terms matter: a full bench is $500 ($150 re-bench, $1,200/yr badge licence), run under published terms — the same battery as every cohort member, with maintainer fact-check and a verbatim response published alongside any card. We would like to walk the maintainers through exactly what would be checked before anything is agreed. One scope note, stated plainly: the bench verifies a server against its own published claims, and Fetch's published claims are its README and package claims. Steven White Cyan Eclipse Technologies LLC steven@cetech.ai
Which server? sequentialthinking (@modelcontextprotocol/server-sequential-thinking) Protocol era Modern (2026-07-28) MCP client _No response_ The problem Characterization proposal — explicitly not a defect claim. The documented caps for sequentialthinking are on the count dimension (thought history length) and on the stderr log formatting. The size dimension is not mentioned in the documentation at all: today a single item of essentially any size is accepted and retained. The three cases below pin that current contract, so that if a per-item cap is ever introduced deliberately, the change is visible in the test suite rather than silent. Cases 1. A 1,000,000-character thought is accepted and counts once in the history. (Existing coverage reaches a 10,000-character thought for acceptance only; how size shows up in the history was unpinned.) 2. A 5,000-line thought is accepted. The line-count limit at lib.ts:271 applies to the display formatting of the log box, not to acceptance. 3. A 10,000-character branchId is accepted and appears verbatim in the array of a later response — the ID passes through validation and retention untruncated (lib.ts:217, 313). This is about the protocol response data; header/display pass-through is a separate surface. Solution you have in mind (optional) Proposed tests For , using its existing helpers: Which MCP feature does it demonstrate? (optional) _No response_ Alternatives or workarounds you have tried Near hits #5433 and #5000 concern the stderr log-box display formatting, which this proposal explicitly distinguishes from protocol-level acceptance — not duplicates. No workaround covers this; the size dimension is not mentioned in the documentation and no per-item cap exists today. Already built it locally? Verification Ran against a byte-identical copy of v2/main @ 6cfff622: 3 passed. Full sequentialthinking suite with them included: 10 files, 142 passed. The tests are labelled characterization in their describe block: they record that no per-item cap exists today, and take no position on whether one should be added — that is the maintainers' call. Prompt used "In src/sequentialthinking's thinking tests, add characterization tests for the size dimension, which the docs don't mention (the documented caps are the thought COUNT and the stderr log box): (1) a 1,000,000-character thought is accepted and counts once in the history; (2) a 5,000-line thought is accepted; (3) a 10,000-character branchId is accepted and appears verbatim in the branches array of a later response. Label them as characterization: they pin the current absence of a per-item cap so that adding one later is a deliberate, visible change." Before you submit [x] I searched existing issues and this is not a duplicate. [x] This is a request for this repository or one of its servers, not a new server, the MCP specification or an SDK.
Which server? everything (@modelcontextprotocol/server-everything) Protocol era Modern (2026-07-28) MCP client _No response_ The problem The multi-step tools' continuation token () is constructed with a declared TTL of 600 seconds (src/everything/server/index.ts:83-85). The existing tests in modern.test.ts pin the tamper case (a modified state is rejected with -32602, :319) and the happy-path round trip (:330) — but not expiry: that a correctly signed, untampered state is refused once its time has run out. Expiry is the security-relevant half of the TTL; if validation only ever checked the signature, an old state would work forever. Case Start over a raw session and capture the . Advance only the clock — plus +601 seconds, the same fake-Date pattern the minted-resource TTL test in the same file uses (:643) — then continue with a valid answer and assert the error is -32602, consistent with the tamper rejection. The state is untampered; only time has passed. Solution you have in mind (optional) Proposed test Beside the existing requestState cases in , using the raw-session harness: Which MCP feature does it demonstrate? (optional) _No response_ Alternatives or workarounds you have tried The only near hit, #4852, is a spec-refactor tracking issue, not a duplicate of this test proposal. No workaround covers this — expiry of a correctly signed, untampered requestState is not pinned by any existing test. Already built it locally? Verification Ran against a byte-identical copy of v2/main @ 6cfff622: 1 passed — the TTL is enforced as declared. Full everything suite with it included: 27 files, 475 passed. Prompt used "In src/everything's modern tests, the requestState cases pin tamper rejection (-32602) and the happy-path round trip, but not expiry. Add one: start trigger-multi-step-elicitation over a raw session, capture the requestState, advance the clock 601 seconds with vi.useFakeTimers({ toFake: ["Date"] }) + setSystemTime (the pattern the minted-resource TTL test in the same file uses), then continue with a valid answer and assert the error is -32602. The state is untampered — only time has passed." Before you submit [x] I searched existing issues and this is not a duplicate. [x] This is a request for this repository or one of its servers, not a new server, the MCP specification or an SDK.
Recent fixes
Which server? More than one server (filesystem and memory) Protocol era Both, or not era-specific MCP client Any. The issue is in the tool descriptions that every client shows the model. The problem Two pairs of tools have descriptions so alike that a model can't tell which one to call. filesystem (2026.8.31): and The descriptions are the same sentence for sentence. They differ only by ", including sizes" and "essential" vs "useful": list_directory: Get a detailed listing of all files and directories in a specified path. Results clearly distinguish between files and directories with [FILE] and [DIR] prefixes. This tool is essential for understanding directory structure and finding specific files within a directory. Only works within allowed directories. list_directory_with_sizes: Get a detailed listing of all files and directories in a specified path, including sizes. Results clearly distinguish between files and directories with [FILE] and [DIR] prefixes. This tool is useful for understanding directory structure and finding specific files within a directory. Only works within allowed directories. Neither says when to pick it over the other, that can sort by size, or that it ends with totals. memory (2026.8.31): and delete_entities: Delete multiple entities and their associated relations from the knowledge graph delete_relations: Delete multiple relations from the knowledge graph Both are destructive. Asked to remove a link between two entities, a model that picks deletes the entities themselves, with all their observations. Neither description says which one to use for that. Solution you have in mind (optional) Say in each description when to use the tool and when to use its sibling instead. Suggested text, written only from what the code does (I checked 's sort and summary in ): : List the files and directories directly inside a path, each marked [FILE] or [DIR]. Use it to see what a directory contains; when you also need each entry's size or want entries sorted by size, use list_directory_with_sizes instead, and for a recursive view use directory_tree. Returns one line per entry. Only works within allowed directories. : List the files and directories directly inside a path with each file's size, marked [FILE] or [DIR], sorted by name or by size (sortBy). Use it when sizes matter, such as finding the largest files; for names only, use list_directory, which returns less text. Returns one line per entry, followed by the totals. Only works within allowed directories. : Delete whole entities from the knowledge graph, together with every relation that points to or from them and all their observations. Use it only to remove an entity entirely; to remove a link between two entities and keep both, use delete_relations, and to remove facts from an entity, use delete_observations. Cannot be undone. : Delete specific relations (from, to, relationType) from the knowledge graph and keep the entities they connect. Use it to remove a link between two entities; to remove an entity itself, use delete_entities. Cannot be undone. Which MCP feature does it demonstrate? (optional) Tool descriptions, and how clients use them to choose a tool. As reference servers, these are what many people copy when writing their own. Alternatives or workarounds you have tried None on the server side. A client can add its own instructions, but every client would have to do it. Already built it locally? No code. The prompt I'd use: "In src/filesystem and src/memory, rewrite the descriptions of list_directory, list_directory_with_sizes, delete_entities and delete_relations so each says when to use it and names the sibling tool to use instead, using only behavior the code implements; keep tool names and schemas unchanged." For context: I found these pairs with Forecall, a static linter for MCP tool descriptions that I maintain. It flags tool pairs whose descriptions overlap heavily. With the text above, its scores go from 38 and 48 to 65 and 70 for the two filesystem tools, and from 51 and 39 to 61 and 61 for the two memory tools. The scores are only a guide; the point is the missing "use X instead". Before you submit [x] I searched existing issues and this is not a duplicate. [x] This is a request for this repository or one of its servers, not a new server, the MCP specification or an SDK.
Repository: modelcontextprotocol/servers. Description: Model Context Protocol Reference Servers Stars: 91979, Forks: 11965. Primary language: TypeScript. Languages: TypeScript (46.9%), JavaScript (33.5%), Python (19.1%), Dockerfile (0.5%). Homepage: https://modelcontextprotocol.io Latest release: v2.4.0 (3d ago). Open PRs: 2, open issues: 17. Last activity: 2d ago. Community health: 87%. Top contributors: cliffhall, olaservo, tadasant, jspahrsummers, dsp-ant, jerome3o-anthropic, maheshmurag, evalstate, baryhuang, marcelo-ochoa and others.