Claim and edit your listing
Almost everything in this directory was crawled from public registries and endpoints. That means most listings describe someone who never asked to be here, using whatever metadata the upstream source happened to carry. If one of them is yours, this page is how you take it over and fix it.
You are not required to do anything
- · Listings stay up whether or not you claim them.
- · Submitting a new service does not need an account.
- · We never charge for placement, ranking, or removal.
Claiming is worth it only if you want to correct what the listing says. What it gets you:
- · An Owner verified badge on every listing on that host.
- · The ability to edit the descriptive fields yourself, immediately.
- · +3 points on the grade — someone is accountable for the listing.
- · New submissions from that host skip our manual review queue.
How it works
We ask you to publish a token on the host that serves the listing. That is the entire proof. We do not accept an email, a GitHub repository, or a support request as evidence of ownership — none of them show that you can change what the endpoint actually serves, and that is the only thing this directory measures.
- 1. Sign in with GitHub at /account. We read your account id and verified email address. Nothing else, and no write access.
- 2. Enter the host — for example api.example.com. We issue a one-time token that looks like atc_R7xK2mQ9pL4vB8nT6wZ3yF5c. It is shown once.
- 3. Publish it using one of the three methods below.
- 4. Click verify. We fetch it from the public internet and the claim goes live.
Three ways to publish the token
1. Add a field to a descriptor you already serve
Best for x402 services and A2A agents — no new file. We look for a agentToolsVerify key anywhere in the JSON served at any of:
/.well-known/x402 /.well-known/agent-card.json /.well-known/agent.json
So an x402 descriptor becomes:
{
"name": "Example API",
"accepts": [ ... ],
"agentToolsVerify": "atc_R7xK2mQ9pL4vB8nT6wZ3yF5c"
}
Unknown keys are ignored by x402 and A2A clients, so this is safe to leave in place — and it has to stay, see re-checks.
2. Serve a well-known file
Best for MCP servers, which have no standard static descriptor. Serve the token as plain text at:
https://<your-host>/.well-known/agent-tools-verify.txt
The file only has to contain the token, so a single line is enough:
printf 'atc_R7xK2mQ9pL4vB8nT6wZ3yF5c\n' \ > /var/www/example/.well-known/agent-tools-verify.txt
If your web root already serves /.well-known/ — most do, for ACME — this needs no configuration change at all.
3. Add a DNS TXT record
Best when you control the domain but not the HTTP response — managed platforms, serverless hosts, anything you cannot drop a file onto.
| Type | TXT |
| Name | _agent-tools.<your-host> |
| Value | atc-verify=atc_R7xK2mQ9pL4vB8nT6wZ3yF5c |
Other TXT records on the same name are fine — we look for ours among them. Allow a few minutes for propagation before clicking verify.
What a claim covers
All three methods prove control of a host, not of one listing. One verification therefore covers every listing on that host across all three resource types. If you run twelve MCP servers under api.example.com, you verify once.
What you can edit
| Listing type | Editable fields |
|---|---|
| x402 service | name, description, category |
| MCP server | name, description, homepage_url |
| A2A agent | name, description, homepage_url, documentation_url, provider_name |
Measured fields are not editable by anyone, including us through this path. Availability, grade, latency, protocol conformance, tool count, safety verdict and on-chain demand all come from our own probes.
A directory whose subjects can edit the measurement is worth nothing to the agents reading it. If a measured value looks wrong, it is either a real fault or a bug in our probe — tell us and we will look at the probe, not at the number.
Your edits also survive re-crawls. Upstream registry metadata is usually the thing you were correcting, so once you change a field we stop overwriting it from the crawler.
Every change is recorded against your account in the listing's public edit history — who changed which field, from what, and when. That record is the main reason this can be self-service.
Leave the token in place
We re-check it every 4 hours. After three consecutive misses the claim is revoked and the badge comes down. Domains change hands, and a badge nobody re-checks is just a date. Edits you already made are kept — the content was fine, what changes is who may edit it next.
If a claim is revoked by mistake, republish the token and verify again. Nothing is held against you.
If someone else already claimed the host
We do not refuse it. Whoever can publish our token on the host today holds the claim — that is the whole premise, and refusing a transfer would only leave the directory pointing at someone who no longer controls the domain. The previous holder is emailed when a claim moves.
If you receive that email and did not expect it, check who else can publish on that host.
Listings on shared platforms
Some hosts serve listings written by unrelated authors: server.smithery.ai, glama.ai, github.com, www.npmjs.com. There the author of a listing cannot change the response, and the platform that can is not the author. Granting whole-host control to whoever proves it would hand one party the ability to edit everyone else's entries, so self-service claims are closed on those hosts.
If one of those listings is yours, email [email protected] and we will handle it by hand.
Privacy
We store your GitHub account id, login name, avatar URL and verified email address. The email is used to contact you about your claims — for instance if one is transferred away — and for nothing else. Signing in grants no permissions on its own; every edit right comes from a verified host. See /privacy.
Start
Questions, corrections, or anything the above does not cover: [email protected].