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.
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.
| Detail | Meaning | In the example "uk.co.hopi/hopi" |
|---|---|---|
| Field | The key of the property or raw value that moved. | roh_transportarten, one of 31 rows |
| Value before | The value current until then; empty for a new entry. | empty, because the entry was new |
| Value after | The value the source delivered, unchanged. | streamable-http |
| Detected on | The run that found the difference, in UTC. | 2026-09-21 01:17 |
| Published on | When the row entered the stream; for the green class the same moment. | 2026-09-21 01:17 |
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.
| Number | Value | Measured against |
|---|---|---|
| Rows in 24 hours | 16,826 | published rows with a publication date inside the window |
| Rows in seven days | 82,491 | the same count over seven days |
| First seen in seven days | 2,177 | entries by the day the registry read them for the first time |
| No longer "active" in seven days | 23 | rows on the field registry status with a value after that is not "active" |
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.
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.
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.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.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.
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.
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.
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.
| Space size | Spaces | Entries in them |
|---|---|---|
| exactly one entry | 8,363 | 8,363 |
| two to nine entries | 377 | 1,074 |
| ten and more entries | 52 | 1,769 |
| together | 8,792 | 11,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:
- No total per slice. For a narrowed stream the API does not say how many rows it has, only whether it continues and from which offset. A number that cannot be measured is not printed.
- No rating of a change. A version that jumps from 1.0.0 to 2.0.0 is a row like any other.
- No fetch. A row on the field remote addresses says that the manifest names a different address than before. Whether anything answers under the new address is not stated, because the registry never opens it.
- No row without movement. A run that finds 33,977 entries unchanged leaves no trace. A stream that is empty on a given day therefore says "nothing moved" and not "nothing was read"; the last run is named by the dataset at the foot of every page.
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.
- Stock, published changes with the four windows, size classes of the namespaces
Show retrieval command
curl -s https://api.tracevero.com/v1/kennzahlen - The namespaces with at least two entries, largest first, with the rule
Show retrieval command
curl -s https://api.tracevero.com/v1/namensraeume - All change rows of the example entry
Show retrieval command
curl -s "https://api.tracevero.com/v1/aenderungen?eintrag=uk-co-hopi-hopi&grenze=200" - The example entry with source, collection date and confidence level per value
Show retrieval command
curl -s https://api.tracevero.com/v1/eintrag/mcp_server/uk-co-hopi-hopi - Missing values and start commands
Show retrieval command
curl -s https://tracevero.com/kennzahlen