API-first was for developers. MCP-first is for agents.
API-first was a real step forward, but it answers a different question. Here is what MCP-first adds on top, and why it matters for agent-ready software.
API-first was one of the best ideas of the last decade. Design the contract before the implementation, and every client benefits. But API-first answers a developer’s questions, and an agent has different ones.
API-first exposes endpoints
API-first asks: what endpoints exist, what can I send, what will I get back, and how do I authenticate? Those are integration questions, answered by a human developer reading docs and wiring calls.
MCP-first exposes capabilities
MCP-first asks all of that and more:
- What can the system actually do, in business terms?
- When should an agent use which tool?
- Which resources provide the context it needs?
- Which actions are risky, irreversible, or have external effects?
- Which actions must never run autonomously?
- Which require human confirmation or step-up auth?
- How is each action audited?
Same action, every client
Because a capability is defined once in a central action layer, the web app, the mobile app, the CLI, a worker, and an agent all call the same action, with the same validation, the same policy checks, and the same audit trail. No interface gets a private code path. No second, divergent permission model hides in the MCP server.
API-first exposes endpoints. MCP-first exposes capabilities.
That’s the shift: from a contract for developers to a contract for everyone, humans, agents, and automations alike. See why UI-first breaks for the longer argument.