How the MCP directory is built and what it leaves out

Read from the repository, nothing from anyone else

In the MCP server directory (servers published on record: 8,106), every field on a row is read from that server's own repository. Finding a repository only tells us it exists. Its name, description, stars, last push, licence, the services it reaches and the credentials it asks for all come from the repository itself, and the source link on the row goes to that repository, so checking a row lands you on the thing described.

Rows the ingest did not clear stay off the page. The candidate pile is not a public document. A directory that showed everything it found, including repositories that no longer exist, would be large and useless in the way a package search for the word server is large and useless.

The two columns that take the work

What a server can reach and which credential it needs are not in a code host's metadata. Credentials are in the README, in the configuration block every server prints so somebody can install it, and reach is in how the server describes itself. Reading them there is the same job the price ingest does on a provider's pricing page.

The credential column holds environment variable names shaped like secrets: names ending in TOKEN, KEY, SECRET, PASSWORD and a few similar words. The rule is deliberately narrow. A README that mentions an ordinary setting is not asking for a credential, and listing it would make the column noise. Placeholders such as YOUR_TOKEN or a bare API_KEY in an example are removed, because they name nothing anyone can act on.

The reach column is matched against a fixed list of services (code hosts, chat tools, databases, cloud storage, browsers, the local filesystem and so on) in two places where a server describes itself: its repository name and description, and the prefix of each credential it asks for, so a variable named after a service records that service. The example configuration in a README is deliberately not read for reach, because those blocks are often templates that name somebody else's product. The column records what the server says it touches. It does not trace what the code does.

What the page shows and in what order

The main table shows the most-starred few hundred servers. Stars are the only popularity signal held, and the page says so rather than presenting them as quality. Everything else is reachable through the directory's own search and through use-case pages, which list every published server in a group in full.

Use cases are placed by rules. A server with no use case is one no rule matched, which is not the same as a server that fits nowhere. A row also carries a state: listed, stale, archived or gone, so a repository that disappeared is marked rather than silently kept.

A strip of signals sits above the table, and each tile opens the rows behind it: servers pushed to recently, servers nobody has touched in a long time, servers that want a credential, servers that carry a licence, and servers that are unchanged copies of one starter template. Abandoned servers are listed rather than hidden, because an old server may be exactly what someone wants and they are entitled to know which kind they are installing.

What was left out, and saying so

Below the table the page prints how many repositories were read and how many were published, followed by the reasons rows were held, most common first. A filter nobody can see looks exactly like thin coverage. Stating what was looked at, what is shown and why the difference exists is the only form of curation a reader can check.

That tally comes from a summary view, not from counting the hidden rows directly. The public table is readable only where a row is published, so counting through it returns nothing held. The view exposes the totals without exposing the rows. The general rules for how facts are read and dated are on how our data is gathered.

Where the method falls short

Reading a README means trusting a README. A server whose documentation omits a credential or a service will have an incomplete row, and a server whose documentation overstates its reach will look broader than it is. The columns are a first question, not an audit.

The fixed list of services means a server that reaches something unusual shows that reach as empty. Credentials requested through a browser sign-in rather than an environment variable do not appear at all. The skills directory has different gaps, because a skill is a file rather than a server, and the post on choosing agent skills covers those.

Failures that are not evidence

A repository can fail to load for reasons that say nothing about it: the code host rate-limited the request, the network dropped, or the host returned a server error. The ingest records those as failures and waits, rather than writing the repository down as gone. Only a repository that is genuinely absent is marked that way.

The reason for the care is scale. An hour of throttling against thousands of repositories would otherwise mark a large share of live servers dead in one run, and the directory would then show readers a false picture of abandonment. Holding a row back for a real reason and holding it back because a request failed are different things, and the method keeps them apart.

Each row also carries the date it was read. Like a price elsewhere on the site, a fact about a server is a fact about the repository on that day. A server that changed its configuration since then will show the old credentials until the next read, and the date on the row tells a reader how old the reading is.