Skip to content

Blog

What does an MCP server actually declare? Reading 31,439 registry entries

An MCP server declares what its manifest states in the public MCP Registry: transports, packages, environment variables, remote addresses, a version, a repository URL and a description. What it does not declare is whether it runs, what it needs outside the schema and which client it works with. Of the 31,439 MCP servers in the directory (dataset built 12 September 2026), 4,905 (15.6%) declare at least one required secret, 17,789 (56.6%) list only remote addresses or HTTP transports, 24,294 (77.3%) name a repository URL and 317 (1.0%) a path argument. This post shows how to read these numbers, and every single entry, without turning a declaration into a promise.

Published on · by tracevero · Reading time 11 minutes (2,170 words)

Three confidence levels and two ways of not knowing

Every value on an entry page names its origin in a line below it, for example "Source: MCP-Register · collected on 2026-08-06 · derived". The last word is the confidence level, and there are three of them. Self-declared means: this is what the vendor's manifest says, taken over unchanged. Derived means: tracevero formed a value from one or more raw values by a published rule, and the raw values are shown right beside it as "Original data". Manually verified appears only on values the operator has set through a logged correction. The example entry further down carries no such correction.

Next to these, there are two states that are easily confused. Confirmed absent means: the manifest contains the field, and it is empty. Not collected means: the source does not deliver the field at all. The registry keeps the two apart and never shows a missing field as "no". From an empty list of secret required variables, on the other hand, it does derive "no", with the same confidence level as from a filled one: the statement is there, after all.

The four cases and what they mean
CaseMeaningIn the example "remote-filesystem"
Self-declaredWhat the manifest says, recorded on the stated day.Transports stdio, collected on 6 August 2026
DerivedFormed from raw values by a published rule.Execution location "local", because stdio is not an HTTP transport
Confirmed absentThe field is present in the manifest and empty.Required secret variables: empty, from which "no" is derived
Not collectedThe source does not deliver the field; it is not shown as "no".None of the four properties: each is collected for all 31,439 entries
From manifest to page: five stations of a value 1. Source registry.modelcontextprotocol.io 2. Raw value self-declared, with collection date 3. Rule derivation rule, version 2, published 4. Derived value shown next to its raw value, never alone 5. Page and API HTML, JSON and CSV with the same values
Figure 1: Every derived value passes through the same five stations. Along this path only the source is fetched; an address that stands in an entry is never opened by the registry.

The decisive station in figure 1 is the third one. The rule is published, it carries a version (currently 2), and it applies without discretion. Anyone who knows the raw value and the rule can recompute every derived value. The methodology discloses every rule with its wording. That is the one promise of the registry, and it is deliberately narrow: it does not rate, it does not recommend, and it does not invent a value the source does not provide.

What the stock declares

Four of the derived properties carry exactly one value per entry. For them, the whole stock can be summed up in one number per value, and each pair of values adds up to 31,439 again. The stock figures count this distribution anew on every request; figure 2 shows the state of 12 September 2026.

Four derived properties across all entries Repository URL listed 24,294 (77.3%) Repository URL listed: 24,294 (77.3%) Execution location remote 17,789 (56.6%) Execution location remote: 17,789 (56.6%) Required secrets declared 4,905 (15.6%) Required secrets declared: 4,905 (15.6%) Path argument present 317 (1.0%) Path argument present: 317 (1.0%)
Figure 2: Share of entries with the value "yes" or "remote", measured against 31,439 MCP servers, dataset built 12 September 2026. Every bar is drawn against the same base.

The largest group is the least conspicuous: 24,294 entries (77.3%) list a repository URL. The rule says explicitly what does not follow from that: whether anything is behind the URL is not stated, because the registry never fetches it. 17,789 entries (56.6%) list only remote addresses or HTTP transports and count as "remote" under the rule. For the remaining 13,650 (43.4%), the same rule says "local".

The two small groups tell more. 4,905 entries (15.6%) declare at least one environment variable or remote endpoint header that is marked as both secret and required. The remaining 26,534 do not. That does not mean 84.4% of all servers work without credentials; it means their manifest declares none as required. A server that mentions its API key in the description but not in the schema counts as "no" here. This is why the short form on the entry page reads "No credentials listed" and not "No credentials required".

The smallest group: 317 entries (1.0%) declare a package or runtime argument or an environment variable with the format filepath. Anyone who has to hand a folder to a server will therefore rarely learn it from this format in the manifest. Whether a server expects a path anyway is stated, if anywhere, in its own documentation.

Two properties crossed: where do the secrets live?

Two single-valued properties can be set against each other, on the page through the cross-table and at the API through /v1/matrix. The question worth asking here: do remote servers declare a required secret more often than local ones?

Required secrets by execution location remote · 17,789 entries no secret declared 16,169 (90.9%) no secret declared: 16,169 (90.9%) secret declared 1,620 (9.1%) secret declared: 1,620 (9.1%) local · 13,650 entries no secret declared 10,365 (75.9%) no secret declared: 10,365 (75.9%) secret declared 3,285 (24.1%) secret declared: 3,285 (24.1%)
Figure 3: The four cells of the cross-table, each group drawn against its own total. Among the remote entries, 9.1% declare a required secret; among the local ones, 24.1%.
The cross-table in numbers
Execution locationno secret declaredsecret declared
remote16,169 (90.9%)1,620 (9.1%)
local10,365 (75.9%)3,285 (24.1%)
total26,5344,905

The numbers run against the intuition. Of the 13,650 local entries, 3,285 declare a required secret (24.1%); of the 17,789 remote ones, only 1,620 (9.1%). 67.0% of all entries with a declared required secret are local. Why this is so is not measured by the registry, and this post does not guess. Anyone who wants to pursue the question opens a cell: every cell of the cross-table leads into the filtered list, and there each entry shows the original data its value was formed from.

Reading one entry in five steps

The example is the entry com.pulsemcp/remote-filesystem, a server for files in Google Cloud Storage, retrieved on 13 September 2026. It carries no display name of its own, is small enough to read in full, and shows every case from the table above.

  1. The raw values first. The entry lists one package (npm:remote-filesystem-mcp-server, version 0.1.5) with the transport stdio, 8 environment variables and the repository URL https://github.com/pulsemcp/mcp-servers, all self-declared, collected on 6 August 2026. That is the foundation; everything else is formed from it.

  2. Then the derived values, each with its rule. Execution location "local": the rule says "remote" only when exclusively remote addresses or HTTP transports are listed, and stdio is neither. Required secrets declared "no", and this is worth a second look: the manifest marks GCS_PRIVATE_KEY as secret but not as required, and GCS_BUCKET as required but not as secret. The rule demands both marks on the same variable, so the list of secret required variables stays empty. That is no statement about the server; it is exactly what its manifest declares. Path argument present "no": according to its description, GOOGLE_APPLICATION_CREDENTIALS is a path to a key file, but it does not carry the format filepath.

  3. Read the date, not just the value. "Collected on" names the day on which the current value was recorded. If the source delivers the same value the next day, no new row is written. In the example there are four days: 6 August 2026 for the core values, 16 August 2026 for raw values introduced later, 26 August 2026 for the description and 8 September 2026 for the connection paths.

  4. Take the empty fields as information. Required secret variables, required secret headers, remote addresses, path arguments and the formats of the environment variables are shown as "confirmed absent". The only thing that follows is what the rule concludes. Which credentials the server really needs at start-up is stated, if anywhere, in its documentation and not in this registry.

  5. Finally, read the registry status as what it is. "Registry status: active" reflects what the source registry carries and is not a measurement of operation. For its entries, tracevero calls no server. Anyone who wants to know whether the server responds starts it; the client pages show how the configuration file is built and where it lives.

Seven dates around the entry "remote-filesystem" 2026-06-26 listing date (source) 2026-08-06 core values collected 2026-08-16 further raw values collected 2026-08-26 description collected 2026-09-08 connection paths collected 2026-09-12 dataset built 2026-09-13 retrieved for this post
Figure 4: The dates as the entry page writes them. Only the first comes from the source; tracevero recorded the others itself, and none of them stands in for another.

Figure 4 shows why the date sits on every value and not once on the entry. The source reports the listing on 26 June 2026; tracevero first saw the server on 6 August 2026 and recorded new raw values on three further days after that. The last run before this post saw the entry again on 12 September 2026 (API field zuletzt_geprueft), without any of the core values changing. Whoever names only a single date therefore says less than they think they do.

What the registry does not say

The limit of a measurement is part of the measurement. Four things are deliberately absent from every entry page, and reading them into it is reading it wrong:

The twelve most frequent fields of use Cryptocurrency 1,021 Cryptocurrency: 1,021 Documents 990 Documents: 990 Payments 978 Payments: 978 Finance 973 Finance: 973 Memory 966 Memory: 966 Images 697 Images: 697 Video 649 Video: 649 Email 611 Email: 611 Security 569 Security: 569 Version control 467 Version control: 467 Audio 456 Audio: 456 Social media 420 Social media: 420
Figure 5: Number of entries per field of use, 12 of 33 fields, drawn against the largest. One entry can stand in several fields, so the numbers do not add up to the stock.

Figure 5 shows the twelve largest of the 33 fields. That Cryptocurrency leads with 1,021 entries says something about the description texts in the source registry and nothing about the quality of the servers. The declared version is to be read the same way: the stock knows 1,634 distinct values, and 8,675 entries (27.6%) state "1.0.0". A version in the manifest is a statement, not a check of the package.

Anyone who wants to check beyond a single entry page will find under tools the cross-table, the gaps per property and the batch query, which looks up a whole configuration file line by line. All three count; none of them hands out a score.

Frequently asked questions

Does "No credentials listed" mean the server runs without a key?
No. It means the manifest declares no environment variable and no header as secret and required. Whether the server needs a key is stated in its documentation. The registry measures the declaration, not the need.
Why does one entry show several collection dates?
Because every raw value carries the day on which its current value was recorded, and the registry did not introduce all of its fields on the same day. A single date per entry would make older values look younger than they are.
Can I recompute the derived values myself?
Yes. The rules are published with version 2 and their wording under https://api.tracevero.com/v1/regeln, and the raw values are listed with every entry. Take both and you arrive at the same value; that is what the rules are published for.
What does "Registry status: active" mean?
The value the source registry carries for the entry. It does not say whether the server responds today. tracevero measures no operation, which is why the field is called registry status and not status.
How current are the numbers in this post?
They hold for the dataset built on 12 September 2026 and were retrieved on 13 September 2026. The stock changes daily; the commands in the sources block fetch the numbers again, and the stock figures show them continuously.

Sources and commands

All numbers in this post come from tracevero itself, dataset built 12 September 2026, retrieved on 13 September 2026. Every line names the command that fetches it again.

  1. Stock, distribution of the single-valued properties, fields of use and versions
    curl -s https://api.tracevero.com/v1/kennzahlen
  2. Execution location against declared required secrets, four cells with margins
    curl -s "https://api.tracevero.com/v1/matrix?art=mcp_server&a=ausfuehrungsort&b=zugangsdaten_erforderlich"
  3. The published derivation rules with their version
    curl -s https://api.tracevero.com/v1/regeln
  4. The example entry with source, collection date and confidence level per value
    curl -s https://api.tracevero.com/v1/eintrag/mcp_server/com-pulsemcp-remote-filesystem
  5. The search patterns of the field of use Payments
    curl -s https://tracevero.de/themen/einsatz-zahlung

All posts

tracevero · https://tracevero.com/blog/what-does-an-mcp-server-declare