← All learnings
🎓 Course

MCP: Building Context-Aware AI Apps with Anthropic

DeepLearning.AI · June 2025 Completed

A short course from the Anthropic team on the Model Context Protocol. The right place to start if you want the spec from the source rather than from secondary explainers.

These are my notes from working through it — what MCP actually is, how the wire protocol is shaped, what the primitives mean in practice, and where the protocol is heading.

What MCP is

MCP is an open protocol that standardizes how LLM applications connect to tools and data sources. The pitch is one analogy: REST standardized how web apps talk to backends, LSP standardized how IDEs talk to language tooling, MCP standardizes how AI applications talk to external systems.

Before MCP, every AI app rolled its own integration stack — custom implementation, custom prompt logic, custom tool calls, custom data access — for every backend it touched. Three apps wanting Google Drive meant three separate Google Drive integrations.

flowchart LR
    subgraph Before["Without MCP"]
        A1[AI App 1] --> I1[Custom impl] --> P1[Custom prompts] --> T1[Custom tools] --> D1[Custom data access]
        A2[AI App 2] --> I2[Custom impl] --> P2[Custom prompts] --> T2[Custom tools] --> D2[Custom data access]
        A3[AI App 3] --> I3[Custom impl] --> P3[Custom prompts] --> T3[Custom tools] --> D3[Custom data access]
    end

With MCP, the integration is built once as a server, and any MCP-compatible client can use it. Three apps wanting Google Drive share one Google Drive MCP server.

flowchart LR
    A1[AI Assistant] --> S
    A2[AI Agent] --> S
    A3[IDE / Desktop App] --> S
    S[Google Drive MCP Server] --> G[Google Drive]

The value lands differently depending on who you are:

The ecosystem is moving fast: 3,000+ MCP servers exist already, spanning AI applications (from IDEs to agents), independent server builders, enterprises building for internal and external use cases, and OSS contributors.

How the wire works

MCP uses a client-server architecture with three roles:

A host with multiple integrations runs multiple clients, one per server.

flowchart LR
    subgraph Host["Host (e.g. Claude Desktop)"]
        C1[MCP Client 1]
        C2[MCP Client 2]
        C3[MCP Client 3]
    end
    C1 <-->|MCP Protocol| S1[MCP Server: Drive]
    C2 <-->|MCP Protocol| S2[MCP Server: GitHub]
    C3 <-->|MCP Protocol| S3[MCP Server: Postgres]

Primitives

Each side exposes a small, fixed set of primitives.

Server primitives:

Client primitives:

Lifecycle

Every connection goes through three phases:

sequenceDiagram
    participant C as MCP Client
    participant S as MCP Server
    Note over C,S: 1. Initialization
    C->>S: Initialize request
    S->>C: Initialize response
    C->>S: Initialized notification
    Note over C,S: 2. Message exchange
    C->>S: Request
    S->>C: Response
    Note over C,S: 3. Termination
    C->>S: Close

Transports

A transport is the underlying mechanism that moves messages between client and server.

The Streamable HTTP exchange in practice:

sequenceDiagram
    participant C as MCP Client
    participant S as MCP Server (remote)
    C->>S: POST /mcp (initialize)
    S->>C: Initialize response
    opt SSE channel
        C->>S: GET /mcp (Accept: text/event-stream)
        S-->>C: Server-pushed messages
    end
    C->>S: POST /mcp (request)
    S->>C: HTTP response
    opt Stateful session
        C->>S: DELETE /mcp (terminate)
        S->>C: Session terminated
    end

Authentication

The March 2025 spec adds OAuth 2.1 support — optional in MCP itself, important for remote servers (stdio servers can lean on environment variables).

The auth standards in play:

The PKCE flow looks like this when an MCP client hits an unauthenticated server:

sequenceDiagram
    participant U as User-Agent (Browser)
    participant C as MCP Client
    participant S as MCP Server
    C->>S: MCP Request
    S->>C: HTTP 401 Unauthorized
    Note over C: Generate code_verifier<br/>and code_challenge
    C->>U: Open browser with auth URL + code_challenge
    U->>S: GET /authorize
    Note over S: User logs in and authorizes
    S->>U: Redirect to callback with auth code
    U->>C: Callback with authorization code
    C->>S: Token request (code + code_verifier)
    S->>C: Access token
    C->>S: MCP Request with access token

This lets MCP servers piggyback on existing OAuth providers — Auth0, Google APIs, GitHub — without inventing new auth machinery.

Where this is going

The protocol is still moving. A few directions worth flagging.

Composability through Sampling. An MCP server can itself act as a client to other servers. That lets you chain agents — an orchestrator client/server talks to specialist client/servers (analysis, coding, research) — while inference stays controlled by the original host application. The host owns cost, privacy, and model choice; the chain owns capability.

flowchart LR
    App[Application + LLM] --> Orch[Orchestrator<br/>Client + Server]
    Orch --> A[Analysis Agent<br/>Client + Server]
    Orch --> C[Coding Agent<br/>Client + Server]
    Orch --> R[Research Agent<br/>Client + Server]

Server discovery and a Registry API. A unified, hosted metadata service for MCP servers, giving Discovery (find servers for a capability), Centralization (one place to look), and Verification (signed / trusted entries).

Two patterns this unlocks. First, site-level discovery — a service publishes a .well-known/mcp.json advertising its servers, and an agent fetches that file to learn what’s available. A user asks “help me manage my Shopify store” and the agent finds shopify.com/.well-known/mcp.json listing the relevant endpoints.

Second, self-evolving agents — the agent doesn’t ship with a fixed toolkit. Given a task (“fix the bug based on my Grafana logs”), it searches the registry, installs the official Grafana server on demand, and uses it. The agent’s capabilities grow with the registry.

Other items on the roadmap. From the course’s closing slide:

What I took away

MCP is doing useful work at the right layer — standardizing the protocol surface between AI applications and external systems, without prescribing how either side is built. The course is mostly conceptual; the hands-on workbooks (building a research-paper server, testing it with MCP Inspector, deploying it remotely) are where the spec actually clicks.

The protocol is still moving — March 2025 dropped HTTP+SSE for Streamable HTTP and added OAuth 2.1, and the registry standard is in flight. Production at scale needs that registry to land, plus more battle-testing of the auth and namespacing story. But the foundation is solid, and worth understanding from the source rather than from one of the many MCP explainer posts of varying accuracy.

MCPAI AgentsAnthropicInteroperabilityProtocolsOAuthTool Use