AI readiness
“Agent-ready” is a claim most APIs cannot back up. Elva makes it a measured grade: every operation is checked for the schemas, descriptions, and semantics an LLM needs before it can call your API safely — and every MCP server shows you that grade before you ship it to a single agent.
Why agents need more than a valid spec
A human developer who hits a vague endpoint reads the source, asks a teammate, or experiments in a sandbox. An agent does none of that. It reads your contract once and acts, which turns every gap in the spec into a runtime failure:
- No request body schema → the agent invents a payload shape, and your API rejects it — or worse, accepts it.
- No description → the agent picks tools by name alone, and
POST /processgets called for everything. - No response schema → the agent cannot interpret what came back, so it guesses, retries, and burns tokens.
Validity is table stakes. Readiness is whether a model can ground itself in your API without a human in the loop — and that is what Elva scores.
The readiness check on every MCP server
When you generate an MCP deployment, Elva runs every selected operation through readiness checks and grades the result, so weak tools are caught at build time, not in an agent’s transcript.
Check | Severity | What goes wrong for the agent |
Missing request body schema | Error | A |
No response schema | Warning | No |
No description | Info | Neither summary nor description, so tool selection runs on the name alone |
The readiness score is the share of checks that pass across all selected operations, graded A (90+), B (80+), C (70+), D (60+), else F. Filter the issue list by severity and burn down the errors first — they are the ones that produce hallucinated payloads.
A weak tool does not fail loudly. It fails as an agent that seems dumb — wrong arguments, wrong tool choices, wasted tokens — and your API gets the blame. Readiness scoring moves that failure from the agent's transcript to your build screen, where it is fixable.
AI Readiness in the spec score
Readiness is not bolted on at MCP time — it is one of the four categories in Elva’s spec quality engine, weighted at 15% of the overall grade and scored by deterministic checks:
Check family | What it measures |
| Every operation has a clean, unique |
| Summaries and descriptions say what an operation does, not just what it is called |
| Schemas carry constraints, enum documentation, and format specifications instead of bare |
Because both surfaces reuse the same deterministic engine, the story is consistent: the grade on your collection, the score on the Insights page, and the readiness check on your MCP server all move together when you fix the spec.
Raise the grade in one pass
1
Name every operation
Add a unique, descriptive operationId and a one-line summary per operation. This alone transforms tool selection.
2
Schema the writes
Give every POST, PUT, and PATCH a request body schema. This clears the error-severity readiness check.
3
Schema the reads
Define the success response (200/201/204) so agents can parse what they get back instead of guessing.
4
Constrain the inputs
Add enums, formats, and min/max bounds. Every constraint you declare is an invalid call an agent never makes.
5
Rescore and ship
Scoring is deterministic — the same spec always earns the same grade — so you can watch each fix move the exact category it should, then deploy the MCP server knowing what agents will experience.
This loop is Elva's core promise in miniature: agent-ready is earned, not assumed — and once earned, it is enforced by the same pipeline that deploys your tools.
Where to go next
Spec quality & scoring
The full engine: 30+ checks, four weighted categories, and how a percentage becomes a grade.
Hosted MCP servers
Where the readiness check runs: select operations, set auth, and deploy an agent-callable server.
On this page
- AI readiness