Demystifying AI Agents & MCP

01

Anatomy of an AI Agent

Every agent runs the same core loop, over and over, until the task is done. Click a stage to see what actually happens inside it.

02

What is Model Context Protocol (MCP)?

MCP is an open standard for connecting AI applications to external tools, data, and systems: the "USB-C port" for AI integrations.

Without MCP

Every app needs a custom integration for every tool: N × M connections.

3 apps × 4 tools = 12 bespoke integrations to build and maintain.

With MCP

Apps and tools each implement the protocol once: N + M connections.

3 apps + 4 tools = 7 implementations, all interoperable.

Core concepts

Six building blocks make up the protocol.

app-side

Host

The AI application the user talks to (e.g. an IDE, desktop app, or chatbot) that manages one or more MCP clients.

app-side

Client

Lives inside the host, keeps a 1:1 stateful connection to exactly one server, and speaks JSON-RPC on its behalf.

tool-side

Server

A lightweight process that exposes one system's capabilities (GitHub, Postgres, Slack) through the protocol.

app-controlled

Resources

Read-only contextual data (files, DB schemas, docs) the host decides when to load into context.

model-controlled

Tools

Executable functions (run_query, create_issue) the model itself chooses to invoke.

user-controlled

Prompts

Reusable, server-defined prompt templates a user can explicitly pick, e.g. "/summarize-pr".

Transport: messages are JSON-RPC 2.0, sent over stdio for local servers or SSE / streamable HTTP for remote ones.

{ "jsonrpc": "2.0", "id": 7,
  "method": "tools/call",
  "params": { "name": "run_query", "arguments": {...} } }

03

Agents + MCP, working together

A single request can fan out across multiple tools. Here's what happens end-to-end.

"Check my SQL database and update the Jira ticket if the row count changed."

04

Diagrams

The same system, two views: the request flow over time, and the architecture at rest.

Sequence: request flow

User → Agent Host → MCP Client → MCP Servers → external systems, and back.

sequenceDiagram
    actor U as User
    participant H as Agent Host
    participant C as MCP Client
    participant S1 as MCP Server (Postgres)
    participant DB as Postgres DB
    participant S2 as MCP Server (Jira)
    participant J as Jira API

    U->>H: "Check my SQL database and update the Jira ticket"
    H->>H: Reason & plan (LLM)
    H->>C: tools/call run_query
    C->>S1: JSON-RPC 2.0 request
    S1->>DB: SQL SELECT
    DB-->>S1: rows
    S1-->>C: tool result
    C-->>H: result
    H->>H: Reflect: did row count change?
    H->>C: tools/call update_issue
    C->>S2: JSON-RPC 2.0 request
    S2->>J: PATCH /issue/{id}
    J-->>S2: 200 OK
    S2-->>C: tool result
    C-->>H: result
    H-->>U: "Row count changed. Jira ticket updated."

Flowchart: architecture map

One host, one protocol, many interchangeable servers.

flowchart LR
    subgraph HostApp["AI Application (Host)"]
        Agent["Agent / LLM Reasoning Loop"]
        Client["MCP Client"]
        Agent --> Client
    end

    Client <-->|"JSON-RPC 2.0 over stdio / SSE"| Proto{{"MCP Protocol"}}

    Proto <--> S1["MCP Server: GitHub"]
    Proto <--> S2["MCP Server: Postgres"]
    Proto <--> S3["MCP Server: Slack"]

    S1 <--> GH[("GitHub API")]
    S2 <--> PG[("Postgres DB")]
    S3 <--> SL[("Slack API")]

Demystifying AI Agents & the Model Context Protocol