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.
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.
| Case | Meaning | In the example "remote-filesystem" |
|---|---|---|
| Self-declared | What the manifest says, recorded on the stated day. | Transports stdio, collected on 6 August 2026 |
| Derived | Formed from raw values by a published rule. | Execution location "local", because stdio is not an HTTP transport |
| Confirmed absent | The field is present in the manifest and empty. | Required secret variables: empty, from which "no" is derived |
| Not collected | The 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 |
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.
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?
| Execution location | no secret declared | secret declared |
|---|---|---|
| remote | 16,169 (90.9%) | 1,620 (9.1%) |
| local | 10,365 (75.9%) | 3,285 (24.1%) |
| total | 26,534 | 4,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.
The raw values first. The entry lists one package (
npm:remote-filesystem-mcp-server, version 0.1.5) with the transportstdio, 8 environment variables and the repository URLhttps://github.com/pulsemcp/mcp-servers, all self-declared, collected on 6 August 2026. That is the foundation; everything else is formed from it.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_KEYas secret but not as required, andGCS_BUCKETas 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_CREDENTIALSis a path to a key file, but it does not carry the formatfilepath.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.
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.
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.
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:
- No fetch of the addresses in an entry. Neither the repository URL nor a remote endpoint nor a package index is opened. "Repository URL listed" says that an address stands in the manifest, nothing else.
- No score, no ranking by popularity. The list sorts by "Recently updated", by name, by "New in the registry" or by the number of documented fields. There is no popularity order, because the registry counts no downloads of the packages.
- No compatibility promise. Whether a server works with a particular client is declared by no manifest. The client pages describe the shape of the configuration file, not the suitability of a server.
- The field of use is computed, not reported. It arises from terms in the vendor description, matched on word boundaries. The field Payments matches payment, payments, invoice, invoices, invoicing, checkout, stripe, paypal, payouts, subscriptions. A server whose description mentions "invoices" lands there even if it only reads them. The topic pages name the search patterns of every field.
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.
- Stock, distribution of the single-valued properties, fields of use and versions
curl -s https://api.tracevero.com/v1/kennzahlen - 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" - The published derivation rules with their version
curl -s https://api.tracevero.com/v1/regeln - 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 - The search patterns of the field of use Payments
curl -s https://tracevero.de/themen/einsatz-zahlung