A common question I hear when teams start building for AI is, “Why can’t agents just use our REST API instead of MCP?”
My response is usually the same: “Why can’t you just use your REST API instead of a UI?” We build interfaces to optimize the experience for the consumer. For the new class of “agent stories,” that UI is an MCP server, and designing for it requires a new discipline.
Consider a simple change: adding a new filter to an API.
For a human-centric API, you add an optional parameter with a good default and clean documentation. This is a win. For developers who don’t need the new filter, the cognitive surface area is unchanged—they can ignore it. It’s discoverable, not intrusive.
For an agent-centric API, this same “improvement” is a disaster. That new parameter is now part of every interaction. Its instructions will be weighed against all others. Its scope will be (mis)understood. It increases the complexity and token cost of every call. The interaction surface area hasn’t been slightly expanded; it has exploded.
A human developer is great at ignoring what’s irrelevant. An agent must process everything.
This is the core challenge. For human APIs, we prioritize discovery. For agent APIs, we must prioritize curation.
MCP is a step in the right direction because it forces us to curate what we expose. But its native discovery—listing all available tools—is still too broad. That’s why in FastMCP, we’re building dynamic solutions that go far beyond simple filtering, including semantic search and per-session tool visibility. The goal is to let an agent request a narrow, context-aware set of tools, not the entire toolbox.
When designing for agents, don’t ask “How much can I show them?” Ask “What is the absolute minimum they need?” Your agent stories—and your token bill—will thank you for it.