I scored 26,568 API providers against the Agent Readiness layer of the Kin Score, and one of the fourteen dimensions came back at a number I had to go and check twice. Seventy-one providers publish a dry-run mode. Not seventy-one percent. Seventy-one providers, out of 26,568. That is 0.27%.
A dry-run mode is the ability to say to an API: tell me what this call would do, without doing it. Some call it simulate, some call it preview, some call it validate-only. Whatever the spelling, it is the difference between asking a question and taking an action, and it is the single most useful thing an API can offer something that is about to act on your behalf without you watching.
The shape of the number
It is worth putting the rest of the dimensions next to it, because the fall-off is the story rather than any single figure:
| Dimension | Providers | Share |
|---|---|---|
| Machine-readable auth | 8,564 | 32.2% |
| Machine-readable contract | 8,467 | 31.9% |
| Rate-limit signalling | 8,161 | 30.7% |
| Stable error semantics | 3,945 | 14.8% |
| MCP server | 3,641 | 13.7% |
| Consent / bot identity | 922 | 3.5% |
| Idempotency | 634 | 2.4% |
| Dry-run / simulate | 71 | 0.27% |
Describing the API sits around thirty percent. That is not great, but it is a recognizable number — a third of the market has done the machine-readable basics. Then look at what happens to everything that constrains or accounts for what a caller may actually do. Error semantics halves it. Consent drops it by a factor of ten. Idempotency — the ability to retry safely, which is table stakes for anything automated — is under two and a half percent. And the ability to preview an action before committing to it is a rounding error.
We have spent fifteen years getting reasonably good at describing what an API is, and almost no time at all on describing what happens when something calls it. That gap did not matter much when the caller was a developer who would read the docs, try it in staging, and think about it. It matters enormously now that the caller is increasingly a model with a tool definition and a task.
Why this is the dimension that matters for agents
Every other dimension on that list helps an agent understand an API. This one is the only one that helps an agent be careful.
Consider what an agent does without it. It has a tool definition, a goal, and no way to distinguish a call that reads from a call that spends money, cancels a booking, or emails a customer list. The only way to find out what a POST does is to issue it. Every guardrail we build on top — approval gates, human-in-the-loop, spend caps — exists because the underlying API cannot answer the question “what would this do?” We are building elaborate scaffolding around a missing feature.
An idempotency key lets you retry without doubling the charge. A dry-run lets you avoid the charge entirely while you work out whether it was the right one. Those are different problems, and the market has barely solved either: 634 providers and 71 providers respectively, out of 26,568.
The caveat, which cuts both ways
This measures what is discoverable in machine-readable form, not what exists. Plenty of APIs have a sandbox, a test mode, or a validate-only flag and never say so anywhere a machine can find it. The real number of APIs that can do this is certainly higher than seventy-one.
But that distinction matters less than it sounds, and it cuts the way you might not expect. An agent cannot rely on a guarantee it cannot read. If your API supports validate_only=true and your OpenAPI does not mention it, then for every automated caller in the world that capability does not exist. Undocumented safety is not safety. It is a feature you built and then hid from the only consumer who needed it most.
So please do not quote this as “99.7% of APIs are unsafe.” That is not what it says. What it says is that 99.7% of APIs have not told anyone they are safe to try.
What to do about it, if you run an API
This is one of the cheapest agent-readiness wins available, and unusually, most of the work may already be done.
- If you already have a validate-only, preview or test mode, document it in your OpenAPI. A parameter with a description, in the spec, in the operation it applies to. That is the whole job. You will move on a dimension where you currently have 26,497 companies for company.
- If you do not have one, start with the operations that spend, send or delete. Nobody needs a dry-run on a
GET. The value is concentrated in exactly the handful of calls that make people nervous about letting an agent loose. - Do not confuse a sandbox environment with a dry-run. A separate base URL with separate data is a useful thing, but it is not the same as modelling this call against this production state. Agents do not get to point at your sandbox when they are working on a real task.
The seventy-one who have done it are a genuinely interesting cohort, and not the one I expected — heavy on infrastructure and developer tooling, and with fourteen universities in the mix, which turns out to be because research APIs get built alongside the teaching materials that need a safe way to demo them.
I will take the obvious next question myself before anyone else asks it: 0.27% is extreme enough that the detector deserves auditing as much as the market does, and I have opened that up rather than assume my own instrument is right. A number this striking should be tested before it is repeated, including by me.
