Is MCP just an API, security-wise?

At the transport layer, largely yes: an HTTP MCP server needs TLS, token validation, rate limiting, schema validation, and egress control, the same as any API. Above the transport, no. MCP tools are discovered at runtime rather than fixed at design time, tool descriptions are input the model acts on, callers are usually delegated non-human identities, and authorization has to be per tool call and per argument. Those four properties have no direct API-security precedent, so a posture built purely on the API playbook covers the transport and misses the model-level surface where MCP-specific attacks land.

What is the tool-description attack that API security does not cover?

In MCP, the server provides a natural-language description of each tool, and the model reads it to decide when and how to call that tool. A malicious server can embed instructions in a description, and the model may follow them, an attack called tool poisoning. Classic API security never defended a client against the API's own field descriptions, because REST clients do not read documentation and act on it. MCP clients effectively do, so tool descriptions have to be treated as untrusted content. That is a control class the API playbook simply does not contain, and it is one of the sharper departures.

Why is per-call authorization necessary instead of per-endpoint?

Because a single MCP session can invoke any tool the server exposes, and the risk lives in the specific arguments rather than the tool name alone. Endpoint-level authorization, common in API gateways, decides whether a role may hit a path. MCP needs to decide whether this caller may run this specific tool with these specific arguments right now, because a caller cleared to run a query tool is not cleared to run every possible query. Reading the arguments and checking them against the caller's authority on each invocation is finer-grained than the endpoint model and is where MCP authorization has to operate.

Does an API gateway secure MCP traffic?

It secures the transport-level parts and misses the model-level parts. An API gateway can terminate TLS, validate tokens, rate-limit, and allowlist egress for an HTTP MCP server, all of which is worth having. What a default API gateway does not do is bind tokens to a per-server audience against confused-deputy replay, treat tool descriptions as untrusted, propagate a delegated human identity through an agent, or authorize per tool call and per argument. Those need a control that understands MCP's model, which is why an MCP-aware enforcement point sits alongside the API controls rather than being replaced by them.

MCP Security vs API Security: What Changes When Tools Are Discovered at Runtime

Model Context Protocol runs over JSON-RPC, frequently on an HTTP transport, with tokens and tool calls. It looks enough like a REST API that the instinct is to apply the API security playbook and move on. Some of that playbook carries over cleanly. Four things about MCP break the assumptions the playbook rests on, and those four are where deployments get hurt. I want to walk each departure, say which classic API control still applies, and mark where MCP needs something the API model never had to account for. The controls themselves are laid out in MCP security best practices; this piece is about why the API mental model is not enough on its own.

Departure one: tools are discovered at runtime

A REST API has a fixed surface. The endpoints exist at design time, you document them, and you write authorization rules against a known list. MCP inverts this. A client connects and calls tools/list, and the server tells it at runtime what tools exist, what arguments they take, and what they do. The attack surface is defined by the server at connect time rather than fixed in advance. An API security posture built on a static endpoint inventory has nothing to enumerate here, because the inventory is dynamic. The control that carries over is schema validation on arguments; the control that does not is any assumption that you know the full surface before the session starts.

Departure two: tool descriptions are trusted input

This is the departure with no API analog. In MCP, the server supplies a natural-language description of each tool, and the model reads that description to decide when and how to call the tool. The description is an input the model treats as authoritative. A malicious or compromised server can write a tool description that carries instructions to the model, a tool-poisoning attack, and the model may follow them. Classic API security never had to defend the client against the API's own field descriptions, because a REST client does not read endpoint documentation and act on it. MCP clients effectively do. The defense is to treat tool descriptions as untrusted content, covered in MCP tool poisoning prevention, which is a control the API playbook does not contain.

Departure three: the caller is a non-human identity

API security has account for service-to-service calls, but the dominant model is still a human behind a session or a well-scoped service account behind a known integration. In MCP, the caller is usually an agent acting on a human's behalf, and the identity question splits: which human delegated this, which agent is acting, and under what scope. A non-human identity with a static credential and broad access is the default failure, and it violates least privilege by construction. The API control that carries over is OAuth 2.1 token validation. What MCP adds is the need to bind a token to a specific server audience and to propagate the delegating human's identity through the agent to the tool, so the confused-deputy path where a token minted for one server is replayed against another is closed.

Departure four: authorization is per call, not per endpoint

REST authorization commonly attaches to the endpoint and method: this role may POST to this path. It is coarse and it is workable because the endpoints are fixed. MCP authorization has to be per tool call and per argument, because a single session can invoke any exposed tool and the risk lives in the specific arguments. A caller allowed to run a query tool is not thereby allowed to run every query, and the authorization decision has to read the arguments, not just the tool name. This is per-invocation authorization, and it is finer-grained than the endpoint-level model most API gateways enforce by default.

What carries over and what does not

The transport-level controls carry over intact: TLS, token validation, rate limiting, input schema validation, and egress allowlisting are the same disciplines they always were, and an HTTP MCP server should have all of them. The model-level controls are new: runtime tool enumeration, tool-description trust, delegated non-human identity, and argument-level per-call authorization have no clean API-security precedent. And one thing sits entirely outside the network model on either side: the stdio transport runs the server as a local child process, so neither an API gateway nor an MCP gateway sees it, and it belongs to host hardening. The tempo is the same as everywhere else in this space, and it is why the new controls have to be inline: Google Mandiant's M-Trends 2026 report put median attacker handoff at 22 seconds.

DeepInspect

The transport controls you already run cover the parts of MCP that look like an API. DeepInspect covers the parts that do not.

DeepInspect is a stateless proxy on the AI request path between agents and the MCP servers and models they call. It validates the caller identity your application supplies, binds tokens to a specific server audience, authorizes each tools/call against role and arguments rather than against a coarse endpoint rule, and commits a per-decision audit record naming the delegating identity, inline and fail-closed. It sits on the HTTP transport where the model-level departures actually show up, so runtime tool calls, delegated non-human identity, and per-argument authorization are governed at one point across every server behind it. The stdio transport stays in host controls by design. Book a demo today.