Balaji Venkatasubramaniyar argues that MCP’s important change is not merely a common format for tools. In a traditional integration, developers decide in advance which systems talk and in what order. With an agent, the model may choose and combine capabilities at runtime, across servers whose authors never planned to work together. The integration plan is partly made when the user asks for something.
That makes three pieces of engineering harder than a clean API schema might suggest:
- Descriptions become part of the interface. A valid input schema says what a tool accepts; its name and description must also tell the agent when to use it, what an ID means, and how it differs from neighboring tools. A technically correct server can still invite the wrong call.
- Composition creates new failure paths. A tool that works in isolation may behave badly when its input comes from another server or when the agent calls it in an unexpected sequence. Test realistic chains and design tools to fail safely, not just pass unit tests.
- Governance has to precede access. The essay calls for vetted tool allowlists, authentication, audit logs, and managed secrets before an agent receives consequential privileges.
The shared protocol removes duplicated framework-specific adapters, but it cannot guarantee good tool selection, safe combinations, or sound authorization. Those remain application and operations work. The useful question is not whether MCP replaces APIs; it is who makes the integration decisions and how those decisions are constrained and observed.