Why APIs Are Becoming Agent Interfaces

Every API you've built was designed for the same consumer: a developer. Someone reading your documentation, copying an example curl request, writing a client library, understanding the semantics of your endpoints from context and judgment. The mental model behind REST conventions (readable resource names, predictable status codes, human-friendly error messages) is the mental model of developer experience.

That assumption is breaking. The fastest-growing category of API consumer isn't a developer. It's an AI agent deciding at runtime what to call, with what arguments, and whether the result means it should keep going or try something else. Designing APIs for developers and designing APIs for agents are not the same problem.

What REST conventions were actually solving

REST gave us a vocabulary. Resources are nouns. HTTP verbs are actions. Status codes communicate outcome classes. URLs are hierarchical and readable. This made sense because the consumer needed to build a mental model of your system from documentation and then implement that model in code.

The design conventions optimise for comprehension. Readable endpoint names help developers navigate. Verbose error messages explain what went wrong in terms a person can act on. Pagination is designed around what a human-facing UI can display. Rate limits are communicated through headers a developer will observe and handle.

None of this is wrong. But it's optimised for a consumer that reads, infers, and exercises judgment, not a consumer that needs precise machine-readable contracts specifying exactly what a function does, what its inputs mean, and what side effects it produces.

How function calling changed the contract

OpenAI's function calling, introduced in 2023 and now mirrored by Anthropic's tool-use API, formalised what agent-optimised API design actually looks like. Instead of giving an agent a URL and hoping it figures out the parameters, you give it a schema: a structured description of what the function does, what each parameter means, what type it expects, and what the output will look like.

The model uses this schema to decide whether to call the function, construct the arguments, execute the call, and interpret the result. The entire interaction is machine-readable by design.

This is a fundamentally different contract. The description field in a tool schema isn't documentation for a developer to read once. It's a runtime input the model uses to make decisions. The parameter descriptions aren't comments; they're semantic constraints that shape how the model constructs arguments. A schema that's ambiguous or imprecise doesn't confuse a developer once. It produces incorrect or unsafe tool calls at runtime, repeatedly, at scale.

When you design an API that an agent will use as a tool, you're writing code that will be executed by a reasoning system. The precision requirements are different, and the consequences of imprecision are different.

The tool surface problem: when one agent has too many options

The next challenge is scale. A single enterprise application might expose hundreds of legitimate actions: create a record, update a field, query a view, send a notification, trigger a workflow, revoke a permission. Give an agent access to all of them at once and you hit a fundamental constraint: every tool schema consumes tokens, and a context window full of tool definitions leaves less room for reasoning and task context.

This is why both OpenAI and Anthropic have introduced tool search, a mechanism that defers tool loading and allows agents to discover relevant tools at runtime rather than receiving the entire catalogue upfront.

The architectural implication is significant. Tool-based systems are evolving from flat lists of predefined functions toward something closer to registries with runtime discovery. An agent doesn't receive all available tools at the start of a session. It searches for relevant tools when it needs them, loads the schemas, executes the calls, and discards what it no longer needs.

This pushes API design toward namespace organisation and semantic clarity. If an agent is going to search for a tool that creates a project, the description needs to be precise enough to match that intent and distinct enough to avoid false positives against tools that create related but different things. Tool naming and description are no longer documentation tasks. They're engineering tasks with direct product quality implications.

MCP and the protocol layer

Individual tool schemas solve the per-function contract problem. The Model Context Protocol (MCP) addresses the system-level connectivity problem: how does an agent runtime connect to the external systems where tools and data live?

Anthropic launched MCP in November 2024 as an open protocol for connecting LLM applications to data sources and tools through a standard interface. In twelve months, it accumulated backing from OpenAI, Google, Microsoft, and AWS, achieved governance under the Linux Foundation, and hit 97 million monthly SDK downloads. For a protocol specification, that's an unusually fast adoption curve, driven largely by bottom-up developer enthusiasm rather than top-down enterprise mandates.

MCP is often described as "USB-C for AI applications." Before it, connecting an agent to a new external system required a custom connector. MCP standardises the integration layer: a compliant MCP server exposes tools, resources, and prompts through a consistent interface that any MCP client can call. Instead of N×M custom integrations, you get N servers and M clients that interoperate through a shared protocol.

Over 5,800 MCP servers are now available, covering everything from database connectors to CRM integrations to developer tooling. Salesforce, ServiceNow, and Workday have all built MCP servers. The protocol has moved from experimental to infrastructure.

That said, MCP is not without trade-offs. Early production deployments have surfaced a specific tension: MCP server schemas can consume 40-50% of available context windows before the agent has done any meaningful work. The emerging architectural consensus for 2026 is pragmatic: use MCP where dynamic tool discovery and interoperability matter, use direct API calls where performance and simplicity matter more. The protocol is the right answer to the connectivity problem, not necessarily the right answer to every API design decision.

What this means if you're building APIs today

The shift from developer-first to agent-first API design isn't an either/or. Humans still use your APIs. Developers still integrate with your systems. But if you're building product surfaces that AI agents will call, and increasingly that's most of them, there are specific design decisions that carry more weight than they used to.

Describe functions precisely, not verbosely. A tool description needs to be accurate enough for a model to decide when to call it, concise enough not to consume excess context, and specific enough to distinguish it from semantically related functions. "Creates a new customer record" is better than "This endpoint allows you to create a new customer in our CRM system."

Make parameters self-describing. Parameter names and descriptions should communicate type, expected format, and semantic constraints. Don't rely on a model inferring what id refers to from surrounding context. Specify it in the schema. An agent constructing arguments doesn't have your documentation open in another tab.

Design for idempotency and explicit side effects. Agents retry. They operate in loops. They make mistakes. An API that's safe to call multiple times with the same arguments is safer for agent use than one that silently creates duplicates or triggers a payment on each call. Side effects belong in the tool schema, not the developer docs.

Separate read from write. Agents benefit from tool surfaces that clearly distinguish information-gathering operations from state-changing operations. This shapes how orchestrators manage risk, implement approval gates, and scope permissions for specific tasks. The distinction that was a best practice in API design is now load-bearing.

Plan for tool registries, not just documentation. If your API will be consumed by agents through tool search or MCP, the semantic content of your descriptions is the signal a search system uses to match intent to function. Clear, consistent naming conventions and description patterns make your tools more reliably discoverable, and discovery failures translate directly to task failures.

The API as a first-class agent surface

As we've covered previously, AI-native architecture separates the system of record, the system of context, and the system of action. The system of action is where APIs live. And as agents become the primary operators of that system, the API surface becomes the interface the agent uses to understand what it can do and to act safely within those capabilities.

This is not a distant architectural concern. Teams that design their action layers for agent consumption today will have better-performing, more reliably operating agent systems than those that retrofit human-facing APIs into tool schemas later. The difference shows up in task success rates, in the precision of tool calls, in the frequency of hallucinated or malformed arguments.

REST conventions gave developers a shared vocabulary. Function schemas, tool registries, and protocol standards like MCP are giving agents a shared vocabulary. The surface being designed has changed. The quality bar for that design has gone up.

If you're building the tooling infrastructure for your AI systems, our Agentic Interface Design playbook covers the practical patterns for tool surface design, approval flows, and agent-safe API architecture.