Menu

How many tools does a remote MCP server expose? The median is seven

2026-10-16MCP Checkup

When our probe reads a server's tool list, the first thing it learns is how many tools came back. Across the directory that number runs from 1 to at least 1,000. This post looks at the whole distribution, using each server's most recent list.

Who is counted

On 8 October 2026 our list held 2,982 remote MCP endpoints. For 1,903 of them we have at least one tool list, read without credentials, and those 1,903 are the population here. The other 1,079 never gave us one:

why there is no tool list endpoints
the server asked for a key first 959
the tools/list answer was not a usable JSON-RPC result 112
other: out of time, over our 2 MiB response limit, rate limited, or the name did not resolve 8

Those 1,079 are not servers with zero tools. We do not know how many tools they have. Three in ten ask for a key is about the first row.

For each of the 1,903 servers we take the latest list we read. For most of them that is from the last day or two; for 29 it is more than a week old, because the server stopped answering, or started asking for a key, after that.

The distribution

tools in the latest list servers share
0 0 0%
1 79 4%
2 to 5 683 36%
6 to 10 547 29%
11 to 20 334 18%
21 to 50 178 9%
51 to 100 56 3%
101 to 999 25 1%
1,000 or more 1 under 0.1%

The median server exposes 7 tools. A quarter expose 4 or fewer, three quarters expose 13 or fewer, and nine in ten expose 26 or fewer. 762 servers, 40 percent, expose five or fewer; 28 expose 100 or more. The mean is 14, pulled up by the long tail: the 1,903 lists hold 26,579 tools between them.

The stats page shows the same distribution in coarser buckets. It is recomputed once a day, so it can differ from these numbers by a few servers.

What zero would mean

A zero would mean the server answered tools/list with a valid, empty list. That is not the same as a server that did not answer, which has no count at all. Among the latest lists there are no zeros. Among all the lists we have stored since August there is exactly one: one server's first read came back empty, and twelve hours later it listed two tools.

The 1,000

The largest count is exactly 1,000, from one server, and it is not a limit on our side. The probe stores every tool in the answer it receives, and the count is the length of the list the server sent. What the probe does not do is ask for more. An MCP tools/list result can carry a nextCursor, which means there is another page, and we only ever read the first page. This server's answer of 1,000 tools carried one, so its real count is 1,000 or more.

Two other servers also answered with a cursor, with first pages of 50 and 60 tools. They sit in the 21 to 50 and 51 to 100 rows above, and their real counts may be higher. Every other latest list in this post was read without a cursor, except that for 22 servers the latest list predates 29 September, where our records of a cursor begin, so for those we cannot say. The call we hold back describes what else the probe does differently when a list is paged.

Descriptions do not get shorter

We also measured the description that comes with each tool. Only 13 of the 26,579 tools had none. The median description is 254 characters, and it hardly depends on how many tools the server has:

tools in the latest list servers median description per tool median description text per server
1 79 337 337
2 to 5 683 241 911
6 to 10 547 227 2,104
11 to 20 334 287 4,497
21 to 50 178 287 10,017
51 to 100 56 262 21,852
101 or more 26 217 57,300

Lengths are in characters. Because each tool keeps a description of about the same length, the text grows with the count. A server in the 6 to 10 row sends a median of about 2,100 characters of descriptions; one with more than 100 tools sends about 57,300, and that is before the input schemas.

What this means in practice

For agent builders: most servers are small. More than two thirds expose ten tools or fewer, and their descriptions add up to a few thousand characters. The tail is long, though. An agent that loads every definition from a server with more than 100 tools takes on, at the median, about 57,000 characters of descriptions before any schema. If a server's list is paged, a client that reads only the first page, as our probe does, sees only part of it. Tool counts also move: in a companion post we found that servers with more tools change them more often.

For maintainers: your server's page in the directory lists the tools from the latest list we read, with their count. If the number there is not the number you expect, the list an anonymous client receives differs from the one you see. A key, a region or a paged answer can each account for that.

How we counted

Population: the 2,982 endpoints on our list on 8 October 2026, of which 1,903 had at least one stored tool list; for each of those, the most recent list. Time: read-only queries against our production database between 13:23 and 13:30 UTC on 8 October 2026. None of the lists comes from a homepage trial run: we checked, and trial runs store no tool lists.

A tool list is one successful tools/list answer to our probe, sent without credentials. The tool count is the number of entries in that answer. A paged list is an answer that carried a nextCursor. Description length is the number of characters in the description text as the server sent it.

Known limits. We read only the first page of a paged list, so three counts are lower bounds. A tool list in an answer larger than 2 MiB is not counted at all. Servers that ask for a key are not counted, so we cannot say whether they are larger or smaller than the ones we can read. A count is what an anonymous client received at that moment; a server may show different tools to a signed-in user. The methodology page describes the probe.