agenttru.st

How this works

Finding agents

Every publicly trusted TLS certificate is appended to public Certificate Transparency logs. agenttru.st reads those logs continuously, plus a historical backfill, and collects the hostnames appearing in newly issued certificates. A listed agent's own certificate can name other hosts as well — useful because a certificate need not appear in any log we read — and the ones not already among the hosts agenttru.st asks are added to them.

Each host is then asked whether it publishes an agent: its Agent Name Service (_ans) DNS record, a DNS-AID SVCB record where that question is asked, and a short list of well-known documents, starting with an agent card at /.well-known/agent-card.json. The crawler page lists every one. Hosts that are not agents are recorded as such and not asked again for a month, stretching towards three for hosts that keep giving the same answer — most of the internet is not an agent, and re-asking is the largest avoidable cost in a system like this.

What verification means

Listings separate what we checked from what the agent says about itself, and never merge the two. An agent card is written by whoever runs the agent; it is a claim.

bronze
An agent card or agents.json manifest was fetched, or an MCP server answered a handshake, over HTTPS, and the certificate validated against the public trust store for that exact hostname.
silver
Bronze, plus the served certificate matches a TLSA record published in DNS and protected by DNSSEC — so the identity is pinned by the domain owner, not only by a certificate authority.

Everything our crawlers find is checked again by this site itself before it appears here, so no single crawler can add an entry to this directory.

Identical skill lists

Many listings serve the same agent card: a self-hosted product installed on many servers, a plugin every shop on a platform carries, one operator's sites. agenttru.st compares every card's skill list with every other's — each skill's id, name and description, ignoring case, spacing and the card's own hostname, and for an MCP server that declares no skills, the tools it listed. Tags, examples and the card's own name are not compared: they are what each installation fills in. A card that declares no skills, or a server that listed no tools, is compared with nothing — and so is a list agenttru.st did not keep whole: a card declaring more skills than the 64 it records, a server whose tool list was longer than the 32 it records, or any compared text as long as the length it keeps. Two such lists can agree on what was kept and differ in what was not.

When 5 or more listings in a view of the directory declare an identical skill list, they are shown as one row, linked to a page that lists them all; fewer are shown one by one, and every listing keeps its own page. An identical skill list is a fact about the cards' text. It often means shared software or a shared template, but it does not tell us whether one operator runs them all or each is run separately, and nothing on this site says which.

Kinds of listing

The directory can be narrowed to one kind of listing. Each kind is a rule agenttru.st checks against the listing's hostname or the card it serves — a fact about a name or an address, never a judgement of what the agent does or who runs it. A listing can match more than one; its page says which, and what matched.

Certificates

Every listing shows the certificate the agent was served under, because that certificate is the whole of what bronze asserts. Two things about it are worth reading carefully.

Almost every certificate on the web is domain-validated. The authority confirmed that someone controls the hostname, and checked nothing about who that someone is. It is not a weaker kind of encryption — the cryptography is identical to the most expensive certificate sold. The difference is identity, and a domain-validated certificate establishes none. Where an authority did vet an organisation, the listing names it; on this corpus that is rare.

A wildcard certificate hides its own siblings. A certificate for *.example.com is logged as exactly that, so Certificate Transparency records the wildcard and never the hosts behind it. Discovery here rides those logs, which means an agent living under a wildcard cannot be found this way at all. When a listing shows a wildcard, it is also telling you there may be neighbours this directory will never see.

Expiry is shown because a lapsed certificate is a listing about to stop working. It is judged as of our last check, not as of today: a certificate renewed since then is not one we have seen. Nothing else is inferred from it: a short-lived certificate, issued for days rather than months, is normal practice and replaced before it lapses, so it is never flagged as expiring.

Post-quantum

A listing's Connection line says which key exchange the server the agent was reached at agreed with our checker — usually the host's own, sometimes another operator's that the host named, which the line then says. A post-quantum hybrid — X25519MLKEM768 and its relatives, which pair a classical curve with the ML-KEM key encapsulation — protects traffic recorded today from being decrypted later by a quantum computer. TLS 1.2 cannot carry one; it needs TLS 1.3.

It does not stop a future quantum attacker from impersonating a server. That needs post-quantum certificates, and publicly trusted certificate authorities may not issue them yet: the CA/Browser Forum's Baseline Requirements allow only RSA and ECDSA keys. So every listing's certificate is classical, and where we have recorded its key the listing says so — a fact about the web today, not about the operator.

What we show is what one connection from agenttru.st agreed, on the date shown. When a CDN sits in front of a host, the CDN decided it, not the operator; when the agent is served from another operator's server, that operator did. "Classical" means it was not agreed with us; it does not mean the server cannot do better. It is not a grade: nothing on this site is ranked, sorted or filtered by it.

Country

Country is hosting location: the geolocation of the IP address that actually served the agent card, falling back to a country-code domain suffix. It is not a statement about the nationality, residence, or legal jurisdiction of whoever operates the agent. An agent run by a German company on a US cloud region is listed as US.

Voting

Voting requires a GitHub sign-in. That is not for tracking — the only things it keeps from your GitHub account are its id, username and avatar link — it is because anonymous voting on a public ranking is trivially automated, which would make the rankings meaningless.

robots.txt

agenttru.st reads a site's robots.txt before the first request a visit makes to it, and honours it for every request after: the discovery documents, the card an _ans record points at, and the site icon.

To keep this crawler out entirely:

User-agent: agenttrustbot
Disallow: /

Groups are read as RFC 9309 defines them: consecutive User-agent lines share the rules that follow, and only an Allow or Disallow line ends that run. A Sitemap, Crawl-delay, Host or unrecognised line between two User-agent lines does not split them, so a rule you wrote for several crawlers at once still reaches this one. A file like the one below keeps this crawler out, along with SomeOtherBot:

User-agent: *
Sitemap: https://example.com/sitemap.xml
User-agent: SomeOtherBot
Disallow: /

A rule naming agenttrustbot takes precedence over your wildcard rule, in both directions. So you can also block everything else and still be discoverable, as long as everything we need to read is under /.well-known/:

User-agent: *
Disallow: /

User-agent: agenttrustbot
Disallow: /
Allow: /.well-known/

If your MCP endpoint, or a card your _ans record names, is at any other path, such as /mcp, add an Allow line for that path too. Otherwise we cannot verify the agent: it will not be listed, and if it already is, it will be taken down. The file above also stops us fetching this host's icon; Allow: /favicon.ico lets us fetch one served at exactly that path. A listing on a subdomain may still show your registrable domain's icon, which that domain's own robots.txt governs.

The Disallow: / has to be repeated in our group. A group that names us replaces the wildcard group rather than adding to it, so a group containing only an Allow line disallows us nothing at all.

Two things worth knowing before you add a block. A hostname whose robots.txt refuses /.well-known/agent-card.json, as Disallow: / does, and on which nothing else we may read is an agent, is not checked for itself again for 180 days, not merely skipped once, unless an endpoint its ANS record names did not answer, and other than on the rare occasion the crawler page describes. A visit made for another name, such as the icon check of a listing under your domain, still reads your robots.txt first and obeys it. And if the agent is already listed and its card is served from the listed host itself, blocking us removes the listing: the next re-check that can read your DNS records finds nothing it is permitted to read, and the entry is taken down. On a network we have been asked not to contact, no re-check reads anything, and the entry comes down after 182 days instead. If its _ans record names a card or endpoint on another host, that host's robots.txt governs it, so remove the record or block us there as well. That is deliberate — robots.txt should work as a way out of this directory, not only as a way to reduce traffic — but it means a general anti-bot rule will delist you along with everything else it blocks.

The rules are read from the host being asked, not from whoever pointed at it. An _ans record can name a card served on a different host, and that host's own robots.txt is what governs fetching it; otherwise publishing a record would be a way to have someone else crawled.

How we read it

A robots.txt that does not exist — any 4xx but 429 — means no rules, with one exception: a 403 from the robots.txt of the host we came to visit — asked directly, or where that file's own redirect leads when every hop stays on that host or its other name (www or bare) and on the same port, which RFC 9309 reads as the visited host's own file — ends that visit there, with nothing else asked of that host or its other name, although RFC 9309 would let us read it as having no rules. It is never read that way, however long it lasts. If you are listed, a check that ends this way counts as one that went unanswered, and the listing comes down only after several in a row go unanswered. A 403 from a file a redirect led to by way of any host but yours and your other name, or another port, from your other name's file when a document's redirect sends us there, or from another host's, means no rules like any other 4xx. One we cannot read means the visit ends there with nothing else asked, as RFC 9309 requires, and what happens next depends on why:

Redirects of robots.txt are followed up to five times, over https only: to any path on the same host or its www name, and to any other host only when the target is exactly /robots.txt on port 443 or 8443. A redirect we do not follow is read as a file that does not exist, which means no rules. When we reach your host on a visit to another host that named it, a redirect we decline for its port or for that visit's limit on other parties instead leaves your rules unread, and nothing they govern is fetched.

The crawler page lists what we ask for, the addresses we ask from, and how often.

Icons

A listing's icon comes from a short visit of its own, described on the crawler page. What happens when that visit learns nothing depends on whose visit it was and who stopped it:

If your registrable domain is itself listed, its own icon visit follows the first two rules; when its homepage or declared image could not be read, the icon it had is kept, and its own listing does not ask it again for 30 days. A listing under it may still ask it sooner, as described in the rule above.

Being listed

agenttru.st lists services that are already published on the public internet and announced in public certificate logs, and it reads only what those services serve to anyone: their DNS records, the fixed paths the crawler page lists, and the URLs their own records, documents and redirects point it to. Nothing here involves authentication, scanning for weaknesses, or accessing anything not offered publicly.

Even so, if you operate an agent and would prefer it not be listed, request removal: once we accept it, the listing is taken down and the hostname you named is never listed again. Name every hostname that serves the agent or redirects to it, your www name included. Removal stops our checks of those hostnames as well as the listing, though a visit made for another name — one whose records, documents or redirects point at your host — can still reach it, and obeys its robots.txt, unless it is your other name's robots.txt that redirects there. A robots.txt rule also takes the listing down, with no form to read, at its next 7-day check — or later, if that check cannot look up your ANS record or your site answers 429, or after 182 days if your host is on a network we have been asked not to contact — unless your ANS record names a card or endpoint on another host. It lasts only while the rule stays: we read the file again every 180 days.