Two datasets sit behind these numbers. ChatGPT publishes no MCP server URLs, so every server we count is linked from a Claude listing: 727 MCP servers behind live listings, of which 105 list their tools without a sign-in, 575 ask for one, 39 are restricted and 8 are offline or return errors. Tool-level numbers come from our wider MCP dataset: the 425 open servers we track across every store, not only the 105 behind ChatGPT and Claude listings, with 7,777 tools, each at its latest version.
Keep servers small
The median open server behind a live listing has 6 tools, and 90% have 23 or fewer. 78 of the 105 have 10 or fewer. A few go much bigger: api.duvo.ai lists 400 and mcp.datacamp.com lists 101.
Small is a choice. Every tool adds a name, a description and an input schema that a client may put in front of the model before the user has asked for anything, and the more tools there are, the harder those descriptions have to work to tell similar tools apart. If a server grows past 20 tools, splitting it by job keeps each part easy to choose from.
Annotate honestly
Tool annotations are hints a server attaches to each tool so a client can decide, for example, when to ask the user before running it. Coverage is high in our MCP dataset: besides readOnlyHint, 86% of tools set openWorldHint and 85% set destructiveHint. The values say more than the coverage:
- readOnlyHint is true on 66% of tools. Most tools only read.
- destructiveHint is true on 9%. The spec's default is true, so a write tool that leaves it out is treated as destructive, and one that sets it to false should mean it.
- idempotentHint is set on 66% and true on 52%.
- openWorldHint, which says a tool reaches outside entities such as the web, is true on 28%.
- title, a display name for the tool, is set on only 55%.
The spec tells clients not to rely on hints from servers they don't trust, so a wrong hint costs you that trust. Mark every read-only tool readOnlyHint: true. On every tool that writes, set destructiveHint explicitly: true when it deletes or overwrites, false when it only adds. A write tool labeled read-only is worse than one with no label at all.
Say what tools take and what they return
The output schema is the gap: only 46% of servers declare one on any tool. Without one, a tool returns text and the model has to work out its shape each time. With one, the client knows the fields in advance and can check the result against them. For any tool that returns records, it is the cheapest fix on this list.
Descriptions have a median length of 350 characters, and the longest 10% run past 1,102. A good one says what the tool does, when to use it instead of its neighbors, and what it needs. Past a few hundred characters, the extra words usually belong in parameter descriptions.
Tools take a median of 3 parameters (7 at the 90th percentile); 7% take none, and 67% mark at least one as required. The names repeat across servers: limit on 211 servers, query on 187 servers, name on 103 servers, id on 76 servers and category on 70 servers. Use the names models see everywhere. A list tool with limit and offset needs no explaining.
Answer the protocol version you're asked for
When a client asks for protocol version 2025-06-18, 94% of servers in our MCP dataset answer with it. 20 answer with an older version (2025-03-26: 11 and 2024-11-05: 9) and 5 with a later one (2025-11-25: 4 and 2025-11-05: 1).
The spec's rule is short. If a server supports the version the client asks for, it answers with that version; if not, it answers with one it does support, and the client decides whether to go on. Answering with a version the client didn't ask for leaves that decision to every client. Test your server with an older client as well as the newest one.
Sign-in and discoverability
575 of the 727 servers behind live listings (79%) ask for sign-in before they list their tools, and 506 of those use OAuth. That is right for anything that touches a user's data. It also means nobody outside a signed-in client can read the tool list: not a directory, not a reviewer. In the stores themselves, tools are visible for under 3% of listings.
If your server is sign-in gated, the listing has to do the work the tool list can't. Name the actions in the description, write starter prompts that use them, and keep tool names that read well when a client shows them after sign-in.
A checklist for your server
- Keep the tool count near the median (6 behind live listings, 7 in our wider MCP dataset). Past 23, your server is bigger than 90% of open servers behind live listings.
- Set readOnlyHint: true on every tool that only reads.
- Set destructiveHint explicitly on every tool that writes.
- Give each tool a title.
- Declare an outputSchema for tools that return records, and return structured content that matches it.
- Keep descriptions near 350 characters: what it does, when to use it, what it needs.
- Use common parameter names (limit, query, name and id) and mark the required ones.
- Answer with the client's protocol version when you support it.
- If you require sign-in, use OAuth and describe your tools in the listing.
The full counts are in the MCP tool design census.