Skip to content

Blog · Understand the registry

What moves in the MCP Registry: 82,491 changes in seven days, 2,177 new entries

A registry that keeps values with source and date must also say when a value moved. At tracevero that is the change stream: one row per field, per entry and per movement, with the value before and the value after. Since the first run that adds up to 1,101,444 published rows, 82,491 of them in the seven days before 21 September 2026 and 16,826 in the last 24 hours. In the same week the registry saw 2,177 entries for the first time, and for 23 the source took away the status "active". This post shows how a row comes about, what the four numbers measure, and reads an entry that received 31 rows at once.

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

A row is a value that has moved

The change stream is not a chronicle of runs but a chronicle of values. Every night tracevero fetches the public MCP Registry and compares, per entry and per field, the delivered value with the one that is current in the registry. Only if the two differ is a row created. A run that reads 33,977 entries and finds the same value everywhere leaves nothing in the stream. That is the rule behind the date "collected on" which the first post explained: it names the day the current value was recorded, and that day is exactly the date of the last row for this field.

Every row carries the same details, and none of them is a judgement. It says which field moved, what was current before and what is current after, when tracevero detected the movement and when it published it. The two moments coincide for the green class; a row that needs a review becomes visible only after the review, and the stream carries published rows only. A row is never a guess of the registry, always a value that stood like this in the source.

What a change row carries
DetailMeaningIn the example "uk.co.hopi/hopi"
FieldThe key of the property or raw value that moved.roh_transportarten, one of 31 rows
Value beforeThe value current until then; empty for a new entry.empty, because the entry was new
Value afterThe value the source delivered, unchanged.streamable-http
Detected onThe run that found the difference, in UTC.2026-09-21 01:17
Published onWhen the row entered the stream; for the green class the same moment.2026-09-21 01:17
From the source to a change row: five stations 1. Source fetched registry.modelcontextprotocol.io, one run per night 2. Value compared per field against the current value in the registry 3. Row written field, value before, value after, timestamp 4. Published immediately for the green class, otherwise after review 5. Delivered change stream, Atom feed, /v1/aenderungen
Figure 1: A row is created only at the third station, and only if the comparison yields a different value. A run that delivers the same value again leaves no trace in the stream.

The fourth station in figure 1 is the only one with a switch. A row receives a class when it is written, and the green one goes into the stream without detour. Everything else waits for a review, and until then the row is visible to nobody. This is why the API has no filter on the class: the stream knows published rows only, and a filter on a field with a single value would look like a choice. The stream can be narrowed by kind, by field and by a single entry, and each slice is available under Watch as an Atom feed without an account.

Four numbers over seven days, and what each one measures

"1,101,444 changes since the first run" proves that something is running here and answers none of the questions a reader has about it. The stock figures therefore name four numbers from the last days, and each is measured and not computed from another.

The four numbers of 21 September 2026
NumberValueMeasured against
Rows in 24 hours16,826published rows with a publication date inside the window
Rows in seven days82,491the same count over seven days
First seen in seven days2,177entries by the day the registry read them for the first time
No longer "active" in seven days23rows on the field registry status with a value after that is not "active"
The windows behind the four numbers 2026-09-14 start of the seven-day window 2026-09-20 start of the 24-hour window 2026-09-20 example entry listed according tothe source 2026-09-21 latest row of the stream, 01:17 UTC 2026-09-21 dataset built, 01:30 UTC 2026-09-21 retrieved for this post
Figure 2: The day boundaries run in UTC because the service knows no other zone. The latest row of the stream belongs to the example entry; it and the build of the dataset lie thirteen minutes apart on the morning of retrieval.

The third number is deliberately not counted from the stream. A new entry creates one row per field the source delivers; in the example further down there are 31. Counted by rows, new entries would show a multiple that depends on how many fields a manifest fills. Counted instead is the date of first sighting: 2,177 entries, which is 6.4% of the stock, in one week.

The fourth number is the smallest and the easiest to overrate. 23 entries received, within seven days, a value on the field registry status that is not "active". That is a statement of the source, not a measurement of operation: tracevero does not call any server, and a server that no longer answers but is still listed as active is not in this number. And 16,826 rows in 24 hours against 82,491 in seven days (20.4%) only say how the week was spread over its days.

A new entry, 31 rows: the example "uk.co.hopi/hopi"

The latest row of the stream on the morning of retrieval belonged to the entry uk.co.hopi/hopi, a remote server for British tax and unit calculators. The source has listed it since 20 September 2026; tracevero read it for the first time in the run of 21 September 2026 at 01:17 UTC. That is the normal case of a new entry, and it can be read in five steps.

  1. All rows at once. The stream carries 31 rows for the entry, all with the same timestamp and all with an empty value before. That is the first intake: every field the source delivers receives its first row in the same run.

  2. 5 derived values, each with its rule. Execution location "remote", because the manifest lists only a remote address and the transport streamable-http. Required secrets declared "no", path argument present "no", repository URL listed "no", each from an empty raw value. Field of use "Finance", found from terms in the description at word boundaries. Each of these values shows the raw value it was formed from.

  3. 26 self-declared values, 25 of them raw values. The version 1.1.0, the remote address https://mcp.hopi.co.uk/mcp, the description, the schema version of the raw record, the listing date and the change date of the source. 9 of the raw values are filled, 16 are empty.

  4. Take the empty rows as information. 16 rows carry "confirmed absent" as the value after: environment variables, packages, path arguments, repository. They stand in the stream because the source delivers the field and it is empty; a field the source does not deliver at all would receive no row.

  5. Keep the two dates apart. 20 September 2026 is the date of the source, a raw value like any other. 21 September 2026 is the day tracevero read the entry. Here they are one day apart; for older entries months can lie between them, because the registry did not introduce all its fields on the same day.

What the raw record reveals about the source

Besides the derived properties, the stock figures also count raw values as the source delivers them. Two of them say something about how the source itself moves. The first is the gap: where the source has stated nothing, nothing stands in the registry, and it is counted. Figure 3 shows five raw values and how often they are missing; the full table is under Gaps.

Five raw values and how often the source does not deliver them Path arguments 33,876 (99.7%) Path arguments: 33,876 (99.7%) Package identifiers 19,789 (58.2%) Package identifiers: 19,789 (58.2%) Remote addresses 12,950 (38.1%) Remote addresses: 12,950 (38.1%) Repository 7,931 (23.3%) Repository: 7,931 (23.3%) Transports 439 (1.3%) Transports: 439 (1.3%)
Figure 3: Entries without a value per raw value, measured against 33,977 delivered entries. A missing value is not a change; it creates no row until the source delivers it one day.

Transports are missing for 439 entries (1.3%), the repository for 7,931 (23.3%), path arguments for 33,876 (99.7%). None of these numbers is a change. A missing value creates no row until the source delivers it one day. Narrowing the stream to a field therefore shows exactly the entries for which the source filled this field for the first time or again.

What starts the server, according to the source not stated by the source 30,306 (89.2%) not stated by the source: 30,306 (89.2%) npx 1,449 (4.3%) npx: 1,449 (4.3%) uvx 1,284 (3.8%) uvx: 1,284 (3.8%) python 360 (1.1%) python: 360 (1.1%)
Figure 4: The four most frequent values of the raw value "runtime hints", measured against 33,977 entries; 20 further values are not shown. The largest bar is the missing value.

The second raw value is the start command from the runtime hints. 30,306 entries (89.2%) name none; 1,449 name npx, 1,284 uvx, 360 python, and 20 further values share the rest. The largest bar is the missing value: for most entries the manifest does not say what starts the server.

Where entries belong together: namespaces

Movement has a second direction too: not across time but across the stock. The identifier of an MCP server has the form namespace/name, and everything before the first slash is the namespace. The rule for it carries version 1, stands on the methodology page and applies without judgement. It explicitly does not say who owns a namespace; that is why the page is called Namespaces and not vendors.

The twelve largest namespaces ai.smithery 213 ai.smithery: 213 app.wishpool 125 app.wishpool: 125 eu.ansvar 106 eu.ansvar: 106 com.a2awire 101 com.a2awire: 101 io.usefulapi 99 io.usefulapi: 99 ai.getvda 94 ai.getvda: 94 com.mcparmory 76 com.mcparmory: 76 io.tooloracle 61 io.tooloracle: 61 com.jojapi 49 com.jojapi: 49 com.mambabuilt 47 com.mambabuilt: 47 com.thenextgennexus 43 com.thenextgennexus: 43 com.olyport 38 com.olyport: 38
Figure 5: Entries per namespace, the twelve largest of 429 spaces with at least two entries, drawn against the largest. A namespace is the part of the identifier before the first slash; the rule does not say who owns it.
How large the namespaces are
Space sizeSpacesEntries in them
exactly one entry8,3638,363
two to nine entries3771,074
ten and more entries521,769
together8,79211,206

Each column alone says something different. Counted by spaces, 95.1% hold exactly one entry; counted by entries, 15.8% lie in the 52 spaces with ten and more. The distribution counts spaces that are shown as such, and not identifiers that carry the account name of a person; that is why the sum of the entries is smaller than the stock. The largest space, ai.smithery, carries 213 entries. What that says about the space, the registry does not measure.

What the stream does not say

Four things deliberately stand in no row, and whoever reads them into it reads wrongly:

Frequently asked questions

Why are there so many rows in the stream for a new entry?
Because every field the source delivers receives its first row at the first intake, all in the same run and all with an empty value before. In the example there are 31. The number of new entries is therefore not counted from the stream but from the date of first sighting.
Does "no longer active" mean the server has been switched off?
No. It means the source no longer lists the entry as active. That is the registry status, a statement of the source registry, and not a measurement of operation. tracevero does not call any server.
Can I see whether an entry has remained unchanged?
Yes, but not in the stream, because only what has moved stands there. The entry page names the date of the last run that saw the entry, and per value the day the current value was recorded. If the two lie far apart, the value has not moved for a long time.
Why is there no filter on the class at the API?
Because the stream carries published rows only, and those are by definition booked green or released by hand. A filter on a field that can take only one value would look like a choice and would be none.
How current are the numbers in this post?
They apply to the dataset of 21 September 2026 and were retrieved on 21 September 2026. The four window numbers change with every run; the commands in the sources block pull them again, and the stock figures show them continuously.

Sources and commands

All numbers in this post come from tracevero itself, dataset of 21 September 2026, retrieved on 21 September 2026. Every line names the command that pulls it again.

  1. Stock, published changes with the four windows, size classes of the namespaces
    Show retrieval commandcurl -s https://api.tracevero.com/v1/kennzahlen
  2. The namespaces with at least two entries, largest first, with the rule
    Show retrieval commandcurl -s https://api.tracevero.com/v1/namensraeume
  3. All change rows of the example entry
    Show retrieval commandcurl -s "https://api.tracevero.com/v1/aenderungen?eintrag=uk-co-hopi-hopi&grenze=200"
  4. The example entry with source, collection date and confidence level per value
    Show retrieval commandcurl -s https://api.tracevero.com/v1/eintrag/mcp_server/uk-co-hopi-hopi
  5. Missing values and start commands
    Show retrieval commandcurl -s https://tracevero.com/kennzahlen

Put it into practice

All posts

tracevero · https://tracevero.com/blog/what-moves-in-the-mcp-registry