“Agent-ready” is the buzzword of the day and is starting to sound like the white noise of “AI-powered.” Everyone is claiming it. Nobody is defining it. A handful of sites will happily score your product on whether it has an llms.txt file and call that an answer. That’s a real signal, but it was never the question.
The question is whether an AI coding agent can actually use your tool. We wrote a 71-criteria open spec to answer it, and then ran its base criteria against over 900 published developer tools. Not one clears the top band. More on that below.
The Zaira Standard v0.9 is open, versioned, and live. 71 criteria across 12 modules, with published scoring gradients, drawn from broad industry research and direct measurement of how agents interact with developer tools. Read it, argue with it, apply it to your own tool, and see what it takes to do more than print the buzzword.
The Standard draws from the broadest evidence base we could assemble on how agents actually find, build with, and use developer tools.
The new customer
Developer tools have a new class of customer. AI coding agents now pick and use tools at machine speed. In enterprise environments, machine identities now outnumber people 109 to 1, and nearly three-quarters of those are AI agents (Palo Alto Networks, 2026). They’re choosing the database that holds your production data, the auth provider your users log in through, the framework your team builds on.
The internet wasn’t built for them. The tools that are will win the race to adoption, whether they’re the best tools or not. What used to be hygiene now shapes the buying decision.
The four things agent-ready actually means
1. Your documentation is a programmatic interface
Long-context accuracy drops 30% or more when the relevant information sits in the middle of the window (Liu et al., “Lost in the Middle,” TACL 2024). Dumping your full API reference into an agent’s context makes it worse at your tool, not better. The shape of your docs is doing more work than the volume.
The Standard measures machine-readable formats (llms.txt, AGENTS.md, content negotiation), structure (self-contained sections, answer-first layouts, descriptive headings that read as queries), and example quality (realistic data, progressive complexity, error recovery cases).
2. Your API surface fits a context window
In a production catalog of 584 tools, routing accuracy on under-specified requests drops 16 to 23 percentage points across frontier models.
Microsoft’s Azure SRE agent is the canonical case study. Within two weeks the team had more than 100 narrow tools and a prompt that read like a policy manual, and the agent was brittle. They rebuilt it around two CLIs the model already knew, az and kubectl, and got a smaller, more reliable surface with broader coverage (Microsoft Engineering, 2026). The Standard measures surface area, schema strictness, output size, and naming conventions because all of them compete for the same finite context.
3. Your errors are recovery instructions
An agent reading “Something went wrong” has no path forward. An agent reading {"type": "insufficient_scope", "required": ["write:repo"], "doc_url": "..."} has a clear next step. In controlled research, agent error recovery nearly triples when tool failures are made systematically curable, rising from a 32.76% baseline to 89.68% (PALADIN, ICLR 2026). The Standard measures error response structure, rate-limit communication, health endpoints, and whether async operations return durable handles.
4. Your auth works without a browser
OAuth flows with redirects and approval buttons don’t work when the end user is software. This is the most common disqualifier in our early evaluations. Tools can score well across documentation, errors, and surface area, then hit auth and stop: there’s no way for an agent to obtain a credential without a human clicking through a consent screen.
In the Standard, non-interactive authentication is a MUST gate. A tool that requires human-in-the-loop auth can’t reach Agent Ready or Agent Native regardless of how good everything else is. Acceptable paths: API keys, OAuth Client Credentials, Device Flow, dedicated agent-identity types, documented as first-class options, not buried in an enterprise tier.
How the Standard works
Every tool starts with the Base Standard: 15 universal criteria covering documentation, error handling, versioning, security posture, maintenance signals, and licensing. Based on what the tool actually does, additional modules activate.
| Module | Trigger | Criteria |
|---|---|---|
| Programmatic Interface (PI) | Exposes an API, SDK, or MCP server | 16 |
| Network Service (NS) | Runs as a hosted or remote service | 8 |
| Write Operations (WO) | Creates, modifies, or deletes data | 4 |
| Authentication (AU) | Requires credentials or tokens | 4 |
| CLI | Has a command-line interface | 4 |
Plus six domain modules where they apply: Payments, Communications, Databases, Hosting, Auth Providers, Frameworks. A simple utility library is evaluated on 15 criteria. A payments API with auth, writes, and a hosted service is evaluated on roughly 51. Every applicable criterion applies. No N/A markings, no denominator adjustments.
Each criterion is scored 0 (not present), 1 (basic), 2 (solid), 3 (exemplary). The Zaira Score is the weighted percentage across applicable modules. Tools land in one of three bands:
What over 900 tools look like against it
Between June 10 and July 6 we ran the Base Standard’s 15 criteria against every tool in the Zaira Guide: Over 900 tools across 60 categories, scored by an automated pipeline from public evidence. Documentation, repositories, package registries, HTTP surfaces. Every per-tool score is published on the tool’s Guide page.
The aggregate picture:
- The median tool scores 56.9% of the Base maximum. Fewer than half (~39%) reach the 60% reference bar.
- Nobody clears 80%. The highest score in the entire catalog is 78.4%. The ceiling is the finding: within each section of the Base Standard, tools do reach the top band, but no tool does it across all sections at once. Human-first tool development doesn’t produce these properties by default.
- Open source and commercial tools fail in mirror image. Open-source tools lead on machine-readable documentation (60.4% versus 52.1% section average) and collapse on safety fundamentals like supply-chain integrity and vulnerability disclosure (35.4% versus 59.2%). Managed services show exactly the reverse. Neither population is agent-ready across the board; they’re incomplete in complementary ways.
- No category is exempt. Across the 26 categories with at least 15 tools, category medians span ~7 points. This is a property of how developer tools get built and published, not a deficiency of any tool type.
Scope caveat: this measurement covers the Base fundamentals only, so no Agent Ready or Agent Native designations are implied by it. Scoring is automated and evidence-bound, which means a tool with undocumented strengths scores as if it lacked them, and individual scores can move a few points between runs as public evidence changes.
”Please not another standard.”
The reflex is fair: the last thing developer tooling needs is a fifteenth competing standard. Two answers.
First, we checked. Adjacent work covers agent security threats (OWASP), AI risk at the system level (NIST), open-source health (OpenSSF Scorecard), protocol conformance (MCP), and capability discovery (ARD). None of it defines tool-side agent-readiness as a measurable, modular framework. The Zaira Standard complements every one of those, and the spec says exactly what it does not attempt to replace. We built it because we needed it and it didn’t exist.
Second, the Standard mostly codifies practices that already exist in the best tools. Stripe’s error taxonomy, structured rate-limit headers, non-interactive auth paths, llms.txt: the exemplars for most criteria are shipping today. The Standard’s contribution is making them measurable, so “agent-ready” can mean something specific instead of whatever a landing page wants it to mean.
Who consumes it: Agents and agent platforms get a procurement signal through the Guide’s published scores, but more importantly, tool developers get a published gradient they can use to understand what agents need to be successful when using their tools.
What the Standard isn’t measuring
Because this is what people always ask first.
Tool quality. Whether your database is faster than someone else’s, your API better-designed, your framework a good idea: we don’t have an opinion. The Standard measures whether agents can use your tool, not whether they should prefer it over an alternative.
Security guarantees. A tool can meet every Safety criterion and still have undiscovered vulnerabilities. We measure documented practices and observable evidence, not absence of risk.
Training data coverage. How well current models know your tool is outside your control and outside the evaluation.
Discoverability. Whether agents can find your tool is a separate problem. Conflating it would penalize excellent tools with weak distribution and reward mediocre tools with strong SEO.
Compliance. SOC 2, ISO 27001, HIPAA are noted when present, but we don’t replicate the work those audits already do.
Versioning
Agent-readiness will evolve. The Standard will too, but not in a way that breaks vendors overnight. We expect to update the standard twice a year based on sustained advancements in the industry and we commit to a thirty day advance notice before any change takes effect. Major versions reserved for structural changes (new modules, revised score bands), minor versions for additive criteria.
We are shipping v0.9 and not v1.0 for a reason: the thresholds need real, extensive evaluation data to lock, and will be dialed in after our first cohort of Zaira Certified tools.
How to engage
Read the spec: it’s already published and out there for anyone to review or argue with. The failure modes the Standard measures are common and costly, and fixing them improves agent performance whether you ever pursue certification or not.
Want to be evaluated? Zaira Certified isn’t generally available yet. We’re running a launch-partner pilot first to fully polish both the Standard and our evaluation engine for v1.0.
The Standard exists for something bigger than certification: a future where agents pick good developer tools for good reasons, and the apps, little projects, and enterprise software being built with AI, by professionals and novices alike, are better for it.
zaira_labs