How we check

Scoring

1. Each check is worth 2, 4, 7 or 10 points, by how much it matters to an AI agent.
2. Your score is the points you earned out of the points available. Half done gets half the points.
3. A blocker caps the score at 39: agents can't get in, or there's nothing to read.
4. Find, Read and Act are each scored the same way, over their own checks.

The detail, and where each rule comes from. The points and caps follow AFDocs' scoring (MIT licence), with the changes in the table. Scores from before this version aren't comparable with these, and the old ones stay in history.

1. Weighted sum: Gate 10, Must 10, High 7, Medium 4, Low 2. Score = 100 × the sum of weight × credit, divided by the sum of the weights of the checks that apply. Source: AFDocs' tiers (agent-ecosystem/afdocs, SCORING.md, MIT); OpenSSF Scorecard's weighted mean.
2. Credit: a pass is 1, a warn 0.5, a fail 0. A check over several pages or operations earns its share: 7 of 10 pages is 0.7. Source: AFDocs; Is Agentic.
3. A check that doesn't apply leaves the sum, so it can never count as a fail. The API checks apply only when we find an API or developer tool; the email checks only on email APIs. Source: Is Agentic; Lighthouse's not-applicable audits.
4. A Gate failing on your homepage or docs page caps the score at 39. Across the pages we read, a Gate that passes on 25% or fewer caps it at 39, on 50% or fewer at 59. The lowest cap wins, and the result says why in one line. Source: AFDocs' score caps; SSL Labs' grade caps.
5. Find, Read and Act each get a score out of 100 from the same formula, and the email checks count in Act. The weakest step is the lowest. Source: Euro NCAP's area scores; SSL Labs' category scores.
6. We hold the score back when we could check less than 90% of the weight that applies. Source: Legible (E21).
7. Each result shows the points earned and available, per check and per step, and how many checks passed. No letter grade. Source: Legible.
8. Each score says which scoring version made it, and v1 scores stay in history. Source: AFDocs' scoring versions.
9. Equal scores share a rank. Source: Legible (E26).

Some checks aren't counted, and the result says how many and why:

• email-specific, not counted for this domain
• not counted: we couldn't find your quickstart or SDK page
• not counted: our stand-in can't judge signed or body-key auth
• not counted: we haven't confirmed this MCP server's tools yet
• not counted: we saw MCP mentioned but can't tell it's your own server
• not counted: no OpenAPI spec to read
• not counted: no OAuth sign-in found to judge
• not counted: we didn't find an API or developer tool on this site (the API checks)

Every check's tier

Three of today's checks read more under v2:

• AI agents allowed, homepage reachable (AR-FIND-01): We read robots.txt on your site, and on your docs host if your docs live on another one, and check the rules for the paths of your homepage and docs page (RFC 9309: the longest rule wins, and an allow wins a tie). It fails if they block an agent that fetches for a person: ChatGPT-User, Claude-User, Perplexity-User. Blocking only a search bot (OAI-SearchBot, Claude-SearchBot, PerplexityBot) is half a fail. No robots.txt, or one nobody can fetch, counts as allowed. Training crawlers are shown and never scored. A fail caps your score at 39.
• Readable without JavaScript (AR-READ-01): We count the visible words in the raw HTML (no JavaScript run) of up to 8 pages: your homepage, your docs page, the docs pages we read for other checks and the pages your docs page links. A page with 150 words or more passes. One with fewer is sparse, worth half, unless it's a JavaScript shell: under 30 words, or an empty app root like <div id="root"></div>. A shell for a homepage or docs page caps your score at 39; across the pages, a share of 25% or less caps it at 39, 50% or less at 59.
• OpenAPI spec (AR-ACT-02): We look for an OpenAPI or Swagger file the same way as before. A spec your docs page, a docs page or your llms.txt links gets full credit. One we found only at a standard address (/openapi.json) or a guessed host gets half: agents used an unlinked spec far less (Ora's field report).

Before a new check counts, we run it on the companies on our boards, and every fail or partial result is checked again by a separate reviewer given only the address and the rule: an AI agent fetching with plain curl, its answer compared with ours by code. On 8 Nov 2026 that was 51 results. Seven new checks agreed in full. For two more, the reviewer found the same facts as us or missed a file plain curl finds. The skills check was fixed to recognise three more ways a skill is published, and then agreed on all 12 sites on 9 Nov.

Why another scanner gives a different number

Mostly because the two scores are made of different things. We compared our results with Ora's public results on 24 sites, on 2 Nov 2026. Each of its results has its own scan date, some of them weeks old.

• What the score is made of. Ora has about 130 checks, and about 60 count on a typical site. Many are things we don't test, like scoped permissions and idempotency keys, and about 40% of its score is a layer it calls Usability. We run 31, and most of our points are on whether an agent can find and read you. So a site that's easy to read and harder to use can score well here and lower there.
• What a gap costs. With fewer checks, each of ours counts for more. Fixing OpenAPI adds about 4 on Ora, by its own estimate. On ours it's a High check, worth 7 of the points a site is scored on; the tiers and why are in the table above.
• Part marks. Ora gives part marks: a real 404 with no guidance for agents gets half. We give half credit too, for a check that's half done. Our checks and Ora's differ, so the same site can get full marks on one and half on the other.
• What we leave out. If we saw MCP mentioned but can't tell it's your own server, we don't count it, which is 1 check or 2. That can lift a result above another scanner's, and the result says how many checks weren't counted.

Where both tools judge the same thing, the answers mostly agree. Score Ora's answers with our points and count its part marks as passes, and the two land equal or within 7 points on 19 of the 24 sites, and 10 or more apart on 5. On these three, the two tools agree on every check they share:

Across the 24 sites and the 15 checks we share, 246 answers agree. In 6 we pass and Ora fails, each one a file we can link to, like Notion's OAuth metadata on its mcp. host. In 18 we fail and Ora passes. The other 90 are part marks, or a check one side couldn't read. Of the 18, 16 are a difference in the rule: on 10, Ora passes a package it finds in a registry where we look for both an npm and a pip install in your docs, because that's what tells an agent which package is yours; on 6, Ora passes a pricing page that exists where we look for a price in its raw text. The other 2 carry a dated note on the result.

So a lower number elsewhere usually means a different mix of questions, not that either of us misread the same file. And no score here, ours or anyone's, measures whether an agent can actually use your product.

Does a higher score mean better code from an agent?

Not on what we've tested so far. On 2 Nov 2026 we gave two coding agents the same task in an empty folder: send a transactional email with a PDF attachment, in TypeScript, using the API's official SDK. Claude Code on Sonnet 5.5 and Codex CLI on GPT-5.6-sol, 5 runs each, on Resend (96), SendGrid (88) and Amazon SES (71). Nothing was sent.

• All 30 used the official package, it installed, and the PDF went in the right field.
• 29 type-checked against the real SDK's types, on one fixed config: Resend 10 of 10, SendGrid 9 of 10, Amazon SES 10 of 10. As written, 22 did: the other 8 were Codex projects, most missing @types/node.
• None opened an llms.txt, an OpenAPI file or a .well-known file. Claude looked nothing up in any of its 15 runs. Codex searched in 11 of its 15, mostly docs pages and npm.
• 4 of Claude's 5 Resend runs pinned version 4 of the SDK, with 6 current. The code still type-checked.

Three well-known APIs and one common task can't show much. It does show what these checks are: a read of the files an agent could use, not a prediction of what it will do. A harder task on smaller APIs is the next test.

Watching an agent use a site

This is built, but it isn't switched on yet: it's waiting on an API key. No run has happened.

Watch runs Claude Haiku 5.5 on one goal: get started, find the API or find pricing. It reads a page at a time without JavaScript, at most 8 pages and 90 seconds, and can only ask for this site or a link a page showed it. A redirect can take it elsewhere, and the step shows where. Pressing Run starts it, and the same site and goal reuses the last run for an hour.

Which pages it opened, how it got there, what came back and the counts all come from our code. Its reasons and its answer are the model's own words, shown as quotes, and we check that the page it names loads. It gives no verdict and doesn't touch the score. One run can differ from the next, and it isn't Claude Code or any other coding agent.

The text of those public pages goes to Anthropic, which runs the model. Nothing about you goes with it. We keep a run for that hour, and after that only a log line: the site, the goal, how it ended and how much it used. Runs aren't published.

How our scanner behaves

We fetch a handful of standard public files on behalf of the person who asked, identify ourselves and read robots.txt as a check. We don't crawl. Our scanner identifies itself as LeaderfileBot/1.0 (+https://leaderfile.vercel.app/method), and a scan stops after 27 seconds.

When a file refuses our scanner, we ask once more as a normal browser, only to tell "blocked for everyone" from "blocks automated readers".

We read llms.txt at your site root and, if your docs live on another host, at your docs root.

The small icon beside a domain comes from DuckDuckGo's icon service: your browser asks it for that domain's icon, so DuckDuckGo sees your IP address and the domain, though not which page you're on. It isn't part of any check.

For the 15 on the email API board, we read their main quickstart, their official page for each language and the agent or MCP page their docs link, all picked by hand; if a scan missed one of your pages, you can report it. For any other domain, we read your llms.txt, your docs page and up to 5 pages they link: up to 3 quickstart, getting-started, SDK or library pages, one MCP page and one auth page, never blog posts. We also try a few addresses where these files usually live: llms.txt on your docs. host and at /docs/llms.txt, OAuth metadata on your mcp., api. and docs. hosts, and OpenAPI specs on your docs., developers. and api. hosts. Those count only on a valid file, and any other answer there counts for nothing.

For a product inside a larger platform, the platform's MCP server or CLI counts when its docs show it covers the product.

The boards

The email API board is 15 email APIs, scanned on the same day by the same scanner, reading pages we picked by hand for each. The current scan is from 9 Nov 2026. A board company's result shows that scan first; a live scan reads the site as it is now. What changed between scans is in each issue, from issue 2.

The AI agent platform board is 13 companies whose own homepage calls them a platform for building or running AI agents, scanned on 9 Nov 2026. Nothing there is picked by hand: each is scanned exactly as any domain is, so its result is a live scan, with the board's dated rank beside it. The 3 email-only checks don't count there.

Each gap shows the file from the highest-scoring company that passes that check: on a board company's result, from its own board, and on any other domain, from everyone on our boards, scored on the same checks. When joint leaders both pass it, we alternate whose file we show, check by check, and the other is listed under "Also shipped by".

We check our own results. On 31 Oct 2026, the 30 board results still open from our hand check went to a separate reviewer given only the URLs and the rule, not our verdict, who fetched them with plain curl and a real browser. No result changed. Where a reviewer found something our rule doesn't read, the result carries a dated note.

The AI agent platform board went through the same before it was published: on 3 Nov 2026, all 58 of its fails, one reviewer per company. 57 agreed. The one that didn't was Dust's OpenAPI spec, which its llms.txt listed at an address our rule didn't follow. The reviewers also showed us reading a product tour where a site's llms.txt listed its API or SDK quickstart. We changed both rules the same day, for every site off the email board, and scanned the board again: Dust, StackAI, Relevance AI and Botpress went up, and nothing else moved. Where a company points to something our scan still doesn't read, the result carries a dated note.

Categories, and where you'd sit

The leaderboards cover the categories where a coding agent picks the vendor itself (Amplifying, “What Claude Code Actually Chooses”, Feb 2026). A company is on a board when its own homepage's title or description, read on the day, says it does that job, and each is on one board only. Every board's fails go through the same blind re-check before the board is public: on 9 Nov 2026, a second AI that never saw our answers re-checked 894 results on the new boards.

Any site you scan is placed the same way: if it's on a board, that board. Otherwise its homepage's title and description are matched against each category's phrases, whole phrases only, and the result shows the words that placed it, with a way to change it. If no phrase matches, we don't guess: you pick, or it's compared with everyone on our boards. "Would sit 6th of 14" places your score among the board's dated scores, counting your site. It's our maths, never a rank you hold, and never shared as one. A site placed with the email APIs is measured on the checks every site gets, since a plain scan doesn't run the 3 email-only ones.

The 31 checks

Corrections

31 Oct to 3 Nov 2026

• 3 Nov, off the email board: where a site's llms.txt listed its API or SDK quickstart, we read a product tour instead, and we skipped an OpenAPI spec listed under an OpenAPI heading in llms.txt when its address didn't end in .json or .yaml. We now read the listed quickstart first and follow that link. On the AI agent platform board, 5 checks went from fail to pass: Botpress's and StackAI's auth an agent can follow, Dust's OpenAPI spec, and Relevance AI's and StackAI's code samples. Dust, StackAI, Relevance AI and Botpress went up, and the email board didn't move.
• We compared our fails with another scanner's passes on 24 sites, and read the differences by hand. Off the board, these were misses: OAuth metadata on your mcp., api. or docs. host (we only read the site root, and an mcp. host is your own MCP server), a name split by a space, like Relevance AI, an OpenAPI spec on your docs., developers. or api. host that no page linked, or listed under an OpenAPI heading in llms.txt, an llms.txt on your docs. host or at /docs/llms.txt when your homepage leads elsewhere, docs on a dev. host, a pricing address that answers with JSON, and uv tool install or pipx install as a Python install. We now read all of them. A made-up address that refuses automated readers also gets a second try now, so that refusal alone no longer withholds a score.
• Our label said none of the 15 has WebMCP. Bird and Postmark load it from a script our check doesn't read, as do CrewAI, Vellum and Zapier off the board. No result changed: each now carries a dated note, and the label says none passes our check.
• "Worth doing" on readable pricing told quote-only sellers to publish prices. It now says that's a business decision.
• Off the board, an install on a page your llms.txt names for that language was missed, so Supabase failed on pip while its llms.txt links a Python reference that opens with it. We now read up to 2 such pages when an install is missing. Titles also now say which install we didn't find, and on how many pages.
• Off the board, a docs page that came back as markdown had its headings counted as 0, an install shown only in a page's markdown copy was missed, and SDK links could crowd out quickstarts in llms.txt. We now count markdown headings, read declared copies when an install is missing, and take quickstarts from every llms.txt first.
• Off the board, we read blog posts as if they were quickstart pages, so a site could fail on pages that aren't its docs. We now read docs links first and never blog posts.
• Off the board, any mention of an MCP server earned the MCP checks, even on a directory. It now has to be your own server; any other mention isn't counted.
• A site far from our scanner with both IPv4 and IPv6 addresses could time out within 250 ms and have its score withheld. We now give each address 2.5 seconds.
• A language tag on a markdown code block indented inside tabs or a list didn't count. It now counts at any indent.
• Off the board, we only read llms.txt at the site root, so a site with one on its docs host failed that check. We now read both, and a linked MCP page and auth page too.

Only the 3 Nov change moved a company on a board, and only on the AI agent platform board. Found another? Report it.