MCP Explained - What, How, Why & the Future

01 - What

What is MCP?

The Model Context Protocol is an open standard (introduced by Anthropic in late 2024) that defines a universal way for AI applications to connect to external systems. Before MCP, every integration between an AI app and a tool was bespoke: M apps × N tools = M×N custom connectors. MCP turns that into M+N - build a server once, and every MCP-compatible client can use it.

🖥️ Host

The user-facing AI app - Claude Code, Claude Desktop, an IDE, or your own agent built on the SDK. It runs the model and orchestrates everything.

🔌 Client

A connector living inside the host. One client per server, maintaining a 1:1 stateful session and speaking MCP on the model's behalf.

⚙️ Server

A separate program exposing capabilities - a filesystem, a database, GitHub, Slack, a private API. It does the real work when asked.

The three things a server exposes

Primitive	What it is	Controlled by	Example
Tools	Callable functions with typed inputs/outputs	The model decides when to call	`create_issue()`, `run_query()`
Resources	Readable data / context, addressed by URI	The app / user attaches	`file:///report.pdf`, `db://users/42`
Prompts	Reusable, parameterized prompt templates	The user invokes (slash commands)	`/summarize-pr`, `/plan-sprint`

Key mental model: the LLM never touches your database or API directly. It emits a structured request; the host mediates and approves; the server executes. MCP is the standardized contract in the middle.

02 - Why

Why MCP exists

LLMs are powerful but isolated - trapped behind their training cutoff with no access to your live data or the ability to act. Every team solving this independently produced brittle, one-off integrations. MCP standardizes the connection layer.

🧩 Solves the M×N problem

Write a server once; every MCP host (Claude, Cursor, Windsurf, custom agents) can use it. No re-integration per app.

🔄 Swappable & composable

Because tools are discovered at runtime, you can add, remove, or upgrade servers without touching the host. Agents compose many servers.

🔐 Clear trust boundaries

The host mediates every call and can require user approval. Servers run as isolated processes with scoped permissions and their own auth.

🌍 Open & vendor-neutral

An open spec with SDKs in Python, TypeScript, Java, C#, Go and more. Not tied to one model or one company.

03 - How

How it works under the hood

Every message is JSON-RPC 2.0. The client and server exchange requests, responses, and notifications over a transport. Two transports dominate:

📟 stdio (local)

The server is a subprocess; messages flow over stdin/stdout. Fast, no network, ideal for local tools (filesystem, git). Auth is implicit - it runs as you.

🌐 Streamable HTTP + SSE (remote)

The server is a web service reached over HTTP, with Server-Sent Events for streaming. Serves many clients, and uses OAuth 2.1 for authentication.

The connection lifecycle

Architecture - one host, many servers, one client per server

flowchart LR
    subgraph Host["🖥️  Host  (Claude Code / Desktop)"]
        LLM["🧠 LLM"]
        C1["🔌 Client A"]
        C2["🔌 Client B"]
        C3["🔌 Client C"]
        LLM <--> C1
        LLM <--> C2
        LLM <--> C3
    end
    C1 <-->|stdio| S1["⚙️ Filesystem Server"]
    C2 <-->|HTTP/SSE| S2["⚙️ GitHub Server"]
    C3 <-->|HTTP/SSE| S3["⚙️ Postgres Server"]
    S1 --> D1[("📁 Local files")]
    S2 --> D2{{"🌐 GitHub API"}}
    S3 --> D3[("🗄️ Database")]

A minimal config (Claude Code / Desktop)

{
  "mcpServers": {
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres",
               "postgresql://localhost/mydb"]
    },
    "github": {
      "url": "https://api.githubcopilot.com/mcp/",
      "headers": { "Authorization": "Bearer ${GITHUB_TOKEN}" }
    }
  }
}

The first is a local stdio server spawned as a subprocess; the second is a remote HTTP server. Same protocol, different transport.

04 - Sequence Diagrams

Detailed sequence diagrams

Three views: the initial handshake & discovery, a tool call at runtime, and the OAuth flow for remote servers.

Diagram 1 - Initialization & capability discovery (once, at connect)

sequenceDiagram
    autonumber
    participant U as 👤 User
    participant H as 🖥️ Host
    participant C as 🔌 Client
    participant S as ⚙️ Server

    U->>H: Launch app / add server
    H->>C: Spin up a client for this server
    C->>S: initialize (protocol version, capabilities)
    S-->>C: initialize result (server capabilities, info)
    C->>S: notifications/initialized
    Note over C,S: Session is now live
    C->>S: tools/list
    S-->>C: [tools + JSON Schemas]
    C->>S: resources/list
    S-->>C: [resources]
    C->>S: prompts/list
    S-->>C: [prompt templates]
    C-->>H: Register capabilities
    H->>H: Inject tool defs into model context

Diagram 2 - A tool call during a conversation (the hot path)

sequenceDiagram
    autonumber
    participant U as 👤 User
    participant LLM as 🧠 Model
    participant H as 🖥️ Host
    participant C as 🔌 Client
    participant S as ⚙️ Server
    participant Ext as 🌐 Data / API

    U->>H: "How many signups last week?"
    H->>LLM: prompt + available tools
    LLM-->>H: tool_use: run_query(sql=...)
    H->>U: Approve calling run_query? (optional)
    U-->>H: ✔ Approve
    H->>C: dispatch tool call
    C->>S: tools/call { name, arguments }
    S->>Ext: SELECT count(*) FROM signups ...
    Ext-->>S: rows
    S-->>C: tools/call result (structured content)
    C-->>H: result
    H->>LLM: tool result appended to context
    LLM-->>H: "You had 1,284 signups last week."
    H-->>U: Final answer

Diagram 3 - OAuth 2.1 authorization for a remote server

sequenceDiagram
    autonumber
    participant U as 👤 User
    participant C as 🔌 Client
    participant S as ⚙️ MCP Server
    participant A as 🔑 Auth Server

    C->>S: tools/call (no / expired token)
    S-->>C: 401 Unauthorized + WWW-Authenticate
    C->>A: Discover metadata, register client
    C->>U: Open browser → consent screen
    U->>A: Log in & grant scopes
    A-->>C: Authorization code (redirect)
    C->>A: Exchange code + PKCE for tokens
    A-->>C: access_token (+ refresh_token)
    C->>S: Retry tools/call (Bearer token)
    S-->>C: 200 OK + result

05 - Step by Step

The 0 → 100 flow

Everything that happens from cold start to a completed, tool-assisted answer - the whole journey in order.

Setup

Author or install a server

Someone writes an MCP server (or you install a published one) that wraps a system - a DB, an API, the filesystem - and declares its tools, resources, and prompts.

Configure

Register the server with the host

Add it to config: a command for stdio, or a url for HTTP. The host now knows the server exists.

Launch

Host starts the client & transport

On startup the host spawns one client per server and opens the transport - a subprocess pipe (stdio) or an HTTP connection.

Handshake

`initialize` exchange

Client and server negotiate protocol version and advertise capabilities, then the client sends notifications/initialized. The session is live.

Discovery

List tools, resources, prompts

The client calls tools/list, resources/list, prompts/list. The server returns names, descriptions, and JSON Schemas.

Inject

Host hands tools to the model

The discovered tool definitions are formatted and placed into the model's context so it knows what it can call and with what arguments.

Reason

User asks; model decides

The user sends a request. The model reasons over it and the available tools, and emits a structured tool_use request if a tool would help.

Guard

Host intercepts & (maybe) asks approval

The host catches the tool call. For sensitive actions it prompts the user to approve. Auth is checked; remote servers may trigger the OAuth flow here.

Execute

Server does the real work

The client sends tools/call; the server runs the query / hits the API / reads the file and returns structured results (and can stream progress).

Integrate

Result flows back into context

The host appends the tool result to the conversation and calls the model again. The model may chain more tool calls - loop back to step 60 as needed.

100

Deliver

Model answers the user

With the fresh, real-world data in context, the model produces a grounded final answer. Session stays open for the next turn.

06 - Case Studies

Real-world case studies

Three representative patterns showing MCP in production-style use.

👩‍💻

1 · The coding agent (Claude Code + GitHub + Postgres)

Pattern: developer productivity

A developer asks their assistant to "find the flaky test causing CI failures and open a fix PR." The agent composes three MCP servers.

Filesystem server (stdio) reads the failing test files and source.
Postgres server queries the CI results table to identify which test fails intermittently.
GitHub server (HTTP + OAuth) creates a branch, commits the fix, and opens a PR.

✅ Outcome: One natural-language request spans three systems with no custom integration code - each server was installed once and is reused across every project.

🏢

2 · Enterprise knowledge assistant (internal wiki + Jira + Slack)

Pattern: retrieval + action over private data

A support engineer asks: "Summarize open P1 incidents this week and post a digest to #ops." The company runs remote MCP servers behind SSO.

Jira server exposes search_issues as a tool and issues as resources - the model pulls live P1 tickets.
Wiki server resources supply runbook context for each incident type.
Slack server exposes post_message; the host requires explicit approval before posting.

✅ Outcome: OAuth scopes keep each user's access correct; the host's approval gate ensures the "write" action (posting) is human-confirmed. Same protocol, enterprise-grade trust.

🎨

3 · Design-to-code with Figma MCP

Pattern: bridging a proprietary app to any agent

A front-end dev selects a component in Figma and asks the agent to "build this as a React component." Figma ships an MCP server exposing the live design context.

The Figma server exposes the selected frame's structure, tokens, and layout as resources/tools.
The agent reads exact spacing, colors, and variants - not a screenshot guess.
The filesystem server writes the generated component into the repo.

✅ Outcome: A proprietary desktop app becomes usable by any MCP client. Design intent transfers with high fidelity because the model reads structured data, not pixels.

07 - Future

Where MCP is heading

MCP went from a single-vendor spec to a broadly adopted standard remarkably fast. The trajectory points at richer, safer, more autonomous agents.

🌐 A registry & ecosystem

Public server registries for discovery and one-click install - an "app store" for agent capabilities, with signing and provenance.

🤝 Agent-to-agent composition

Servers that are themselves agents, plus emerging agent-to-agent protocols, enabling networks of specialized agents that delegate to each other.

🔐 Stronger security & identity

Fine-grained scopes, standardized OAuth 2.1, tool-poisoning defenses, and auditability as MCP moves deeper into enterprises.

🧠 Elicitation & sampling

Servers can ask the user for input mid-task (elicitation) and request model completions from the host (sampling) - richer two-way interaction.

📦 Native platform support

OS-level and IDE-level MCP hosts, so any app can become an agent surface without bespoke plumbing.

⚡ Streaming & long-running work

Better support for progress streaming, cancellation, and durable long-running tasks - essential for real autonomous agents.

Bottom line: just as HTTP standardized the web and USB standardized peripherals, MCP is becoming the standard socket between AI models and the real world. Build a capability once - every agent, present and future, can use it.

What is MCP?

🖥️ Host

🔌 Client

⚙️ Server

The three things a server exposes

Why MCP exists

🧩 Solves the M×N problem

🔄 Swappable & composable

🔐 Clear trust boundaries

🌍 Open & vendor-neutral

How it works under the hood

📟 stdio (local)

🌐 Streamable HTTP + SSE (remote)

The connection lifecycle

A minimal config (Claude Code / Desktop)

Detailed sequence diagrams

The 0 → 100 flow

Author or install a server

Register the server with the host

Host starts the client & transport

initialize exchange

List tools, resources, prompts

Host hands tools to the model

User asks; model decides

Host intercepts & (maybe) asks approval

Server does the real work

Result flows back into context

Model answers the user

Real-world case studies

1 · The coding agent (Claude Code + GitHub + Postgres)

2 · Enterprise knowledge assistant (internal wiki + Jira + Slack)

3 · Design-to-code with Figma MCP

Where MCP is heading

🌐 A registry & ecosystem

🤝 Agent-to-agent composition

🔐 Stronger security & identity

🧠 Elicitation & sampling

📦 Native platform support

⚡ Streaming & long-running work

`initialize` exchange