# A WebMCP registration is not an execution

Canonical: https://mudpie.ai/blog/registration-is-not-execution/
Breadcrumb: [Home](https://mudpie.ai/) / [Field notes](https://mudpie.ai/blog/) / [A WebMCP registration is not an execution](https://mudpie.ai/blog/registration-is-not-execution/)
Author: Ali Abouelatta (https://mudpie.ai/authors/ali-abouelatta/)
Published: 2026-09-19
Updated: 2026-09-19
Research type: Original analysis of archived observations
Method: Computed from the 6,934 public directory records dated September 3–4, 2026. Public and local DATA payloads matched on September 18. No new tool execution or organic usage measurement.

A tool showing up in a directory does not mean an agent used it.

Here, a registration or named-tool observation means evidence recorded by the September snapshot. It is not a tool invocation or a completed customer task.

That sounds obvious. It is also the easiest distinction to lose when a dataset is full of impressive names, platform labels, and clean status badges.

The archived [Mudpie WebMCP directory](https://mudpie.ai/webmcp/) is useful precisely because it makes the distinction visible. The snapshot contains 6,934 records dated September 3 and 4, 2026. The `tl` field contains at least one non-empty tool name on 3,763 records, or 54.3%. The source `live` label appears on 2,236 records, or 32.2%.

Neither number is an execution number.

The first is a named-tool listing count. The second is a status count defined by the source snapshot. The embedded records do not contain a call ledger, a successful task outcome, or a count of unique agents. The names tell us what was recorded as visible or present during the source process. They do not tell us whether any agent selected a tool, whether a call succeeded, or whether a human completed the task afterward.

The cross-tab makes this hard to wave away.

| Source status | Records | With named tools | Coverage |
|---|---:|---:|---:|
| `live` | 2,236 | 2,236 | 100.0% |
| `code-unenrolled` | 1,336 | 1,328 | 99.4% |
| `live-polyfill` | 184 | 184 | 100.0% |
| `bridge-primed` | 421 | 13 | 3.1% |
| `none` | 1,970 | 2 | 0.1% |
| `token-idle` | 101 | 0 | 0.0% |

The `code-unenrolled` row is the cleanest example. Almost every record in that group has names in `tl`, but the status itself says “Tools, no trial token.” A browser may have code capable of registering tools while the normal visitor does not receive the conditions required for those tools to be exposed. Counting those 1,328 records as successful agent access would turn a capability observation into a product claim.

The reverse mismatch is also real. Two records under `none` still contain seven named-tool incidences: [zkawa.com](https://zkawa.com/) has five names, and [us.weberweb.com](https://us.weberweb.com/) has two. That does not automatically make the status wrong. It tells us the fields are measuring different things, or that the source process encountered an exception. A good report keeps the exception instead of forcing every field into one funnel.

The same applies to `live-polyfill`. All 184 records in that status have names, but “polyfill” is not the same claim as native browser execution. It is a different implementation state. `token-idle` goes the other way: 101 records, no named tools. The presence of a token-like signal is not equivalent to a tool list.

There is a second measurement problem hiding inside the tool list itself. The generator caps visible names at 26. In the archive, 27 records have raw `tl.length === 26`; 26 of those have `tc > 26`. The largest `tc` is 60. That means exact-name frequencies are lower bounds for those capped records.

The cap is not the only data-integrity exception. The analysis counts each exact name once per domain for frequency purposes, but three records repeat names inside their raw list. [airvio.co](https://airvio.co/) has 26 visible entries but only 13 unique exact names, with each repeated twice. [mysoftco.com](https://mysoftco.com/) has 24 visible entries but two unique names, each repeated 12 times. [the-online.com](https://the-online.com/) has eight visible entries but two unique names, each repeated four times.

Those exceptions do not make the directory useless. They define what it can support. The archive has 30,452 domain-tool incidences after per-domain deduplication and 5,166 unique exact names. The ten most common names account for 19,881 of those incidences, or 65.3%. That is a useful description of the recorded vocabulary. It is not a claim that those tools were called 19,881 times.

This is where product analytics usually goes wrong. A team sees a page load, a registration event, or a tool list and gives it the language of use. Then the denominator silently changes. “Sites with tools” becomes “sites used by agents.” “Tools exposed” becomes “agent actions.” “A call succeeded in QA” becomes “customers completed the workflow.” The numbers may all be true individually and still produce a false conclusion together.

The reader decision is straightforward: keep the funnel split.

1. **Reachability:** did the source process reach the record and retain a dated row?
2. **Capability:** did it record a token, code path, or named tool list?
3. **Exposure:** would the intended browser/client actually see the tools under the stated status?
4. **Execution:** did a client make a tool call, and did the call return successfully?
5. **Outcome:** did the task finish, and was the result useful to the person or agent?

Only the last two stages support a claim about use. Even then, the unit matters. A call is not a unique agent. A successful request is not a conversion. A QA replay is not voluntary adoption.

If you publish a directory, call it what it is: a dated capability census. Show the observation date, the status, the visible names, the total count field, and the fields that are missing or capped. If you run the product, add a separate execution ledger with an explicit call identifier, outcome, task context, and exclusion rules for controlled tests.

The archive has zero exact duplicate domains and zero case-insensitive duplicate domain groups, which is good. It also has 903 blank or missing `tc` fields, 6,742 blank categories, and 6,633 blank ranks. Data quality is not binary; the right response is to publish the limits beside the count.

**Decision:** use this snapshot to describe what was recorded as available or visible on dated pages. Do not use it to claim that agents used those tools. For that claim, measure execution separately.

## Sources and method

- Public source snapshot: [Mudpie WebMCP directory](https://mudpie.ai/webmcp/).
- Local calculation: the embedded `const DATA=[...]` records, with raw `tl.length` kept separate from per-domain unique exact-name counts.
- The local public-source copy and the served snapshot have identical DATA JSON SHA-256: `d7a86dfec2ce5e500da231ef8a735b214f2d3e5fe1f9ac469cf4176205c92f2a`.
- The analysis did not visit or scan the linked domains. The record links above are generated from each record's `u` field for auditability.
- Status labels, tool names, missing fields, and cap behavior are reported as historical source data, not as current product behavior.


## Author disclosure

I cofound Lazyweb and publish Mudpie. This is an owner-written publication, not an independent testing organization. Research notes distinguish observations, sourced reporting and editorial judgment.