# What 300 MCP services declare

A corpus built to answer a prior question: before proposing capability contracts, what moving parts are actually present across a large set of real MCP services?

**The results are in [`FINDINGS.md`](FINDINGS.md).** This page describes where the data came from and what it can and cannot support.

## Cohort

`smithery-use-300-2026-08-02`. Collection captures the complete 7,601-row public Smithery registry snapshot, sorts it locally by numeric `useCount` descending with `qualifiedName` ascending as the tie-break, and retains the first 300. The manifest records the endpoint, seed, full-snapshot hash, ranking method, per-listing `useCount`, retrieval time, and source URL.

Captured: 300/300 indexed detail surfaces, 9,390 declared members (8,881 tools, 246 resources, 263 prompts), 10,891 observation records.

`useCount` is a directory-specific signal. This is a purposive cohort, not a random sample, an ecosystem census, or evidence that one entry is better maintained than another.

Duplicate listings, forks, templates, gateways, and multiple deployments are analytically important and stay in the 300. Primary results are listing-level; a separately labelled family-weighted view keeps repeated members of one family from dominating an incidence count. Neither is ecosystem prevalence.

## Two limits that bound every conclusion

**The frame cannot see host-native capabilities.** The sampling frame is *servers published to a directory*. A capability shipped as a host feature or a browser extension is invisible here, however many implementations exist. Browser and computer control is the clearest case: a near-zero count for that shape is evidence about the frame, not about the ecosystem. Reaching those shapes needs a differently constructed frame, not more analysis of this one.

**Nothing here is behavioral.** No sampled service was installed, connected, or invoked. Every figure counts declarations. A name containing `cursor` does not establish that the value is opaque; a name containing `dry_run` does not verify that effects are suppressed.

## Evidence layers

- `observations/` — content-addressed source captures and mechanical extraction. *What did the source contain at that time?*
- `derived/` — reproducible counts and measurements, always rebuildable from observations.

No derived value is written back into an observation. Rights-limited source snapshots stay in the ignored `work/` tree and are never copied into the website; public records carry facts, hashes, stable references, and rights-safe paraphrases. Collection and redistribution limits are in [`DATA-NOTICE.md`](DATA-NOTICE.md); record envelopes are in [`schema.json`](schema.json).

## Reproduce

```powershell
node scripts/research/derive-structural.js
node scripts/check-research.js
```

`check-research.js` re-derives every published measurement and compares it against the committed artifact, verifies each ledger hash against the manifest, and confirms that no member redistributes withheld source prose.