Agent-ready APIs
Agent-ready APIs that an agent can call without guessing
Routebase makes the descriptions, examples and errors in your OpenAPI spec the interface an agent reads, serves llms.txt from every docs portal, and lets agents work the same contract over MCP.
14-day Pro trial — no credit card required.
An AI agent decides in milliseconds, from your contract alone, whether and how to call an endpoint, and a description that repeats the name turns that decision into a guess. Agent-ready APIs close that gap without a second artefact, because the spec your team already writes is what the agent reads. In Routebase the description of an operation is a full editor rather than a text box, and enum values carry labels and meanings that travel into the export. One shared error component tells a caller what went wrong and what would fix it. Every published docs portal serves an llms.txt index, a full Markdown export and a Markdown twin per page, so an agent reads the reference as text instead of scraping a rendered page. And because every workspace ships an MCP server, the agent that consumes your API can also help design, test and document it under your team's permissions.
Agent-ready APIs start with the description
The description of an operation is where the schema stops and the protocol begins, so Routebase gives it an editor and carries every word into the export.
- Callouts, tables and sequence diagrams in the description, rendered in the portal and exported as Markdown
- Enum values with a label and a meaning per value, exported as x-enumNames and x-enumDescriptions
- Tag descriptions that introduce a group of endpoints and export as the OpenAPI tag description
- Style guide rules that list every operation, parameter, schema and response without a description, on Pro
Errors that tell the agent what to do next
A human meeting an unstructured error reads your docs, while an agent does whatever the error body suggests, so the body has to suggest the recovery.
- One error response defined as a component and referenced from every operation that returns it
- An organisation-wide shared library for the error shape several projects should answer with
- Style guide rules for declared 4xx responses and for application/problem+json as the error media type
- Room in the component for a stable type and an actionable detail, so a 403 can name the scope it needs
Docs an agent can read without scraping
Every published portal serves its content as text next to the HTML, and a build fails rather than ship a portal without those files.
- An llms.txt index of every content and reference page, and llms-full.txt as one Markdown document
- A Markdown twin of every page, with endpoint pages generated from the spec and references resolved
- A robots.txt that points at the sitemap and the index, so an agent starting at the root finds them
- Page actions for readers, from Copy as Markdown to Open in Claude or ChatGPT
Agents work the contract, under your permissions
Every workspace ships an MCP server that covers the full feature set, so the agent that consumes your API can also help build it, and the tests it writes are the honest check.
- 13 prompts and 12 resources package whole workflows, and design_api loads your style guide before drafting
- generate_tests builds the suite and run_test_suite reports which assertion failed on which case
- Permissions checked when tools are listed and again when one is called, billing and roles stay read-only
- A remote connector for Claude over OAuth, and one command for Claude Code, Cursor, VS Code and Codex
Frequently asked questions
What makes an API agent-ready?
An agent reads your contract and nothing else. An agent-ready API therefore says in its descriptions what an operation does, when to use it instead of its neighbours, what has to be true first and what comes back. It returns errors with a stable type and an actionable detail, and it publishes its documentation as text an agent can fetch. None of that needs a new artefact, because all of it lives in the OpenAPI spec and the portal built from it.
Do I need MCP to make my API agent-ready?
No. Descriptions, error bodies and llms.txt make your API usable by any agent, whichever client it runs in. The MCP server is how an agent works inside Routebase, where it can draft descriptions, generate the test suite and publish a version under your team's permissions.
What is llms.txt, and does my docs portal serve it?
It is a proposed file at the root of a site that gives an agent a short description and a curated list of links to Markdown versions of the pages that matter. Every Routebase portal build emits it, together with llms-full.txt and a Markdown twin of every page, and a build that cannot produce them fails. Our own documentation runs on the same portal, so the files are open to check.
Can an agent test my API?
Yes. Over MCP an agent reads the spec, creates a suite with a case per endpoint and its assertions, runs it against an environment and reads the structured results back, including JUnit output for CI. It works under a scoped key, so its reach is set by the credential rather than by the prompt.
Does Routebase check whether a description is good?
The style guide finds the missing ones, on every operation, parameter, schema, response and tag, and reports them at the severity you set. Whether a description is useful is a judgement no linter makes, so the honest test is to hand the endpoint to an agent and read every guess it has to make. Over MCP the agent can then propose the rewrite as a diff you approve.
One living spec
The lifecycle behind it
Change the spec — everything on this page updates with it.
Ready to ship on it?
Routebase is live. Design your API once — docs, mocks, tests, and monitoring all follow from the same source.
14-day Pro trial — no credit card required.