I Read All 14 Archived MCP Servers. Here's the Pattern.

In late 2025 Anthropic moved 14 of its reference MCP servers to a archived directory in modelcontextprotocol/servers. The Postgres one was the headline because it's the one teams were actually using. The others were quieter. Filesystem, Git, Slack, GitHub, Brave Search, Sequential Thinking, Memory — almost the whole "official examples" list.

I went back and read the commit history for each one. There's a pattern, and it tells you something useful about what an MCP server actually has to do once people are using it for real, not for a demo.

What got archived, and roughly when

The full archived list as of the date this post:

• postgres — archived 2026-04-08
• filesystem — archived 2026-03-21
• git — archived 2026-03-21
• github — archived 2026-03-21
• gitlab — archived 2026-03-21
• slack — archived 2026-04-02
• brave-search — archived 2026-04-02
• puppeteer — archived 2026-04-02
• google-maps — archived 2026-04-02
• gdrive — archived 2026-04-02
• memory — archived 2026-04-15
• sequentialthinking — archived 2026-04-15
• sqlite — archived 2026-04-15
• everything — archived 2026-04-15

That's a single quarter. They didn't stop existing — they're still there in the archived/ directory. Anthropic just stopped saying "use these."

The pattern, in one sentence

Every one of these was a thin wrapper around a service that exposed the service's full surface area to the model, with no permission layer in between.

Pull up the Postgres one. It's about 130 lines of TypeScript. It exposes a single tool, query, which takes a SQL string and runs it against whatever connection string the user passed at startup. It hardcodes a BEGIN TRANSACTION READ ONLY and rolls back at the end, which is the entire safety story. There's no allowlist for tables. No column masking. No row limit. No timeout. No audit log. The README doesn't make safety claims. It just says "use this."

This is fine for a demo. It's not fine when a Claude Code agent is asking it to scan your production users table at 2am.

The same pattern shows up everywhere:

• The filesystem server gives the agent any file the process can read.
• The git and github servers give the agent the same blast radius as the credentials they're handed.
• The slack server can read DMs the user can read.
• The gdrive server can read every doc the OAuth scope authorizes.

In every case, the server exposed the service's permission model directly. Whatever the underlying credential could do, the agent could do. That's the right primitive for proving the protocol works. It's the wrong primitive for production.

What "production" actually requires

If you're going to put an MCP server in front of any real system, the things you need on top of "just expose the API" are predictable. I'd argue the absence of these is exactly what got the reference servers archived rather than promoted to production-grade:

Allowlists and denylists. Some specific tables, columns, files, channels, repos — the agent should be able to touch them. Others it shouldn't. The user, not the agent, should declare which are which.

Read-only enforcement at the gateway, not at the SQL. BEGIN TRANSACTION READ ONLY works until somebody finds an INSERT that fits into a CTE or a stored procedure. The right place to enforce read-only is in the layer that parses the SQL before it reaches the database, not the database session.

PII masking. Email columns, SSN columns, salary columns. The agent doesn't need them to do most of its job. Whether or not it gets them should be a per-tool, per-user decision.

Per-query cost guards. Row limits, query timeouts, max-bytes. Agents are surprisingly happy to ask for a billion rows. The gateway should refuse before the database gets the chance.

Audit log. What did the agent run, when, against what, and what came back. This is the difference between "we let agents touch the database" and "we let agents touch the database and have receipts."

Schema change resilience. When the user renames a column, the agent shouldn't quietly start producing wrong numbers. Either fail loudly or re-resolve.

The reference servers had zero of these. That's not a criticism — they weren't trying to be production. It's an observation about why teams that started using them in production hit a wall fast enough that Anthropic chose to archive rather than maintain.

Why this matters for anyone running an MCP server

If you maintain an MCP server, the failure mode the reference implementations got hit with is going to come for you. The line between "this is cool, my team uses it" and "this is in production at a customer and a junior engineer just dropped a table" is shorter than it looks.

Three things you can do today, in order of importance:

1. Move the permission decisions out of the underlying service and into a layer you control. Don't rely on the database role being read-only. Don't rely on the OAuth scope being narrow. Encode the rules in your server.

2. Default to denying. Anything not explicitly on the allowlist should be inaccessible. The agents are going to ask for everything. They are not the right people to decide what they should be able to see.

3. Log every call with enough detail to reproduce. tool_name, arguments, result_summary, user_id, timestamp. If you ever need to answer "what did the agent do," that log is your answer.

Why I'm building QueryBear in this lane

The whole reason QueryBear exists is that we hit this wall at a previous company and ended up writing the same allowlist + audit + masking layer three times. After the third one I decided that was a product, not a side project.

The Postgres MCP server we ship is the version of modelcontextprotocol/servers/postgres with all of the production layers on top. It's still the same query tool the agent sees. The work is happening in the layer the agent doesn't see — the layer that decides whether the query runs.

That's the part the reference servers were missing. Once you've worked with the reference version for a week, you build the layer yourself. Once you've built the layer twice, you start wondering why nobody shipped it as the layer.

We did. That's the pitch.

The reference servers weren't the problem. The pattern was.

Anthropic shipped the reference servers to prove MCP works. It does. The protocol is good. The work that needs to happen is one layer up — the layer that decides what tools agents are actually allowed to use, against what data, with what guardrails.

The 14 archived servers are a useful warning, not an indictment. The next version of these servers — the production version, the ones running in actual companies — won't look like thin wrappers. They'll look like gateways with thin wrappers attached.

That's what we're betting QueryBear is, for the database side of the problem. The next step for the ecosystem is the same kind of thing for filesystems, for source control, for messaging. Not new protocols. New layers on top of MCP that make the protocol safe to ship.