How to measure agent distribution: a 1,752-row WebMCP census

I checked the listed websites of 1,752 accelerator entries for native WebMCP registrations. Four roster rows exposed registrations in default Chrome. With Chrome’s experimental WebMCP features enabled, 23 roster rows exposed registrations. All four default positives appeared in both runs; 19 appeared only in the experimental run.

No tools were called. These are observations of capability exposure in two browser contexts, not users, successful tasks, or adoption.

The population was 1,586 current YC directory rows across nine cohorts and 166 current a16z Speedrun rows across three cohorts. YC rows were captured September 18, 2026; Speedrun rows were captured September 20. Both browser passes ran September 20. This is a dated directory snapshot, not a historical count of companies originally admitted to each program.

Observation	Default Chrome	Experimental features enabled
Roster rows accounted for	1,752	1,752
HTML preflight available	1,663	1,663
Assessable browser windows	1,661	1,661
Registration observed	4	23
Registration not observed in the window	1,657	1,638
Unknown: 89 preflight-unavailable + 1 runtime-unknown	90	90
Access-limited	1	1

The registration rate was 0.24% of assessable windows in default Chrome and 1.38% with experimental features enabled. Using the full roster denominator, the rates were 0.23% and 1.31%. The latter retains unknown and access-limited rows; neither calculation treats them as observed absences.

The row-level dataset lets you recalculate these counts. The 23 dated evidence pages show the tool names, URLs, browser modes and observation windows for each positive entry.

The default-positive metadata evidence preserves the passive toolsAdded metadata, including the readOnly annotations on assistant-ui's five tools, alongside the observed URLs, windows, browser provenance and saved-record hashes.

The browser belongs in the denominator

Both passes used Chrome 153.0.8010.50, fresh logged-out contexts, the same roster and the same HTTP preflight. The second pass added --enable-features=WebMCP,WebMCPTesting. Each visit observed registration events during page loading and a 1.5-second settled observation window. It did not click through the product or wait indefinitely for delayed tools.

The 19 additional observations tell us that the two contexts exposed different capabilities. They do not tell us how many people use either configuration. The runs were sequential, not a randomized experiment; a later page state can also differ from an earlier one. A single visit cannot establish that tools never appear elsewhere on a website.

A founder’s first measurement question is therefore concrete: which browser, page, account state and observation window could expose this tool? A registration percentage without those conditions is hard to interpret.

The default positives expose different kinds of work

The identity review connects each positive to its current public company and official directory entry. Three expose matching commerce tool metadata consistent with Shopify storefronts—an inferred platform attribution: Button Computer, Nine Fives, and Pocket. Their browser tools are commerce operations such as catalog search, product browsing, cart reads, policy lookup, and checkout navigation. The fourth is assistant-ui, whose tools are documentation and skills operations.

assistant-ui's registration metadata describes read-only documentation and skill operations: search docs, read a document, read an example, list skills, and read a skill.

Observed registration	Tool surface	What the observation does not establish
Button Computer	Shopify-like commerce metadata; platform attribution inferred	That a voice-AI hardware task was exposed or completed
Nine Fives	Shopify-like commerce metadata; platform attribution inferred	That RF REST, SCPI, or LLM-skill tools were registered or called
Pocket	Shopify-like commerce metadata; platform attribution inferred	That a note-taking, device, or API workflow was executed
assistant-ui	Metadata-declared read-only docs/skills tools	That a developer read a page, installed a package, or shipped an integration

This split matters because a platform can add a tool surface to a page without the company having built the underlying product workflow for that protocol. The registration event is still useful. It says something about what a browser observed on that page at that time. It does not say which product capability drove the event.

Use a five-stage measurement chain

Founders usually need five separate questions:

Reachability: was the company in the current directory and could the public page be reached?
Exposure: did the intended browser and page context load far enough to observe the surface?
Registration: did the runtime report a tool, and what name, schema, and read/write annotation did it expose?
Invocation: did an agent or client send a call with a call ID, and did the call return?
Outcome: did the task finish, did the person accept the result, and did the behavior repeat?

This census answers the first three only. It does not contain a call ledger, a successful task result, a unique-agent count, or voluntary adoption. Treating the four registrations as four users would skip two stages and change the unit halfway through the sentence.

The event names should make that separation hard to break. A useful product ledger could record:

Event	Minimum evidence	Safe claim
`registration_seen`	Page, browser mode, timestamp, tool names, source identity	This page exposed these tools to this observation context
`invocation_attempted`	Call ID, tool name, auth context, request boundary	A client attempted this call
`invocation_result`	Call ID, status, latency, error class, response boundary	The call returned with this result
`task_outcome`	Declared task, completion evidence, human/agent acceptance	This task reached the measured outcome
`repeat_use`	Privacy-safe actor/session key and repeat window	The same eligible actor used the capability again

Registration is a distribution lead. Invocation is a usage event. An outcome is a product result. A repeat is closer to adoption. None should be silently substituted for another.

What the cohort view can and cannot say

The four positives appeared in Winter 2026, Spring 2026, and Winter 2025 YC rows. None appeared in the three Speedrun groups in the complete default run. That is a description of this frozen sample. It is not evidence that one accelerator, cohort, or category is more agent-ready than another.

The denominator is a row denominator, not a company or user denominator. A directory can contain duplicate organizations across programs, stale domains, redirects, inaccessible hosts, or companies whose public page is not the place where a product capability lives. The export keeps the program, cohort, listed URL, final URL, capture date, and source record hash so a later review can revisit those boundaries.

The identity checks also matter. Nine Fives' public homepage describes RF test equipment, while its recorded tools describe a commerce storefront surface. Button Computer and Pocket have the same platform distinction. assistant-ui's docs tools line up with its public developer-library surface. These checks keep a platform registration from being credited to an unrelated product capability.

The practical founder decision

If you are deciding whether to expose a browser tool, do not set the first goal as “get registered.” Set the goal as a completed user task that requires the page's current state. Then instrument the chain around that task:

Count eligible exposures, keeping preflight failures and access limits visible.
Record registration with a dated tool/schema snapshot.
Measure invocation success separately from registration.
Define the task outcome before launch.
Track repeat use with a privacy-safe denominator.
Keep controlled QA and internal tests out of the adoption series.

If you only have a registration count, report reachability or capability exposure. If you have successful calls, report calls. If you have task completion, report task completion. Use “users” only when the underlying actor and denominator support that word.

The two browser passes make the distinction visible: changing the observation context changed the count from four to 23. Nothing in either pass measured a new user, an invoked tool, or a completed task.

Method and limits

The two passive browser passes used the fixed roster, a robots-respecting public HTTP preflight and fresh browser contexts. No login, form submission, purchase, tool invocation, or product trial was performed. Unavailable pages remain unknown. The observations cover listed homepages and their normal redirects, not every page or authenticated product surface.

The default pass ran from 21:03:29 to 21:27:21 UTC on September 20, 2026. The experimental pass ran from 21:27:50 to 21:50:53 UTC. The same 91 rows were unknown or access-limited in both modes. The exported row-level records preserve those dispositions, URLs, tool names, dates, frame origins and source hashes. Raw input schemas and private filesystem paths are omitted.

I co-founded Lazyweb, one of the SR007 entries. It went through the same passive procedure: no registration was observed in its default window, and tools were observed in its experimental window. Controlled research traffic on our own sites is kept out of the adoption series.

The public dataset and evidence directory preserve the measured result. This study does not measure agent calls, customers, revenue, task success, or which accelerator has the most agent-ready companies.