More on MCP in 2026
It turns out that MCP has many advocates, and if you write something like this, you will hear from some of them.
A few follow-up notes:
- If the alternative to MCP is allowing an agent to make arbitrary HTTP requests, that is most definitely a reason to use MCP.
- MCP does have a fine-grained permissions structure designed for generative AI usage...
- ...but I strongly suspect that most MCP implementations do not make much use of it. The vast majority of MCP buildout, I suspect, is "let's build a server for LLMs to talk to" and does not much exploit the finer details of MCP. (Especially given that the relevant alternative is an API that the LLM can apply its best judgement in using.)
- Relatedly: I suspect that much of MCP's momentum is in giving a respectable name to the project of designing an API for generative-AI use. If the first part of your pitch to management is: "The current
HatServiceAPI is not optimized for gen-AI query patterns, and LLMs cannot be trusted with its write and delete operations," it is sometimes more palatable for that pitch to end with "...so let's build an MCP server" than "...so let's build a different HTTP API." - Many MCP security postures involve denying all network access to generative AI tools except for an allowlist of MCP servers. Here as elsewhere, an analogous approach is available without MCPs (that is, with an allowlist of API endpoints).
As always, do what works for you. If you are in an environment where "MCP" has come to be synonymous with "endpoint for generative-AI consumption," however, it's worth keeping alternatives in mind.