Quick MCP refresher

The Model Context Protocol (MCP) is a standardized way for AI agents to communicate with external software systems. First released in November 2024, MCP represents a fundamental shift in how AI agents interact with the broader software ecosystem.

The evolution of AI tool integration

Before MCP, integrating AI agents with external tools was challenging and inconsistent. Early implementations required AI models to be trained on specific tool formats, making each integration unique and difficult to maintain.

MCP solved this by creating a standardized protocol that allows AI agents to discover available tools and their capabilities; make structured requests to external services and receive responses in formats that AI models can understand.

Authentication in MCP is different

MCP introduces a new authentication paradigm because it operates differently from traditional web applications. In a traditional application, users interact and authenticate directly with your application. If you’re building an MCP server, the MCP client (which you don’t control) will authenticate the user, and then use that permission to access your server.

This creates unique challenges:

• AI agents need to prove they’re authorized to act on behalf of specific users
• Your application needs to verify both the agent’s identity and the user’s permissions
• The authentication flow must work seamlessly across different AI platforms

Why authentication matters

Not every MCP server needs authentication. For example, a locally hosted stdio-based server that accesses local files doesn’t need credentials.

However, authentication becomes critical when:

• Your MCP server needs to access protected systems
• The server is exposed on the internet
• You need to know who is making requests
• You need to control what actions users can perform

Key actors

Before diving deeper, it’s important to understand the actors in an MCP interaction:

• MCP host: The AI agent framework (like ChatGPT) that manages the conversation and coordinates tool calls. This is what the user will interact with.
• MCP client: Manages connections to MCP servers.
• MCP server: Your application that exposes tools and resources.

If you’re building an MCP server, it’s generally okay to treat the MCP host and MCP client as one — the line can be blurry anyway.

Protocol layers

MCP is built on three main layers:

• Data layer: Defines the JSON-RPC endpoints that can be called to perform tool calls and access other features. Generally speaking
• JSON-RPC layer: MCP uses JSON-RPC 2.0 as its communication protocol. This provides a standardized request/response format and error handling.
• Transport layer: Specifies how JSON-RPC calls are made.

Transport mechanisms

MCP currently supports two transport mechanisms:

stdio transport (local)

The stdio transport is used for locally hosted MCP servers. The MCP client starts a process on the same machine, and the input/output handles become the communication channel for JSON-RPC calls.

Notably stdio has no standardized approach for auth, so it won’t be discussed further here.

HTTP streaming transport (remote)

The HTTP streaming transport is used for remote MCP servers accessible over the network. This transport uses standard HTTP requests, but also supports streaming responses.

Authentication is handled via a bearer token in the headers of the request. MCP auth formalises this into a particular approach which uses OAuth to obtain that token.

How it all works together

Here’s how the components interact in a typical MCP flow:

1. Discovery: The MCP client connects to your MCP server and discovers available tools
2. Authentication: If authentication is required, the client initiates an OAuth flow
3. Tool invocation: When the AI agent needs to use a tool, the client makes a call
4. Response processing: The server processes the request and returns a response
5. Integration: The client incorporates the response into the conversation