Finding MCP servers stopped being the hard part some time ago. There are thousands of them, and a directory will hand you a hundred in a category before you finish reading the page.
The hard part is deciding which ones deserve a place in your agent's tool list, because every server you connect costs tool-selection accuracy, adds a trust boundary, and, if the server can write anything, adds a blast radius.
This post is the evaluation pass: seven checks worth running, a v2-readiness checklist now that the protocol has changed underneath everyone, and the exact commands that tell you what a server actually supports rather than what its README claims. If you want a starting shortlist instead, we keep one in 10 MCP servers that make your agent smarter.
Quick answer
Judge an MCP server on seven things: whether it produces outcomes or only fetches context, whether it is stateless, what happens when the agent gets it wrong, how it authenticates, how many tools it adds to your list, whether it returns typed results, and whether it is keeping up with the specification. Most of these you can verify yourself in about two minutes with curl, and you should, because a server connecting successfully tells you almost nothing about which protocol revision it really implements.
Key takeaways
- Tool count is a budget, not a feature. Every server you add competes for the model's attention when it picks a tool.
- Read-only servers are cheap to trust. Write-capable servers need a blast-radius answer before you connect them.
- A server that connects is not necessarily a modern server; client SDKs still default to legacy negotiation, so they will happily fall back without telling you.
server/discoveris the single most informative request you can send a server in 2026.- Authorization is where "it works in my host" quietly stops being true, because strict clients enforce rules lenient ones ignore.
- Annotations and structured results are the difference between an agent that reasons about a tool and one that guesses.
Start with the question a directory cannot answer
Every MCP server falls somewhere on one axis: does it bring the agent information, or does it let the agent do something?
Retrieval servers (docs, search, issue trackers, read-only database access) make an agent better informed. They are low-risk and easy to evaluate, because the worst case is a wrong answer.
Action servers (anything that writes files, runs commands, moves money, sends messages, or deploys) change the world. The worst case is not a wrong answer, it is a wrong action you have to undo. These deserve the whole checklist below. A retrieval server usually needs only the first half.
Be honest about which you are actually short of. Most agents that feel unhelpful are not short of context; they are short of the ability to finish. That is the argument we made in MCP tools should ship software, and it is the main reason to spend a tool-list slot on an action server at all.
The seven checks
1. Does it produce an outcome, or just context?
Look at the tool list, not the marketing. If every tool is a get_, list_, or search_, it is a retrieval server: useful, but it will never finish a job. If there are tools that create, run, write, or deploy, ask what the finished artifact is. For anything software-shaped, the strongest answer is a URL you can open, because that is a result a human can verify without reading a diff.
2. Is it stateless?
This became the question in 2026. The 2026-07-28 revision removed protocol-level sessions entirely: no handshake, no Mcp-Session-Id, no sticky routing. A server built on session state either has migrated or is running on borrowed time.
Statelessness is not just spec compliance, it is an operational tell. A stateless server can be load-balanced trivially and cannot lose your place when an instance recycles mid-task. A session-bound one has a shared store or sticky sessions behind it, and both are things that fail at the wrong moment.
3. What happens when the agent is wrong?
Assume the model will call the most destructive tool on the list with plausible-looking arguments, and ask what that costs you.
Good servers make this answerable. Tool annotations (readOnlyHint, destructiveHint, idempotentHint) let a host warn or gate before the call lands. Sensible defaults matter more: anything a server creates should start private, and anything it deletes should be scoped to what the agent itself made. If a server's delete tool can reach resources the agent never created, that is a design decision you are inheriting.
4. How does it authenticate, and would a strict client accept it?
For a remote server, walk the chain: an unauthenticated request should return 401 with a WWW-Authenticate header pointing at protected-resource metadata (RFC 9728), which names the authorization server, whose metadata (RFC 8414) advertises the endpoints.
Then check one detail almost nobody advertises: does the authorization response include the iss parameter (RFC 9207)? The 2026 revision hardened this because a client talking to several authorization servers needs to prove which one answered. That validation lives in the client's auth layer, not its protocol handler, so it applies no matter which protocol version gets negotiated. A server that omits iss works fine with lenient clients and fails with strict ones, which is the worst kind of bug, because it looks like a client problem.
5. How many tools does it add?
This is the check people skip, and it is the one that degrades an agent quietly.
Every tool in the list is a candidate the model weighs on every turn. Servers that expose sixty near-identical tools do not make an agent sixty times more capable; they make tool selection harder and every call slower to decide. Prefer servers with a tool surface that reads like a job description rather than an API dump. If you connect several servers, watch for name collisions and overlapping verbs: two servers that both offer search will cost you accuracy on both.
6. Does it return data, or a string that looks like data?
A tool that returns JSON stuffed into a text block forces the model to re-parse its own tool output, which it will sometimes do wrong. The structuredContent field exists so results come back as typed data, and the 2026 revision widened it to accept any JSON value rather than only objects.
A server that declares an outputSchema and returns structuredContent is telling you it was built for agents rather than adapted from an HTTP API.
7. Is it keeping up with the specification?
MCP now has a formal deprecation policy: features move active → deprecated → removed with a minimum twelve-month window. Roots, sampling, and logging entered that lifecycle in the 2026 release.
A server still built around sampling is not broken today, but it is telling you how closely its authors track the protocol. Check when it last shipped, and whether it has anything to say about 2026-07-28.
How to test a server before you trust it
You do not have to take any of this on faith. Three requests tell you most of it.
Ask what protocol revisions it speaks. This is the highest-value probe in 2026:
curl -s -X POST https://mcp.example.com \
-H 'authorization: Bearer <token>' \
-H 'content-type: application/json' \
-d '{"jsonrpc":"2.0","id":1,"method":"server/discover"}'A modern server answers with supportedVersions, its capabilities, and its identity. A pre-2026 server answers -32601 Method not found. That single response separates servers that have done the work from servers that have not, and it is worth doing precisely because your host will not tell you. Client SDKs currently default to legacy negotiation, so a v1-only server connects perfectly and nothing in your logs mentions it.
Check the authorization chain. Send an unauthenticated request and read the challenge:
curl -si https://mcp.example.com | grep -i www-authenticate
# Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource"Follow that URL, then the authorization server's metadata, and look for authorization_response_iss_parameter_supported. Its absence is not fatal, but it tells you how carefully the OAuth side was built.
Check what a `GET` returns. With valid credentials, a server that offers no server-to-client stream should answer 405, not 401:
curl -si https://mcp.example.com -H 'authorization: Bearer <token>' | head -1
# HTTP/1.1 405 Method Not AllowedA 401 to an authenticated client is a small bug with an annoying failure mode: strict clients read it as a rejected token and can loop trying to re-authenticate.
The v2-readiness checklist
| Signal | How to check | What good looks like |
|---|---|---|
| Stateless core | server/discover | Answers with supportedVersions, no session header anywhere |
| Revision support | server/discover | Lists 2026-07-28 alongside older revisions, not instead of them |
| Legacy compatibility | initialize | Still answers, so hosts that have not upgraded keep working |
| Result envelope | Any v2 call | Results carry resultType; errors keep ordinary JSON-RPC codes |
| Caching | tools/list | Returns ttlMs with a cacheScope that is private if the list varies per user |
| Typed results | tools/call | structuredContent alongside the text block |
| Routing headers | Any v2 call | Rejects requests where Mcp-Method or Mcp-Name contradict the body |
| Auth hardening | Authorization response | Returns iss; metadata advertises it |
| Deprecations | Capabilities | Does not depend on roots, sampling, or logging |
You will not find many servers that clear all nine yet. The release is days old. The checklist is more useful as a way to rank two candidates than as a pass/fail gate.
Where we land on our own checklist
It would be strange to publish this and skip ourselves, so: Server4Agent answers server/discover with every revision from 2024-11-05 through 2026-07-28, has been stateless since before the spec required it, returns structuredContent on every tool, sends ttlMs on tool lists, rejects requests whose routing headers contradict their body, and returns iss on every authorization response. Projects it creates are private until you make them public, and its delete tools are scoped to resources the agent itself created.
The gap on our own list is the Tasks extension: long-running builds and deploys still return a handle the agent polls, rather than a task the host drives. Tasks moved into a separate versioned extension in this release and no client runtime has shipped for it yet, so there is nothing to verify an implementation against.
If you want the detail on what changed in the protocol and why statelessness matters, that is MCP v2 vs MCP v1.
FAQ
How many MCP servers should I connect at once?
Fewer than you want to. Tool selection degrades as the list grows, and the damage is invisible: the agent does not announce that it picked the wrong tool. Start with the two or three that cover your actual workflow and add only when you hit a wall.
Is a server that fails the v2 checklist unsafe to use?
No. The specification keeps deprecated features working for at least twelve months, and clients fall back to the legacy handshake automatically. The checklist measures maintenance, not safety. A server that has not moved in a year is the real signal.
How do I know which protocol version my host actually negotiated?
Ask the server directly with server/discover rather than trusting the connection to tell you. Most client SDKs default to legacy negotiation and fall back silently, so a successful connection is consistent with both a modern and a pre-2026 server.
What is the single most important check?
For a read-only server, the tool count. For anything that can write, the blast radius: what the most destructive tool on the list can reach, and whether the server's defaults contain it.
Do I need to run my own MCP server?
Only if you need tools nobody offers. The protocol is simple enough that writing one is a weekend, but the maintenance cost is real now that the spec has a deprecation lifecycle to track.
Related reading
- 10 MCP servers that make your agent smarter in 2026
- MCP v2 vs MCP v1: what the 2026-07-28 spec actually changes
- What is an MCP server in AI? A clear, practical explainer
- MCP tools should do more than fetch data. They should ship software.