Why would I do that if the MCP already handles it? The MCP exposes the API with those tools, it explains what the calendar app is and when to use it.
Connected MCP tools are also always in the model's context, and it works for any AI agent that supports MCP, not just Claude Code.
Why would you put a second, jankier API in front of your API when you could just use the API?
> The MCP exposes the API with those tools, it explains what the calendar app is
So does an API and a text file (or hell, a self describing api).
Which is more complex and harder to maintain, update and use?
This is a solved problem.
The world doesnt need MCP to reinvent a solution to it.
If we’re gonna play the ELI5 game, why does MCP define a UI as part of its spec? Why does it define a bunch of different resource types of which only tools are used by most servers? Why did not have an auth spec at launch? Why are there so many MCP security concerns?
These are not idle questions.
They are indicative of the “more featurrrrrres” and “lack of competence” that went into designing MCP.
Agents, running a sandbox, with normal standard rbac based access control or, for complex operations standard stateful cli tooling like the azure cli are fundamentally better.