Optimizing Agentic Atlas for agents
What a six-day push from 73 to 88 taught me about making a site useful and honest to agents.
On Sunday I found is-agentic, pointed it at Agentic Atlas, and knew it was time to start grinding.
The site scored 92 out of 100. Getting it to 100 was pretty achievable, and I got there quickly. Then I found ora underneath it, ran the same site, and got a 73.
That was when it got interesting.
Six days and a slightly unreasonable number of pull requests later, Agentic Atlas is at 88 out of 100 on ora: an A, and currently #74 on its community leaderboard while ora reports roughly 54,000 sites scanned. I have probably exhausted the meaningful site-controlled improvements without adding features the product deliberately does not have. The main remaining gap is brand discovery, and a site that only went live on August 18 still has to wait for search engines to notice it.
I obviously enjoyed watching the number go up. But the score was really just the feedback loop. The useful part was seeing what happened when I treated an agent as a first-class user of the site.
The scoreboard
This was the progression over the push:
| Date | is-agentic | ora | Glama |
|---|---|---|---|
| August 22 | 92/100 | — | — |
| August 24 | — | 73/100 | 3.5/5.0 |
| August 25 | 100/100 | 76/100 | — |
| August 26 | 100/100 | 86/100 | — |
| August 27 | 100/100 | 88/100 | 4.1/5.0 |
These are point-in-time readings from different rubrics, not permanent properties of the site. The trend was useful because every scan gave me another set of claims to test as a real agent or API client.
Ora also publishes the agent’s full journey, which might be my favorite part of the whole thing. I can watch an agent move through the site and find where its model of the product diverged from mine. The public journey predates most of this push, so it does not represent the current 88. That makes it more useful as a before picture.
A readiness score is not the product. It is a very persistent user trying paths I had forgotten to test.
Agents cannot infer a contract
The first lesson was that something can be true inside the application and still be absent to an outside client. Agentic Atlas returned its API version in a response header, for example, but did not let clients request that version. From outside, it looked more like a stamp than a contract.
The same pattern showed up all over the site:
- Registry listings existed, but the origin did not name them back.
- The runbook said to notify search engines after a release, but the release pipeline did not actually do it.
- Page content had Markdown twins, but their dialect was not documented.
None of those changes made the human-facing site more impressive. They made its promises externally verifiable.
That became the through-line for the exercise. Agentic Atlas now publishes a developer entry point, discovery guides, OpenAPI, a hosted MCP server, and byte-derived Markdown. Those surfaces identify the same sealed catalog revision, so a client does not have to guess whether they describe the same release.
The boring failures were the useful ones
Some scanner findings exposed real protocol bugs hiding behind perfectly healthy browser behavior.
The MCP server once rejected Accept: */* with a 406. That header is the
default for tools like curl and fetch, so a browser looked fine while a
normal machine client failed. HEAD was similar: pages worked, but crawlers
probing them cheaply got a 405.
My favorite discovery was MCP Apps. Agentic Atlas now offers its Card as a separate UI resource: the agent gets a structured result, while a supporting host can fetch the interface for a human. There is still a network fetch, but the UI bundle does not enter the model’s context or travel with every tool result. I had no idea that path existed before this push.
This is the optimization I care about: making a product cheaper to discover, cheaper to call, and harder to misunderstand.
A scanner is also capable of being wrong
I did not implement every recommendation.
The scans looked for OAuth metadata, registration and revocation endpoints, write-operation idempotency, aggregate ratings, and a full postal address. Agentic Atlas has no authentication, accounts, write operations, collected ratings, or business address separate from my home. Adding those shapes would have made the machine-readable product less true.
So I refused them. The site states that authentication is absent, tests keep rating markup out of its structured data, and the published address stops at the country. A read-only service stays read-only.
State the absence in a machine-readable field rather than invent the feature.
A benchmark can expose a gap, but it cannot decide whether that gap is a bug, a misread, or a request for fiction. That judgment still belongs to the builder.
Six-ish days of iteration
From August 22 through August 27, I merged 94 pull requests across this push. That number only makes sense in context: I built Agentic Atlas with orchestrated background agents, dependency graphs, and a separate spec-review pass on each change. An agent-oriented product was being optimized for agent access through an agent-heavy workflow. I could keep running the loop:
- Scan the public surface.
- Reproduce each finding as a real client.
- Classify it as a bug, a misread, or a request for fiction.
- Fix what was true.
- Deploy the complete release and scan again.
The current release serves its 26-node corpus through human pages, Markdown, a 14-operation JSON API, an eight-tool MCP server, and four in-page WebMCP tools. The backend and its tests are each nearly 40,000 lines of Python, with roughly 2,800 test runs across overlapping suites. Every surface can drift. The scans gave me a way to find that drift from the outside.
The last twelve points
At 88, the main meaningful limitation is discoverability away from the site.
On August 26, Bing had not indexed agentic-atlas.dev, and the quoted brand
name returned namesakes. The sitemap is in Search Console and all 103 URLs
have gone through IndexNow, but indexing has its own clock.
That is why the difference between 100 on is-agentic and 88 on ora is useful. is-agentic can be satisfied with surfaces the site controls. ora also asks whether the wider web can find and corroborate the brand. No homepage tag can honestly force that result.
Maybe the score rises when the indexes catch up. Maybe another scan finds a new edge case and sends me back into the loop. Either outcome is fine.
I started because I wanted to see 100. I kept going because the benchmark was showing me a version of the site I could not see in a browser. That view is worth considerably more than the number.
You can explore the live Agentic Atlas, inspect its developer surfaces, or run the is-agentic scan yourself. The main application repository is still private, but the companion plugin is public on GitHub.