Three Checks Before Your Agent Commits to a Dependency

When an agent workflow selects a dependency at runtime, it is operating against a registry that has grown faster than the services in it have. The average caller cannot tell which entries are real services and which are placeholder listings, abandoned endpoints, or operators calling their own stack. The filtering layer that human API directories once provided does not exist yet at this scale.

Three signals work as automated filters. Each is computable, each catches a different class of noise.

Liveness

We probe every declared MCP server. Of 12,031 registered, 1,708 have blocked our crawler via robots.txt and were not tested. Of the 10,323 actually probed, 5,140 returned a valid response to a tools/list handshake. That is 49.8%.

This check is the most direct one your agent can run. Before registering any endpoint as a callable dependency, issue a tools/list request and require a valid JSON response listing at least one tool. If the server does not answer, nothing downstream works and it does not matter what the registry entry says.

The check takes a few hundred milliseconds. Run it at dependency registration time, not at every call. Cache a positive result with a TTL short enough to catch servers that go dark. The 49.8% figure means you can drop roughly half the field with a single probe before running any other filter. Do not skip this step on the assumption that a registry listing implies a working server.

Multi-payer presence

443,128 calls reached paid agent endpoints in the last 30 days across 33,617 listed endpoints. (This is Coinbase telemetry that we ingest; it is not our own probe.) Of those endpoints, 5,194 have more than one distinct paying buyer.

That 15.5% figure is the relevant one. An endpoint with a single payer is typically the operator calling its own service. That tells you the endpoint can receive traffic. It does not tell you that anyone other than its creator has found it worth paying for.

Look for payers greater than one. This is the structural difference between a service with customers and a demo that was registered because registration is cheap. The presence of a second buyer means someone external evaluated the service and paid to use it. That is a signal nothing in the registry metadata itself can replicate.

Cross-registry corroboration

1,262 hosts appear in two or more independent registries. The check is useful precisely because it is cheap. Cross-listing means the host was discovered independently by at least two registry operators with different crawl strategies. It does not prove the service works, but it is evidence the service exists beyond a single registry's self-signup flow.

When you are evaluating an unfamiliar endpoint, cross-registry presence is a reasonable first filter before investing engineering time in integration. A listing that appears only in one registry could be a service that other registries chose not to include, or it could be a test endpoint whose creator never needed broader distribution. The two are hard to distinguish from the listing alone.

Applying all three

Before hard-coding any endpoint into a workflow, run the three checks in sequence. Probe tools/list. Query your registry layer for payers greater than one. Check whether the host appears in more than one source. Cache the results with appropriate TTLs: liveness is perishable; payer status and cross-registry presence change more slowly.

The intersection of all three is small. Many endpoints fail at liveness. Of those that pass, fewer than one in six has a second buyer. Of those, a fraction appear in multiple registries. The set that clears all three checks is the fraction of the registry that has demonstrated it can run, that someone external paid for, and that multiple registry operators independently found.

These checks do not substitute for evaluating tool schemas, testing sample calls, or monitoring uptime in production. They screen for existence and basic commercial viability. That is the starting point, not the finishing line.