MCP (Model Context Protocol)

The Problem

Why MCP?

AI agents need to interact with external tools and data sources. Before MCP, every integration was custom: different APIs, different auth methods, different error handling.

MCP (Model Context Protocol) standardizes this. Anthropic released it in November 2024, and it's now under the AAIF (Agentic AI Foundation) at the Linux Foundation. Thousands of MCP servers already exist for GitHub, Slack, Google Drive, Postgres, and more.

(Not to be confused with A2A, which handles agent-to-agent communication. MCP connects agents to tools.)

What MCP Solves

Three Core Problems

MCP addresses three fundamental challenges for agent-tool integration:

🔌

N×M Integration

N agents × M tools = N×M custom integrations. MCP reduces this to N+M: each agent implements MCP once, each tool exposes MCP once.

📋

Capability Discovery

How does an agent know what tools are available? MCP servers declare their capabilities: tools, resources, and prompts with JSON schemas.

🔐

Authentication

How do agents authenticate to tools? MCP mandates OAuth 2.1 with PKCE for remote servers, plus resource indicators for scoped tokens.

Think of MCP as a universal adapter. Build one integration, connect to any compatible tool.

How It Works

Architecture

The architecture is simple: clients (agents) talk to servers (tools) over a standard protocol.

Core Concepts

🤖

MCP Client

The AI agent (Claude, GPT, your agent)

🔧

MCP Server

Wraps a tool/API (GitHub, Slack, your DB)

📋

Protocol

JSON-RPC 2.0 over stdio or HTTP

Capabilities

MCP servers expose three types of capabilities:

📄

Resources

Read-only data

🔧

Tools

Functions with side effects

💬

Prompts

Templates and workflows

Tools are where the action happens. The LLM sees tool schemas and decides when to call them:

Tool Definition

{
  "name": "crm_search_contacts",
  "description": "Search contacts by name or email",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query": { "type": "string" }
    },
    "required": ["query"]
  }
}

Authentication

What the Spec Requires

MCP supports two transport mechanisms with different auth models:

Transport Comparison

Local     │ Server runs as subprocess on your machine
(stdio)   │ Auth: None required - inherits env credentials
          │ Use: CLI tools, desktop apps, local dev
──────────┼──────────────────────────────────────
Remote    │ Server hosted elsewhere, accessed via HTTP
(HTTP+SSE)│ Auth: OAuth 2.1 + PKCE (spec mandates this)
          │ Use: SaaS integrations, shared servers

For remote HTTP connections, the MCP spec (2025-11-25) mandates specific OAuth standards:

OAuth 2.1 PKCE S256 RFC 8707 RFC 9728

▶ What do these standards do?

OAuth 2.1

The latest OAuth standard. Mandates PKCE for all clients, deprecates implicit flow and password grants.

PKCE S256

Proof Key for Code Exchange. Prevents authorization code interception by requiring clients prove they initiated the request.

RFC 8707 Resource Indicators

Binds tokens to specific audiences. Without this, leaked tokens can be replayed to any service. Resource indicators ensure a token issued for MCP Server A can't be used against Server B.

RFC 9728 Protected Resource Metadata

Enables auth server discovery. The MCP server tells clients which authorization server to use via /.well-known/oauth-protected-resource.

Best Practice: On-Behalf-Of

The MCP spec allows various OAuth flows, but when agents access user data, one pattern stands out:

Token Exchange (RFC 8693)

The agent exchanges the user's token for a new token scoped to the MCP server. The resulting token identifies both the user and the acting agent.

This is the On-Behalf-Of (OBO) pattern. It preserves user identity, enabling:

Audit trails: MCP server knows Alice requested this via Agent X
Fine-grained authorization: Policies consider both user and agent
Least privilege: Tokens scoped to specific resources

Why not client_credentials?

With client_credentials, the MCP server only sees "Agent X is calling me". It can't enforce user-specific policies or audit who actually requested the action.

The demo below shows the OBO flow in practice. For a deep dive on the pattern, see my OBO Explainer.

See It In Action

MCP Flow with OBO

Request

-

Response

-

Security Risks

MCP Creates New Attack Surface

MCP solves integration. It also introduces new security risks.

What MCP Gives You

Standard protocol
Capability discovery
OAuth 2.1 authentication
Scoped tokens

Your Responsibility

Vetting which servers to trust
Avoiding overprivileged tokens
Validating tool behavior

Primary Attack Vectors

⚠

Overprivileged Tokens

An MCP server with a powerful token (admin PAT, service account) becomes a confused deputy. Any user's agent can leverage those privileges.

⚠

Tool Schema Manipulation

Server lies about what a tool does. Description says "search contacts" but implementation exfiltrates data.

⚠

Resource Poisoning

Malicious content in tool responses triggers prompt injection.

See Hou et al. for the full threat taxonomy.

Real-World Incidents

These aren't theoretical. MCP security incidents are already happening:

May 2025

GitHub MCP - Private repos leaked via prompt injection in malicious issues

Jul 2025

Filesystem MCP - Sandbox escape via symlink bypass (CVE-2025-53109)

More: AuthZed MCP Security Timeline

Who Benefits

Different Stakeholders, Same Protocol

🤖

Agent Developer

"How do I connect to 10 different tools?"

Implement MCP once. Connect to any MCP server.

🔧

Tool Provider

"How do I make my API agent-accessible?"

Build one MCP server. Work with every MCP client.

🏗️

Enterprise Architect

"How do I standardize agent integrations?"

MCP as protocol layer. Gateway for audit and control.

🛡️

Security Team

"How do I audit what agents access?"

Capability declarations visible. Scoped tokens enforceable.

For enterprise deployments, consider an MCP gateway:

AgentGateway (LF) Docker Microsoft

What's Still Missing

The Trust Gap

MCP handles transport and auth to the server. It doesn't handle trust of the server.

✓ Server identity

TLS verifies domain ownership. An MCP server at tools.acme.com proves Acme controls it.

✓ Within your organization

You deploy your own MCP servers, you trust them. Standard auth works fine.

✗ Cross-organization discovery

No standard way to discover trustworthy MCP servers. No verification of capability claims. No delegation chain tracking.

✗ Non-repudiation

TLS encrypts the connection, but doesn't sign individual messages. If there's a dispute about what was sent, there's no cryptographic proof. Audit logs rely on trusting the logger.

✗ Trust durability

Trust is session-based and domain-centric. If a server migrates infrastructure, changes domains, or rotates certificates, previous trust relationships break. No persistent identity across these changes.

✗ Metadata privacy

TLS protects content, but network observers and intermediaries can still see who's talking to whom. For sensitive agent interactions, this traffic analysis is itself a privacy leak.

Third-Party MCP Servers

Connecting to external SaaS MCP servers from your enterprise creates a policy gap:

The problem: External MCP servers use external IdPs. Your enterprise IdP isn't in the loop.

MCP gateways help inbound (user → gateway), but outbound (gateway → external IdP) is out of band
Which users are allowed to connect to which external servers?
How do you audit usage? On whose authority?
Can you revoke access?

MCP gateways like AgentGateway are adding auth portals to manage these external connections from a single enforcement point.

Beyond Single Trust Domains?

For most use cases (your own servers, established SaaS providers) TLS and OAuth are enough. You know who you're talking to.

The gap appears in open ecosystems where you can't pre-establish trust. DIDs and Verifiable Credentials offer a path forward:

Discoverable identity without centralized registries
Verifiable capability claims issued by trusted parties, not self-asserted
Delegation chains that can be cryptographically verified across boundaries

Same gaps as A2A. Both protocols need this trust layer for open ecosystems. TSP (Trust Spanning Protocol) is the emerging answer from the Trust over IP Foundation.

MCP vs A2A