Methodology

How we check services, what the results mean, and what they cannot tell you.

What we publish

Only objective data: our own measurements, operators' statements paraphrased with a link to the source, and computed figures shown with their method and coverage. We do not rate, rank or recommend services.

Checks

Check What it does

Availability One unpaid GET or HEAD request, without credentials, usually hourly. We record the HTTP status and the time until response headers arrive. The response body is not read.

Documentation, API schema One GET request, usually daily. The body (up to 2 MB) is normalised and hashed (content-hash/2), so a later difference is recorded as a detected change. We keep a private copy of the readable text of each version (text-extract/1) and publish only an automated comparison with the previous version (content-diff/1): lines added and removed, and price-like values that appeared or disappeared. A small AI model then labels the type of change from the changed lines only (triage-ai/1: pricing, access, interface, documentation or cosmetic); the label is shown as automated until a person reviews it. After a pricing or access change, each operator statement that cites the page is re-checked against its current text (upkeep/1): re-confirmed with the date, replaced by the operator's exact words (a quote that must appear on the page), or marked as no longer stated. Earlier statements are kept. Apart from those quotes, page text is never republished.

Check	What it does
Availability	One unpaid `GET` or `HEAD` request, without credentials, usually hourly. We record the HTTP status and the time until response headers arrive. The response body is not read.
Documentation, API schema	One `GET` request, usually daily. The body (up to 2 MB) is normalised and hashed (`content-hash/2`), so a later difference is recorded as a detected change. We keep a private copy of the readable text of each version (`text-extract/1`) and publish only an automated comparison with the previous version (`content-diff/1`): lines added and removed, and price-like values that appeared or disappeared. A small AI model then labels the type of change from the changed lines only (`triage-ai/1`: pricing, access, interface, documentation or cosmetic); the label is shown as automated until a person reviews it. After a pricing or access change, each operator statement that cites the page is re-checked against its current text (`upkeep/1`): re-confirmed with the date, replaced by the operator's exact words (a quote that must appear on the page), or marked as no longer stated. Earlier statements are kept. Apart from those quotes, page text is never republished.

A check passes when the status matches what a healthy, unpaid response looks like for that operation. For an x402 endpoint that is usually 402 Payment Required: it shows the endpoint is reachable and asking for payment. It does not show that a paid call succeeds or returns useful results.

History and freshness

Counts cover a rolling 30-day window, or a clearly labelled shorter window when monitoring began more recently.
Passed, failed and missed checks are reported separately. A missed check is one that was scheduled but never ran.
A result becomes stale after two missed intervals. Stale or missing results are never shown as passing.
Listings with under 30 days of monitoring are marked limited evidence.
Since 17 October 2026, every check runs from one fixed location in eastern North America (a Cloudflare data centre there; each result records which one), so response times are comparable over time. They include the network distance from there: a service hosted far away reads slower. Earlier checks ran wherever Cloudflare scheduled them (method versions availability/1, candidate-x402/1 and /2, mcp-reach/1).
On 17 October 2026 the service was renamed from Agent Service Atlas to Agent Service Directory, and our requests now identify themselves as AgentServiceDirectoryMonitor (before: AgentServiceAtlasMonitor). Results from then on carry new method versions (availability/3, content-hash/2, candidate-x402/4, mcp-reach/3); nothing else about the checks changed.

Services from public registries

We also read public agent registries (currently x402 facilitators' public discovery lists: x402 Bazaar (Coinbase), thirdweb x402 facilitator, PayAI x402 facilitator, Ultravioleta DAO x402 facilitator) and probe every listed x402 service with one unpaid request, on a schedule that follows how much each service is used (see below). A probe passes when the response is HTTP 402 carrying a valid x402 challenge (scheme, network and recipient) on a mainnet network. These entries are not reviewed by a person and are published with their evidence so agents can filter them. Registry descriptions are not republished; payer and call counts are the registry's own figures.

We also track remote MCP servers listed in the Official MCP Registry (this data comes from the Official MCP Registry; we read it at most hourly, as it asks). For each server's latest version we check its first streamable-HTTP endpoint with one plain GET: no body, no credentials, asking for JSON only so no event stream opens, and no redirects followed (mcp-reach/3). It passes when the server answers the way an MCP endpoint does (HTTP 200, 400, 401, 403, 405 or 406): reachable, which says nothing about whether its tools work. Servers the registry marks deleted are removed.

How often we probe (`schedule/1`)

Hourly: 100 or more distinct payers in the last 30 days, as reported by the registry.
Daily: 5 to 99 payers, and every new service until it has been probed 3 times.
Weekly: fewer than 5 payers, or no usage figure.
Monthly: every probe failed for 14 days or more, or the registry has not listed the service for 7 days or more. Every service is probed at least monthly.

Each service's check interval is shown with the rule that set it (evidence.check_interval, evidence.check_interval_rule, evidence.check_interval_hours; the old name evidence.schedule_tier is served until 2027-01-17). Every change of interval is recorded, and expected and missed probes are counted against the schedule in force at the time. When a result changes between pass and fail, a weekly or monthly service is probed again within a day to confirm it. We send at most two probes to one host in any five minutes.

Operator statements

Each service from our own listing files records what its operator states about five things an agent needs before paying or taking work: payment rails, identity, reputation, settlement and dispute resolution. Entries come from the operator's own pages, with links, using a fixed vocabulary. "Not stated" means the sources are silent.

Records and corrections

Observations are never edited or deleted. A correction is stored alongside the original, and a reworded operator statement keeps its earlier version. Anyone can report a correction from a service's page.

Contact and corrections

Where to go, and what happens next.

What you need	Where	What happens
Fix details in a listing	The "Report a correction" form on that service's page	Recorded for review. Corrections are added alongside the original, never over it.
Stop us checking your service	The opt-out page	Applies straight away: we stop contacting that host.
Report a security issue	security@agentservicedirectory.com (see security.txt)	Handled by a person, as a priority.
Anything else: questions, partnerships, investors, press	hello@agentservicedirectory.com	An automatic acknowledgement, then a reply from a person.

We never use AI to reply to you, and we never publish what you send us.

What we record about visits

We count use of the site, the API and the MCP server in aggregate, to learn what is useful: which pages, endpoints and MCP tools are used, which filters (their names, not their values), whether a search found nothing, the broad family of the software making the request (from its user agent), and the referring site's domain. We keep the text of searches that find nothing, so we can find the services people are looking for. We do not store IP addresses beyond short-lived rate limiting, keys or key IDs in these counts, full URLs, or the content of your requests.

Feedback sent with the form, the API or the MCP tool send_feedback is kept as sent (kind, note, what it is about, any contact given), sent to us in a daily digest, and published only as counts by kind. A one-way hash of the sender's address together with the date enforces the daily limit and cannot be linked across days.

Terms of use

Agents and people may query the API and use the data to make decisions, with attribution to Agent Service Directory where results are shown to others. Bulk copying, mirroring or republishing the dataset requires permission. The service is a preview and is provided as is, without warranty.

Changelog

Newest first. Dates are in UTC.

17 October 2026: feedback: tell us what is missing or wrong with the MCP tool send_feedback, POST /api/v1/feedback or the form at /feedback, no key needed. Searches that find nothing now include a hint saying how. Counts by kind are on the roadmap and in /api/v1/roadmap; the messages are never published.
17 October 2026: new API keys start asd_; keys issued earlier (asa_) keep working. The header that marks a search with no results is now x-asd-empty-result.
17 October 2026: renamed Agent Service Directory, at agentservicedirectory.com. Pages on agentserviceatlas.com redirect permanently to the same path here. The API, MCP server, OpenAPI document, llms.txt and well-known files keep answering on the old domain until 2027-01-17, with Sunset and Link headers giving the new address; after that they redirect too. Contact addresses are now hello@ and security@agentservicedirectory.com (the old ones still reach us). Our requests identify themselves as AgentServiceDirectoryMonitor, so results from now on carry new method versions (availability/3, content-hash/2, candidate-x402/4, mcp-reach/3); nothing else about the checks changed. The MCP server is listed in the Official MCP Registry as com.agentservicedirectory/agent-service-directory.
17 October 2026: each service shows its check interval with the rule that set it (evidence.check_interval, evidence.check_interval_rule). evidence.schedule_tier is the old name for check_interval and is served until 2027-01-17. The tier field is labelled "Added from" (our listing files or a public registry); its values are unchanged. "Trust profile" is now "Operator statements".
17 October 2026: plainer description everywhere: "A directory of APIs, MCP servers and marketplaces for AI agents, with metrics we measure and the prices they state." The home page gives live counts and two lists, what we measure today and what we plan to add, and a new roadmap (also /api/v1/roadmap): planned, not promised, with no dates.
17 October 2026: the changelog lists the newest changes first.
17 October 2026: the home page and /api/v1/stats show checks in the last 24 hours by kind as well as overall (checks_24h_by_kind: reviewed, x402, mcp), because each kind has its own pass rule and the overall share moves when a new source is added. The status page now says services are probed within their scheduled interval (it said daily).
17 October 2026: aggregate usage counts and a note on what we record about visits: no IP addresses, keys, full URLs or request contents; searches that find nothing are kept as text.
17 October 2026: every check now runs from one fixed location in eastern North America, so response times are comparable over time (method versions availability/2, candidate-x402/3, mcp-reach/2). Each result still records the data centre it ran in.
17 October 2026: one description everywhere: "Find any agent service, and check it before you pay for it or rely on it." The home page and llms.txt now lead with what works with any agent (the MCP URL, the API and OpenAPI); the Connect page gives setup for each tool in alphabetical order, checked against each tool's documentation.
17 October 2026: probes record the payment protocols a 402 response offers (candidate-x402/2, field payment_protocols): x402, MPP (WWW-Authenticate: Payment) and L402. The request and the pass rule are unchanged.
17 October 2026: remote MCP servers from the Official MCP Registry are now tracked as discovered services (type mcp_server), checked on the same schedule with mcp-reach/1: one plain request that shows whether the endpoint answers like an MCP server, not whether its tools work. The registry is read at most hourly, as it asks; servers it marks deleted are removed. New type filter type=mcp_server.
17 October 2026: discovered services now come from four x402 facilitators' public discovery lists (the x402 Bazaar, thirdweb, PayAI and Ultravioleta DAO), about 120,000 listings before duplicates. A service listed in several is one entry; usage figures come only from a list that reports them. The definition of registry_listing.listed now matches the rule in use: listed since the start of the registry's last complete read, and always within 3 days.
17 October 2026: weekly reports (weekly-report/2): our expected hourly runs are counted from when monitoring began, discovered probes against each service's schedule, and the HTTP 402 row is labelled as counting every payment request, valid or not.
17 October 2026: discovered services are probed on a published schedule that follows usage (schedule/1): hourly with 100 or more registry payers in 30 days, daily with 5 to 99 and for new services until their third probe, weekly below that, and monthly for services failing for 14 days or no longer listed. New fields evidence.schedule_tier; expected and missed probes are counted against the schedule in force at the time. The registry is read in full about once a day, and "listed" means seen in the last completed pass. See How often we probe.
16 October 2026: preview notice strengthened on every page and in the API, OpenAPI, llms.txt and MCP descriptions: this is an unstable preview, and data, fields and tools can change or break without notice.
16 October 2026: correction: the payment-terms tracking window (payment_terms.window_start) now starts when tracking began, 16 October 2026 at 15:44 UTC; it previously showed a later time. Usage rules on the Connect page reworded.
16 October 2026: payment-terms tracking (terms-diff/1): every valid x402 payment request is reduced to its terms, and changes are counted and classified (price, network added or removed, token, receiving address, scheme, version). New column and payment_terms field; filter max_terms_changes_90d.
16 October 2026: automatic listing upkeep (upkeep/1): after a pricing or access change, each operator statement citing the page is re-checked against its current text and re-confirmed, replaced by the operator's exact words, or marked as no longer stated. Every answer must quote the page; earlier statements are kept.
16 October 2026: detected changes get an automated type label (pricing, access, interface, documentation or cosmetic; triage-ai/1, a small AI model that sees only the changed lines), marked as not reviewed. Pricing and access changes are flagged as "listing may need updating" until the listing's statements are re-checked.
16 October 2026: detected changes to reviewed services' documentation are summarised on their pages and in the API and get_changes: lines added and removed and price-like values that changed (text-extract/1, content-diff/1). We keep private copies of each version for comparison and never republish them.
16 October 2026: field dictionary at /fields and /api/v1/fields; every table heading links to its definition. The column "Checks passed (30 days)" is now "Scheduled checks passed / run (30-day window)".
16 October 2026: published usage rules for API keys, applied automatically: 24-hour suspensions for sustained rate-limit overruns or bulk copying, and the daily request limit enforced. See Connect.
16 October 2026: reviewed services show the operator's stated lowest price per call, labelled as a claim (price_source: "operator"); discovered prices are labelled "registry".
16 October 2026: public status page at /status (and /api/v1/status) with our own run record and evidence freshness. The services table column "Reliability (30 days)" is renamed "Checks passed (30 days)".
16 October 2026: robots.txt opens the API and MCP endpoint to agents' fetch tools; only form endpoints are excluded.
16 October 2026: weekly State of Agent Services reports (weekly-report/1) at /reports, /api/v1/reports and the MCP tool get_report. The first covers the week starting 19 October 2026.
16 October 2026: OpenAPI description at /openapi.json, sitemap, robots.txt and schema.org structured data; /services pages redirect agents that ask for JSON to the API.
16 October 2026: MCP server listed in the official MCP Registry as com.agentserviceatlas/agent-service-atlas.
16 October 2026: reviewed and discovered services unified in one table and one API (/api/v1/services); provider grouping and template-URL flags added. /api/v1/discovered redirects to /api/v1/services?tier=discovered.
16 October 2026: purpose tags and per-call prices added for every service; the services table shows all columns and scrolls sideways; per-address rate limits introduced.
16 October 2026: MCP server at /mcp, free API keys, referral IDs and outcome reports.
16 October 2026: preview status marked on all pages and API responses; terms of use published.
16 October 2026: discovered services and daily x402 probes added (candidate-x402/1).
16 October 2026: monitoring and catalogue launched (availability/1, content-hash/1).