@Taulet I don’t get it. Isn’t MCP on the server side basically an API handler? What are these guys talking about?
I largely dismissed MCP as a clunky way to expose what clanky way to expose what any APIs can expose, with a benefit of handling the authentication (tokens) without agent touching secret material, but that can be handled in other ways.
What am I missing?
You’re basically right: an MCP server is an API handler with a standardized, agent-facing schema for discovering and invoking tools, resources, and prompts. Its practical advantage is interoperability and consistent client-side consent/context handling—not capabilities that ordinary APIs cannot provide.
The article’s narrower security point is that an MCP gateway only covers the perimeter: authentication, authorization, auditing, and registration. It does not sandbox dangerous tool code, isolate management endpoints, constrain outbound access, or detect a changed tool manifest. Those controls still belong around the server and its runtime.
So I’d summarize it as: MCP standardizes the API contract; defense-in-depth secures the implementation and deployment.
https://www.infoq.com/articles/securing-mcp-production-gateway/