What is MCP Authorization?

If you love working with and building around AI Agents, you’ve probably seen the hype around the Model Context Protocol (MCP) lately. If you’re like me, you initially rolled your eyes at "yet another standard."

But guess what! After digging into the specs and implementing a few test servers, I realized this isn't just another syntactic sugar. It’s actually fixing the integration problem we’ve been dealing with since the "function calling" API era began.

We’re going to look at what this protocol actually is, how the architecture handles the handshake, and, because the title promised a deep dive, we’ll touch on the security implications of opening up your local filesystem to an LLM - because that’s precisely where MCP is needed the most.

So, let’s get started.

What is MCP (Model Context Protocol)?

At its core, MCP is an open standard that acts like a universal translator between AI applications (like Claude Desktop or an IDE) and external systems (your local files, a Postgres DB, or a Jira instance).

Think of it as a USB-C port for AI applications. Before USB-C, we had a mess of proprietary cables. Similarly, before MCP, if you wanted Claude to talk to a SQL database, you wrote custom glue code. If you wanted ChatGPT to talk to the same database, you wrote different glue code. MCP standardizes that interface so you write the integration once, and it works with any MCP-compliant host.

It’s important to note: MCP isn't the LLM itself. It operates strictly as the protocol for context exchange. It’s the pipe, not the water that flows in the pipe.

The MCP Protocol

Let’s understand its architecture a bit. The MCP protocol follows a client-server model, but the terminology can be slightly counter-intuitive if you're used to standard web apps. Here’s what they precisely mean in MCP context:

MCP Host: This is the "frontend" app that you (the user) interact with (e.g., Claude Desktop, Cursor, or VS Code).
MCP Client: The host (i.e. the app you are interacting with) spins up an MCP Client. This is the protocol-level component that maintains the actual connection with the Server.
MCP Server: This is the program exposing the data or tools that you want to connect with. It can run locally or remotely.

The Layers

Under the hood, MCP is built on two layers:

The Data Layer: This uses JSON-RPC 2.0. It handles the message framing, lifecycle management (connection initialization), and the core primitives like tools and resources.
The Transport Layer: This is where the bits actually move.
- For local stuff, it uses Stdio (standard input/output). This is great for privacy and speed - no network overhead, just process communication.
- For remote connections, it uses HTTP with Server-Sent Events (SSE). The client sends requests via HTTP POST, and the server streams responses back via SSE.

The Handshake

When the client connects, there’s an initialization handshake. The client sends an initialize request with a protocol version (currently 2024-11-25 for stable) and capabilities.

This is where they negotiate—the client says, "Hey, I support sampling," and the server replies, "Cool, I support tools and resources".

So What is an MCP Server?

An MCP server is just a lightweight program that speaks JSON-RPC. It can be a simple Python script using stdio or a full-blown Node.js app running over HTTP.

There are already reference implementations for things like:

Filesystem: Lets the LLM read/write files (within boundaries).
Git: Lets the LLM commit code or read diffs.
Postgres: Lets the LLM query your data.

The cool part is the deployment flexibility. You can run a "local" server that just spawns a process on your machine (great for sensitive local files), or a "remote" server deployed on Cloud Run or Kubernetes that creates a shared specialized agent for your team

What Does MCP Do?

Okay, so the pipe is established. What flows through it? MCP defines three main primitives that servers expose to clients:

Resources: These are passive data sources. Think of them like GET requests or file reads. They have URIs (like file:///logs/app.log or calendar://2024) and mime types. The client can read these to load context into the LLM’s window.
Tools: This is the active stuff - executable functions. If you’ve used OpenAI function calling, this is the standardized version. The server sends a JSON Schema defining the inputs, and the LLM can decide to "call" that tool to perform actions like querying a DB or creating a calendar event.
Prompts: These are reusable templates. Instead of copy-pasting a complex "Code Review" system prompt every time, the server can expose a prompt called review-code that accepts arguments. It helps standardize workflows.

Interestingly, there are also primitives the client can expose to the server, like Sampling. This allows the server to say, "Hey, I need an LLM completion to process this data, can you run that for me?".

The Authorization Deep Dive

Since this blog is on "MCP Authorization," we have to talk about the elephant in the room. When you connect an LLM to your filesystem or database, you are essentially giving an agent shell access.

Currently, MCP authorization is heavily reliant on the Transport layer:

Stdio: Security is essentially "user permissions." If you run the server locally, it runs with your OS user's permissions.
HTTP/Remote: This uses standard HTTP auth. The spec supports headers like Authorization: Bearer <token>, and they heavily recommend OAuth 2.1 for remote connections.

The "Roots" Misconception You might see a feature called Roots, where the client tells the server, "You are only allowed to look at this directory" (like /User/projects/my-app).

It sounds like a security sandbox, but the documentation is very clear: this is a coordination mechanism, not a security boundary. A well-behaved server will respect it, but a malicious server could ignore it completely because the code is running outside the client's control.

The State of Security

Now a genuine note of concern - the ecosystem is still young. Recent scans found thousands of exposed MCP servers on the internet with zero authentication, meaning anyone could technically query them. If you are building a server, you need to implement Resource Indicators (RFC 8707) to prevent token forwarding attacks.

Right now, the philosophy is "Human-in-the-loop." The MCP Host (the client) is expected to ask the user for approval before executing a tool or sending data to a server. It’s a bit like the "Allow this app to access your contacts?" pop-up on your phone.

MCP in the AI Era - Why is it Required?

If you've ever tried to build an agentic workflow, you've hit the NxM problem.

N = Number of AI models (Claude, Gemini, Llama, etc.)
M = Number of external tools (Slack, GitHub, Postgres, etc.)

Without applying the MCP protocol, you are building N * M integrations. It’s unmaintainable!

MCP turns this into N + M. You build the Postgres MCP server once, and it works with Claude, Cursor, and whatever comes next.

Beyond just saving dev time, it solves the hallucination issue, or at least mitigates it. Because the LLM isn't relying solely on training data; it's pulling fresh context from your live resources via the protocol.

To Sum Up

In essence, MCP is trying to do for AI what USB-C did for hardware: stop the madness of proprietary cables. We are finally moving past the phase where every LLM provider needs a custom integration for every database on the planet - the classic NxM problem we talked about earlier.

But let’s be real, we are still in the "early adopter" phase. The protocol is powerful, but the security model puts a lot of trust in the user and the implementation. As we saw with the Roots mechanism, "coordination" isn't the same as "sandboxing". If you are deploying this in production, keep an eye on upcoming specs like Progressive Scoping and Client ID Metadata, which are aiming to tighten up those authorization flows.

That said, the utility here is undeniable. By standardizing the "grammar" of how LLMs interact with tools, we aren't just getting better chatbots; we're finally getting agents that can actually do work rather than just talk about it.

So, grab one of the SDKs (TypeScript, Python, or Java) and build a simple server. Even if it’s just a script to fetch your local logs, seeing Claude or VS Code interact with your live data without you writing a single line of client-side glue code feels like a superpower.

And in case you need help with MCP Auth or Agentic IAM in general, LoginRadius AI is right here to help! Click here to know more about our MCP Auth offerings.

MCP Authorization: The Key to Safe and Simple AI Integrations