Best MCP Servers: 53 Tested, 14 Answered [2026]

We called 53 public MCP endpoints between 24 July and 13 August 2026. Fourteen answered an anonymous tools/list and exposed 288 tools between them. This page ranks those 14 on what they returned to us, not on GitHub stars, commit activity, or how long they have been listed somewhere.

The rubric is published below the table, along with the tool names each server handed back, so you can check the ranking instead of trusting it. Every roundup we could find ranks on popularity signals. None of them called the servers.

TL;DR:

• Fourteen of 53 endpoints answered anonymously. Thirty refused with a 401 or 403, which is the most common outcome by a wide margin and is not a fault.
• The median server exposed 4.5 tools. The range ran from 2 to 213, and the top of that range is one server, not a trend.
• All 14 shipped descriptions on their tools. The spec marks five fields on a tool object as optional and does not mark description that way [1].
• Tool count is not a quality score. A large surface costs the client context on every request, so more tools is a trade rather than a win.

How did we rank these MCP servers?

By four things we could read directly out of a response, and nothing else. Each server got one JSON-RPC initialize call followed by one tools/list call from the same code path that runs on every submission to this board. What came back is the entire basis for the ordering, and anything we could not read from a response is absent from it.

The rubric, in full:

1. Did it answer an anonymous tools/list? If it required credentials, it is not in the table. That is a fact about our request, not a judgment about the server.
2. How many tools did it expose? Counted from the response, following nextCursor when present, because tools/list supports pagination and stopping at the first page silently undercounts [1].
3. Did the tools carry descriptions? Read per tool from the description field.
4. Which protocol revision did it negotiate? Taken from the initialize result, not from documentation.

What is deliberately not in the rubric: popularity, stars, install counts, uptime, and anything about security or data handling. We connected to these servers once. We have not audited anyone's code or permissions, and a list like this cannot tell you whether a server is safe to run.

Response time is also absent, and that one is a measurement problem rather than a policy. Our own figures were collected across one consumer connection running requests back to back, which measures our afternoon as much as anyone's server. Publishing that as an ecosystem number would be dressing up a fact about our test rig.

Which MCP servers answered, and what did they expose?

Fourteen servers, ordered by the number of tools each returned on its most recent check. The endpoint column is the exact address we called, because a surprising share of "broken server" reports are a wrong path rather than a broken server.

The tool names are the part worth reading, because they tell you what a server is for far faster than its description does. Context7 returned resolve-library-id and query-docs. DeepWiki returned ask_question, read_wiki_contents and read_wiki_structure. Microsoft Learn returned microsoft_docs_search, microsoft_code_sample_search and microsoft_docs_fetch. Three documentation servers, three near-identical jobs, three completely different vocabularies.

Every date in that table is the date we checked. We test once and do not re-test on a schedule, so none of it describes what any of these servers is doing right now.

What does a large tool count actually tell you?

Less than the number suggests, and possibly the opposite of what you would guess. The median across the 14 was 4.5 tools. One server returned 213, which is more than the other 13 combined, and treating that as "the most capable server we found" would be reading a size as a score.

A tool surface is not free. Every tool definition a server exposes has to sit in the model's context on requests where the client has that server connected, whether or not any of those tools get called. A 213-tool surface is a large standing cost paid on every request, and the servers at the bottom of that table are not less useful for returning two.

This cuts against how roundups usually present the number, our own table included, which is why it is worth stating outright: read the tool names, not the count. resolve-library-id and query-docs describe a job precisely. Two hundred and thirteen tools describe a surface area, and you will be paying for all of it.

The one place the count is genuinely informative is the shape of the distribution. Eleven of the 14 servers returned six tools or fewer. Small and specific is what the working end of this ecosystem looked like in our sample, and the outlier is a game server, not a developer tool.

Why are 39 servers missing from this list?

Because they did not answer an anonymous request, and only 4 of the 39 were broken. The full outcome distribution across all 53 endpoints, counting each address once by its most recent check:

Fifty-seven percent is the headline and it is easy to misread in both directions. A 401 or 403 means the server completed the connection, parsed the request, and made a deliberate decision about it. The spec assigns 401 to authorization being required or the token being invalid, and 403 to insufficient scopes [2]. Neither is a broken endpoint, and neither is a mark against the server.

It is equally not a mark in its favour. An auth_required result tells you a credential was wanted. It tells you nothing about how that credential is checked, which is exactly the line this page will not cross. If you want the full taxonomy of what the other outcomes mean, why an MCP server fails to connect covers the three status codes that stay ambiguous after you read them.

The practical consequence for a list like this: any roundup built by calling servers anonymously is, structurally, a list of the quarter of the ecosystem that answers strangers. That is a real limit on this page and on any page like it.

It is also why a guarded server is not excluded from a week's board. A listing records the outcome we got, and "asked for a credential" is a result rather than a failure. What it will never do is print a tool count for a server that never showed us one.

Which protocol revisions were these servers running?

Three, live at the same time, across 14 servers. Nine negotiated 2025-11-25, three negotiated 2025-03-26, and two negotiated 2025-06-18. That is not a smooth migration curve. It is a third of the connected sample sitting at least one revision behind the newest one anybody in the sample was using.

If you are writing a client, this is the number that matters more than any ranking above it. Assuming a single revision across the servers your users will connect to was wrong for 5 of the 14 we reached. The field-level detail of what changes between them, and what a real exchange returns, is in what tools/list returns.

What this ranking does not tell you

Four things, stated plainly, because a page that ranks servers invites all four assumptions:

• It is not a safety or security rating. We called an endpoint and read a response. We have not audited any server's code, its data handling, or its permissions, and no number on this page should be read as a judgment about any of that.
• It is not current. Every figure is dated to the check that produced it. Servers change, versions ship, and Context7 already returned two different versions across our two checks of it.
• It is not complete. Fifty-three endpoints is a sample gathered from public catalogs, not a census. The full corpus and method is published separately with every figure derived from the database at request time.
• It is not a popularity ranking, on purpose. If you want the servers with the most stars, several good lists already do that well. This one answers a different question.

Check your own server before you trust any list

The useful move is not to take this table's word for anything. Every claim on this page came from one initialize call and one tools/list call, and you can run exactly the same pair against any endpoint yourself with the MCP connection test. It returns the same dated record we used here: outcome, negotiated revision, tool count, tool names, and whether descriptions are present.

Two things worth reading in your own response before you ship. Check whether you are paginating, because a client that stops at the first page will undercount your tools and you will never see it from the outside. And check what an anonymous caller gets, since that is what every directory and every first-time user meets first.

If your server already answers, put it on a week's board. The listing carries exactly what your endpoint returned on the date we asked it, and when we cannot connect it carries no such claim rather than a softer one. If you have not shipped yet, how to publish an MCP server covers the registry steps and the part the tutorials skip.

Sources

1. Model Context Protocol specification 2025-11-25, Tools
2. Model Context Protocol specification 2025-11-25, Authorization