Three Checks Before Your Agent Commits to a Dependency

When an agent workflow selects a service dependency at runtime, it is operating against a registry that has grown faster than the services in it have. Registering an endpoint costs little: set up a server, submit the URL, done. Keeping that server running costs ongoing money, maintenance, and attention. The two processes are decoupled, which is why a registry entry tells you almost nothing about the service it describes.

Registry entries typically expose the same fields: endpoint URL, tool list, and a description the operator wrote. None of those fields indicate whether the server is running today, whether it has any external customers, or whether anyone other than the operator has tested it in production. The filtering layer that human API directories provide through star ratings, review counts, and uptime histories does not exist yet in agent registries.

Three signals work as automated filters. Each is computable before you write a line of integration code. Each catches a different class of dead or unreliable endpoint.

Liveness

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

The implication is direct: roughly half of what is listed in an MCP registry will not answer your first integration test. 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 the registry entry is irrelevant.

Run this check at dependency registration time, not at every call. Cache a positive result with a time-to-live short enough to catch servers that go dark between registrations; a server that responds today may not respond next week. Treat a failed liveness check as a hard stop. Do not move to the next two checks on a server that does not respond, and do not assume the server is temporarily down unless you have independent evidence of that.

Practical implementation: send a GET or POST to the server's tools/list endpoint with a standard MCP envelope. Parse the response for a valid tool array. Flag the server as unresponsive if the connection is refused, if it times out, or if the response does not parse as expected MCP JSON. Log the result with a timestamp; you will want the cache history when debugging a workflow that selected a dependency from a stale registration.

Multi-payer presence

Of 34,696 paid endpoints listed in the index, 5,308 have more than one distinct paying buyer in the last 30 days. This is Coinbase telemetry that we ingest; it is not our own probe. The caveat is mandatory: treat this as directional evidence, not a verified transaction log.

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.

The presence of a second independent buyer changes the signal entirely. It means someone external discovered the endpoint, integrated it, and paid for it repeatedly. That chain of events cannot be faked at scale. It is the structural difference between a service with real customers and a demo that was registered because registration is cheap.

If you are not using a live index with payer data, find external evidence instead. Search developer forums, agent builder communities, and GitHub for mentions of the endpoint's host domain. Look for integration changelogs from other builders that reference the service. Any endpoint with repeat external buyers leaves traces outside its own documentation. If you cannot find any reference beyond the service's own pages, treat it as single-payer until you can confirm otherwise.

Cross-registry corroboration

1,275 hosts appear in two or more independent registries. Cross-listing means at least two registry operators, running different crawl strategies and applying independent judgment, both chose to list the same host. It does not prove the service works, but it is evidence the service exists beyond a single signup flow.

The check is useful because it is cheap and fast. Search the endpoint's host domain across the MCP registry, the Virtuals protocol registry, and any agent marketplace you use. Two independent listings are better than one; three are better than two. A host that appears in only one registry could be a legitimate service that other operators have not yet indexed, or it could be a test endpoint that no one outside the operator's team has found. The two are hard to distinguish from the listing alone, which is why corroboration matters as a secondary signal, not a primary disqualifier.

Applying all three in sequence

Run the checks in this order and stop when one fails:

1. Send a tools/list request. Require a valid response with at least one tool listed. If it fails, stop. 2. Check your payer data source or search for external evidence of independent buyers. If you find none, flag for manual review before proceeding. 3. Search at least two independent registries for the host. If it appears in only one, note that as a risk factor and proceed with extra scrutiny on the first two checks.

Cache results with appropriate TTLs. Liveness is perishable and worth rechecking weekly. Payer status changes more slowly and can be cached for days. Cross-registry presence is the most stable of the three and changes least frequently.

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 is the fraction of the registry that has demonstrated it can run, that someone external has paid for, and that multiple operators independently found worth listing.

If you are building a workflow that requires three reliable service dependencies, plan to evaluate at least fifteen to twenty candidates to find them. These checks take minutes each. A bad integration takes days to untangle. The time spent at the filter stage returns in multiples.

These checks do not replace evaluating tool schemas, testing with sample inputs, or monitoring uptime once in production. They screen for existence and basic commercial validation. That is the starting point.