How to Determine Which APIs to Make Agent-Ready

The question every platform team eventually asks

Enterprise platform teams tell us this is the most common question they get once agent adoption starts: which APIs should we make agent-ready first? What’s actually in scope — do we need MCP servers everywhere, or is a better API enough? Most teams don’t have a systematic answer. They guess, or they wait.

Demand evidence, not intuition

Before touching a single endpoint, evaluate what you have. You want to evaluate before you build, not build and hope. That means testing real agent behavior against your real APIs — watching where an agent guesses, retries, follows a description over a schema, or gives up and hallucinates an endpoint. Intuition about which APIs “seem important” is a weak substitute for watching an agent actually try to use them.

Score readiness — but don’t trust the score blindly

Automated readiness scoring tools exist and are worth running as a first pass. But they can mislead. One scoring tool rated a spec at 38% description coverage when the actual spec had 95% coverage — because it double-counted reused schemas and dereferenced $refs incorrectly. It also flagged conventional headers and standard API-key auth as gaps without considering context. Treat automated scores as a starting point, not a verdict. Always validate findings against the actual spec and real agent behavior before you prioritize based on a number.

Prioritize by familiarity and traffic, not gut feel

Here’s a concrete prioritization signal, not a guess: agents perform very differently depending on how well-known an API is. In one 756-run benchmark (Smithery, “MCP vs CLI is the wrong fight” (Mar 2026)), agents blind-calling a well-known REST API (like GitHub’s) succeeded 92% of the time — they leaned entirely on training data. A niche, unfamiliar REST API succeeded only 42% of the time. An unfamiliar GraphQL API succeeded just 17% of the time.

About this evidence: Smithery’s result is a 756-run benchmark across a specific harness and a small set of APIs. It is a strong signal for tool-calling agents, but results vary with API familiarity and agent design, so use it as directional evidence rather than a universal law.

The practical takeaway: your most popular, most “famous” APIs get a false positive on agent-readiness — models already know them, so they’ll limp along even with weak docs. Your internal, proprietary, and niche APIs have zero training-data advantage. They’re the ones that fail silently and the ones that benefit most from deliberate agent-ready design work. Combine that familiarity signal with actual or expected agent traffic volume, and you have a real prioritization matrix instead of a hunch.

Sequence the stack correctly

Agent readiness isn’t only about deciding “API vs. MCP.” The Agent Access Stack starts with APIs as the foundation; CLI and MCP wrap the API; skills sit on top. Get the API wrong and nothing built on top of it works reliably — an MCP server bolted onto a bad API just wraps the same problems in a nicer interface. Fix API-level agent-readiness issues (naming, errors, list endpoints, idempotency) before deciding whether a given API also needs an MCP server.

Start free: the 12+2 checklist

You don’t need a formal engagement to start this work. Run the free 12+2 Insights for Agent Experience checklist against your top few candidate APIs. It covers the concrete, testable items — descriptive naming, list endpoints, idempotency, structured errors, deprecation signaling, response verbosity — that determine both how much work an API needs and how much agent traffic it can safely support once it’s ready.

Next step

Where to take this next

Working through this with your team? Team training — a private program that gets product, platform, and engineering aligned on what to ship for agents. Learning on your own? Compare the courses.