Most assume MCP server auth works like a REST API.

That can lead to shipping something secure-looking...

(but not actually secure)

While implementing MCP, I ran head-first into a distinction that isn't obvious:

Server-level authentication is not the same thing as tool-level authorization.

In traditional API systems, we treat the connection as the security boundary:

-> Authenticate once

-> Reject the request if auth fails

-> Everything downstream inherits trust

That mental model does not map cleanly to MCP. In some implementations:

-> You may be able to connect unauthenticated

-> And then discover available tools...

-> ...But not use all of them

(Unauthenticated tool discovery may be allowed by design in some MCP implementations. Especially if tool descriptions are already publicly documented)

At first, this feels like a flaw.

It isn't.

It's a different security model.

Once you connect to an MCP, some tools might be accessible while others are off-limits.

(Different from most APIs, where if you are authorized to use a given scope, you can generally use the endpoint)

The key for securing this more complex approach?

Don't forget to actually check (at least) authorization before each tool call!

(Miss this, and the result is the same as an unauthenticated API endpoint - risk to data confidentiality, integrity, and availability)

Middleware to read credentials and inject permissions into a server-controlled namespace does the trick.

What MCP server security traps have you encountered?