One account wrote 86 of the 88 commits in the newest release of the official MCP servers, v2.4.0, on 11 November. I counted it with the GitHub compare API; the commands below repeat it.

The release is v2.4.0 of modelcontextprotocol/servers, a security release that fixes six vulnerabilities in three servers. github-actions wrote the other two commits. The release before it, v2.3.0, came out on 4 November: cliffhall wrote 153 of 156. Across the five releases since v1.0.0, the same account wrote 575 of the 591 commits.

Does your agent use the filesystem, git, fetch or memory server? Then this number changes how you depend on the code, not whether you use it. The concentration is deliberate.

Who maintains the official MCP servers right now

I compared each pair of v2 tags and counted the author of each commit. These are the tags: v1.0.0 (11 October), v2.0.0 (19 October), v2.1.0 (25 October), v2.2.0 (28 October), v2.3.0 (4 November) and v2.4.0 (11 November).

• v1.0.0 to v2.0.0: cliffhall wrote 155 of 162 commits.
• v2.0.0 to v2.1.0: cliffhall wrote 59 of 61 commits.
• v2.1.0 to v2.2.0: cliffhall wrote 122 of 124 commits.
• v2.2.0 to v2.3.0: cliffhall wrote 153 of 156 commits.
• v2.3.0 to v2.4.0: cliffhall wrote 86 of 88 commits.

The total is 575 of 591 commits, or 97 percent. The bot wrote 10 commits. Two other accounts wrote 3 commits each.

The release notes show the same pattern. The v2.3.0 body has 74 change lines. 65 lines credit cliffhall. 9 lines credit the bot. The repository tagged six releases in 31 days.

Why one account writes almost every commit

The CONTRIBUTING file gives the rule in its first lines: “We accept issues, not pull requests.” A person outside the maintainer group opens a pull request, and the maintainers close it. Do you have a local fix? Then they ask you for “the prompt you used”. They do not ask for the diff.

The reason is the workflow. The maintainers develop the servers “with an AI-assisted, prompt-driven workflow”. The repository holds seven packages in two languages with shared gates. An outside diff “has to be reverse-engineered to fit”. AGENTS.md gives one more rule: the development branch “requires no approvals, so a maintainer can merge their own PR.”

The thank-you list at the bottom of the v2.3.0 notes shows the effect. It has 70 lines. They name 67 different people. 32 people reported issues. The maintainers closed 38 pull requests from 35 people and rebuilt those changes. Three separate pull requests (#4459, #4496 and #4636) made a prototype of the same fetch timeout for issue 4448.

The commit log shows the method. The 176 merge commits take no trailer. Of the other 327 commits, 313 name Claude Opus 5.5 as co-author, every one of cliffhall’s own; the 14 without are the bot’s 8 and 6 from two outside accounts. The committer field reads cliffhall 324 times and GitHub’s merge button 176 times. In ten sampled pull requests, cliffhall wrote and merged every one, and a bot was the only other reviewer. The releases endpoint lists him as author of all five releases. One account merged and published it all. The work is concentrated in one person, and all of his own is machine-drafted under his review.

Bon. This model is coherent. One careful person keeps a small codebase consistent with AI help. But the name “community project” is not correct. The community supplies an issue and then waits.

What a dependency on one commit queue costs

The wait is the cost, and you can measure it. I examined some issues that the v2.3.0 notes thank people for:

• Issue 297: a filesystem request. A person filed it on 2024-12-10. The maintainers closed it on 2026-10-29. That is 688 days.
• Issue 519: a copy tool for the filesystem server. 653 days.
• Issue 4448: a hardcoded 30-second fetch timeout. A person filed it on 2026-07-01 and the maintainers closed it 120 days later.
• Issue 5184: a bug in the head and tail commands. 9 days, but cliffhall filed that ticket himself. The outsider’s pull request for the same bug (#4178, by pragnyanramtha) waited 156 days.

These four survived, so they are not the rate. The whole set is the search API’s 316 issues closed between 11 October and 4 November: 172 completed, 136 not planned, 8 duplicates. 138 of them closed on 19 October, the day v2.0.0 shipped: median age 454 days, 128 not planned. The other 178 closed in a median of 7.4 days, mostly as completed. The long waits are one backlog sweep; a request opened after 11 October closed in a median of 3.8 days.

Churn is the other cost. One person ships 88 commits in the week to 11 November, 86 of them his, so your pinned version changes quickly. But “latest” is a bad pointer for a production agent when the repository ships a release every three to eight days.

I measured the tool-list cost of these servers in an earlier post. You pay that on every request. You pay this cost once, on the day you need a fix nobody on the queue wants to write.

How to count the official MCP servers’ commits yourself

All the numbers above come from the GitHub REST API. A few calls need no token. The limit without a token is 60 calls an hour.

A=https://api.github.com/repos/modelcontextprotocol/servers

Count the commits of each author in one release. The compare API gives 100 commits per page.
for p in 1 2; do curl -s "$A/compare/v2.2.0...v2.3.0?per_page=100&page=$p" | jq -r '.commits[].author.login'; done | sort | uniq -c
Count the change lines in the release notes.
curl -s "$A/releases/tags/v2.3.0" | jq -r .body > notes.md grep -cE '^\ . by @.* in https' notes.md 

The first command printed 153 for cliffhall and 3 for github-actions[bot]. The second command printed 74.

The lifetime number needs one more step. The contributors endpoint returns 100 names per page at most. One call with per_page=100 gives the first 100 contributors. These contributors hold 3,509 commits. cliffhall wrote 1,122 of them, or 32.0 percent.

for p in 1 2 3 4 5; do curl -s "$A/contributors?per_page=100&page=$p" | jq -r '.[] | "\(.login) \(.contributions)"'; done | awk 'NR==1{a=$1;n=$2} {t+=$2} END{print NR, t, a, n, n/t}' 

Five pages give 427 contributors and 4,402 commits. The same account has 1,122 commits, or 25.5 percent. The branch holds 5,106 commits, so the lifetime number is 22.0 percent (1,122 of 5,106). The recent number is 97 percent.

What a wide project looks like next to it

vLLM published its v0.33.0rc3 release notes on 2 November. The notes say “927 commits from 389 contributors (122 new)”.

CONTRIBUTING calls the MCP servers “reference implementations, meant to show how each part of the protocol is used, not general-purpose products.” You read reference code. You copy it. You run vLLM. Do you treat the reference servers as a product? Then the one-queue risk applies. Do you treat them as a textbook? Then the risk is mostly not there.

What I check before I depend on a reference server

First, count the authors of the last five releases, as above. One name has more than 90 percent of the commits? Then the fix queue follows that person’s calendar.

Second, read the contribution policy. In this repository the maintainers close your pull request. Do you need a fix this week? Then make a fork. Do not send a patch upstream.

Third, find out who can publish. Writing and publishing are different powers. The npm registry lists six maintainer accounts for the filesystem package. Its 2.2.0 package came from a GitHub Actions trusted publisher at 21:36 UTC on 4 November, about eight minutes after cliffhall published release v2.3.0. Six accounts can publish. One account pressed the button.

curl -s https://registry.npmjs.org/@modelcontextprotocol/server-filesystem | jq '.maintainers | length' 

It prints 6.

Fourth, pin the exact version from the release table. Example: @modelcontextprotocol/server-filesystem@2.3.0.

Fifth, read the LICENSE file. It says the project moves from MIT to Apache-2.0, and both licenses let you fork.

Mettons you copy the one server you use into your own repository. Then you own that code. A maintainer who ships 88 commits in a week is no longer your problem. I do this for all code that sits between an agent and my files.