Your API used to be a feature. Now it's the product. The next company that integrates with you won't send a developer to read your docs; it will send an agent, and that agent will both build the integration and run it in production.
That changes what your API has to do. An agent doesn't research, it calls and reacts, so everything it needs has to arrive in the response.
Getting an API ready for that takes work on a few fronts:
1. Error bodies should carry the fix
Errors for APIs tend to just describe what went wrong. Errors written for
agents should describe how to fix it. An error like invalid_parameter: date_range barely gives humans enough information to start investigating,
and definitely isn't enough for AI.
Agents will rarely search for documentation when they hit a wall. They will guess, try similar conventions, and rely on their parametric knowledge. But it will rarely go out and search for documentation. If you want to unblock agents building on your API, you need to bring the up-to-date documentation to them.
Restless calls this Agent Recovery. Every request is fingerprinted based on the error, endpoint and parameters, and next steps are served automatically inside the error JSON.
Just like agents won't search for documentation, they also don't like to follow links surfaced in error responses:
- Especially if they have tracking links or query params.
- That's why we include it as a continuation.
- We've found agents are much more likely to follow a link mentioned in prose, with a clear reason why they should.
2. Solicit agent feedback
Your API likely has some gaps: missing functionality, inefficient data structures, or lacking docs.
An easy way to find these issues is to give agents a way to send feedback via your MCP server.
If you expose an agent_send_feedback tool, some agents will let you know
where they get stuck. You can ask them to categorize the issue (feature
request, missing docs, confusing errors, etc), and triage them yourself.
3. Expose request logs
Most API problems don't appear until the code is in production and using real data. One of the best ways to understand what's going wrong is to give agents access to realtime request logs from production.
Your developers can give their agents access to this by properly setting up Sentry so their agents can track down issues and debug what's actually happening.
Restless exposes this information to agents via an MCP server. It lets them filter for errors (and successes!), and fetch information about how to fix them.
4. Limit MCP tool count
You'll want to surface your endpoints via the MCP server so agents can call them. Agents don't tend to like (or need) a generic fetch tool, since the functionality isn't discoverable.
However, MCP tool selection degrades after around 30 to 50 tools. So most APIs are far too large for this.
The best way to deal with this is to automatically curate a shortlist of
endpoints that you surface as tools, based on usage and other signals (such
as the agent_send_feedback tool, most searched for tools and more). To
surface the rest, you can provide a Tool Search.
You can also curate a few endpoints into a single tool. In Restless we call these Usecases, because they're surfaced as both tools in the MCP server and available functionality in the docs.
5. Programmatic signup
It's great if AI surfaces your tool, but getting to a working integration tends to break at account creation. Most apps require a human to go to a website, sign up, and then set up tooling so the agent can proceed. This is the most annoying part of starting with a new product, yet it still falls on the human.
There's a new standard, auth.md, aiming to fix this. Verification happens by sending a token to the user's email. This gives the agent scoped credentials and lets it keep going with your product on its own. Eventually, the goal is for agent providers (such as Claude or OpenAI) to be able to vouch for the user's identity so that step can be skipped.
6. CLI for more complex setup
Setup isn't just about getting a username and password, and CLIs are a great way to onboard if you have a tool that's built to be integrated.
Most good CLI onboardings are interactive, but agents can't work with TTY interactions. So you should build two flows for your CLI: one for humans and one for agents.
All the agent providers surface an environment variable to CLI tools when they run them:
| Agent | Environment variable |
|---|---|
| Claude Code | CLAUDECODE=1 |
| Codex | CODEX_SANDBOX |
Additionally, most languages surface a catch-all you can check for. For
example, it's process.stdout.isTTY in Node or sys.stdout.isatty() in
Python.
You can do more than just remove TTY interactions: you can be more verbose, so agents have all the information they need.
7. Agent-only endpoints
We traditionally see APIs as a contract with developers, since historically APIs are used for integrations with code. However, APIs are now how agents do things with your product.
It's okay to have agent-only endpoints, which change as frequently as your product. You can iterate on the ergonomics of your endpoints, remove unused ones, and keep up with your evolving product.
The most important thing is making sure agents can do everything in your product.
GET STARTED
Build with Restless
The modern API toolkit: docs, an API reference, and AI chat, generated from your OpenAPI spec and updated as it ships.