Model Context Protocol

Protocol Primitives

MCP defines three primitives, each with a different control model that determines who initiates the interaction.

Transport Comparison

Core JSON-RPC Methods

Capability Negotiation

During initialization, client and server declare what features they support. Only negotiated capabilities are used during the session.

The Three Participants

MCP cleanly separates concerns across three roles. A single application can contain all three, but the boundaries matter for security and modularity.

  +--------------------------------------------------+
  |                     HOST                         |
  |  (Claude Desktop, IDE, AI application)           |
  |                                                  |
  |   +------------+   +------------+   +----------+ |
  |   |  MCP       |   |  MCP       |   |  MCP     | |
  |   |  Client A  |   |  Client B  |   |  Client  | |
  |   +-----+------+   +-----+------+   +----+-----+ |
  +---------|---------------|---------------- |-------+
            |               |                 |
     +------+------+  +-----+-------+  +------+------+
     |  MCP        |  |  MCP        |  |  MCP        |
     |  Server A   |  |  Server B   |  |  Server C   |
     |  (files)    |  |  (database) |  |  (API)      |
     +-------------+  +-------------+  +-------------+

Two Protocol Layers

Lifecycle Phases

Every MCP connection goes through three phases. The handshake ensures both sides agree on protocol version and capabilities before any real work begins.

Initialize Handshake

The initialization exchange sets the protocol version and declares capabilities. The latest protocol version is 2025-03-26.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-03-26",
    "capabilities": {
      "roots": { "listChanged": true },
      "sampling": {}
    },
    "clientInfo": {
      "name": "my-ai-app",
      "version": "1.0.0"
    }
  }
}

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "protocolVersion": "2025-03-26",
    "capabilities": {
      "tools": { "listChanged": true },
      "resources": { "subscribe": true, "listChanged": true },
      "prompts": { "listChanged": true },
      "logging": {}
    },
    "serverInfo": {
      "name": "weather-server",
      "version": "1.0.0"
    }
  }
}

Install the SDK

pip install "mcp[cli]"

npm install @modelcontextprotocol/sdk

First Server — Python (FastMCP)

FastMCP is the high-level Python framework that handles all the protocol details. You just write decorated functions.

from mcp.server.fastmcp import FastMCP

# Create an MCP server with a name
mcp = FastMCP("weather")

@mcp.tool
def get_weather(location: str) -> str:
    """Get current weather for a location."""
    # Your real implementation here
    return f"Weather in {location}: 72F, sunny"

@mcp.resource("config://app")
def get_config() -> str:
    """Application configuration."""
    return "debug=true\nlog_level=info"

@mcp.prompt()
def review_code(code: str) -> str:
    """Review the given code for issues."""
    return f"Please review this code:\n\n{code}"

Run the server locally with stdio transport:

mcp dev server.py

First Server — TypeScript

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new McpServer({
  name: "weather",
  version: "1.0.0"
});

server.tool(
  "get_weather",
  "Get current weather for a location",
  { location: z.string() },
  async ({ location }) => ({
    content: [{
      type: "text",
      text: `Weather in ${location}: 72F, sunny`
    }]
  })
);

const transport = new StdioServerTransport();
await server.connect(transport);

Configure Claude Desktop

Add your server to Claude Desktop's configuration file to make it available in the app.

{
  "mcpServers": {
    "weather": {
      "command": "python",
      "args": ["server.py"],
      "env": {
        "WEATHER_API_KEY": "your-key-here"
      }
    }
  }
}

Configure Claude Code

Claude Code uses a project-level .mcp.json file or global settings.

{
  "mcpServers": {
    "weather": {
      "command": "python",
      "args": ["server.py"],
      "env": {
        "API_KEY": "${WEATHER_KEY:-sk-default}"
      }
    }
  }
}

Or add via the CLI:

# Basic: add a stdio server
claude mcp add weather python server.py

# With environment variables
claude mcp add weather --env WEATHER_KEY=sk-123 python server.py

# Scoped: project-only (default) or user-wide
claude mcp add weather --scope user python server.py

# HTTP transport (Streamable HTTP or SSE)
claude mcp add weather --transport http https://example.com/mcp

Configure VS Code

VS Code supports MCP servers through a workspace-level config file.

{
  "servers": {
    "weather": {
      "command": "python",
      "args": ["server.py"],
      "env": {
        "API_KEY": "${WEATHER_KEY}"
      }
    }
  }
}

Test with MCP Inspector

The MCP Inspector is a visual debugging tool that lets you interact with your server directly.

# Launch inspector for your server
mcp dev server.py

# Or use npx for the TypeScript inspector
npx @modelcontextprotocol/inspector node server.js

The Inspector opens a web UI where you can browse tools, resources, and prompts, invoke them with test inputs, and inspect the raw JSON-RPC messages.

What Are Tools?

Tools are executable functions exposed by MCP servers that the AI model can decide to invoke based on conversation context. Unlike resources (which are application-controlled) or prompts (which are user-controlled), tools are model-controlled — the LLM autonomously decides when and how to call them.

Tool Definition Schema

Every tool is defined with a JSON Schema that describes its name, purpose, inputs, outputs, and behavioral annotations. Servers expose these definitions via tools/list.

{
  "name": "get_weather",
  "title": "Weather Provider",
  "description": "Get current weather for a location",
  "inputSchema": {
    "type": "object",
    "properties": {
      "location": {
        "type": "string",
        "description": "City name or zip code"
      }
    },
    "required": ["location"]
  },
  "outputSchema": {
    "type": "object",
    "properties": {
      "temperature": { "type": "number" },
      "conditions": { "type": "string" }
    }
  },
  "annotations": {
    "readOnlyHint": true,
    "openWorldHint": true
  }
}

Calling Tools

The client invokes a tool via tools/call, passing the tool name and arguments. The server executes the tool and returns structured content.

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": {
      "location": "New York"
    }
  }
}

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "content": [{
      "type": "text",
      "text": "72°F, sunny"
    }],
    "isError": false
  }
}

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "content": [{
      "type": "text",
      "text": "Invalid location: coordinates out of range"
    }],
    "isError": true
  }
}

Tool Annotations

Annotations are optional behavioral hints that describe a tool's side effects and interaction model. Clients can use them to make UI and safety decisions.

Error Handling

MCP distinguishes between two error modes. Understanding the difference is critical for building robust integrations.

Content Types

Tool results can include multiple content items of different types in the content array.

{
  "content": [
    { "type": "text", "text": "Analysis complete. See chart below." },
    {
      "type": "image",
      "data": "iVBORw0KGgo...",
      "mimeType": "image/png"
    },
    {
      "type": "resource_link",
      "uri": "file:///reports/analysis.csv",
      "name": "Full Data",
      "mimeType": "text/csv"
    }
  ]
}

What Are Resources?

Resources are URI-addressable data sources that provide context to the LLM. Unlike tools, resources are application-controlled — the host application decides which resources to attach to the model's context, not the model itself.

Listing Resources

Clients discover available resources via resources/list. The server returns a paginated list of concrete resources with their URIs, descriptions, and metadata.

{
  "jsonrpc": "2.0",
  "id": 3,
  "result": {
    "resources": [
      {
        "uri": "file:///project/src/main.rs",
        "name": "main.rs",
        "description": "Primary application entry point",
        "mimeType": "text/x-rust",
        "size": 1234
      },
      {
        "uri": "config://app/settings",
        "name": "App Settings",
        "description": "Current application configuration",
        "mimeType": "application/json"
      }
    ]
  }
}

Reading Resources

Clients fetch resource content via resources/read. Resources can return text or binary (base64-encoded) content.

// Request
{
  "method": "resources/read",
  "params": { "uri": "file:///project/src/main.rs" }
}

// Response
{
  "result": {
    "contents": [{
      "uri": "file:///project/src/main.rs",
      "mimeType": "text/x-rust",
      "text": "fn main() {\n    println!(\"Hello, world!\");\n}"
    }]
  }
}

{
  "result": {
    "contents": [{
      "uri": "file:///project/logo.png",
      "mimeType": "image/png",
      "blob": "iVBORw0KGgoAAAANSUhEUgAA..."
    }]
  }
}

Resource Templates

Resource templates use URI Templates (RFC 6570) to expose dynamic, parameterized resources. Instead of listing every possible file, a server can expose a template that the client fills in.

{
  "uriTemplate": "file:///{path}",
  "name": "Project Files",
  "description": "Access any file in the project by path",
  "mimeType": "application/octet-stream"
}

// Database table rows
{ "uriTemplate": "db://tables/{table}/rows/{id}" }

// Git repository at a specific ref
{ "uriTemplate": "git://{repo}/blob/{ref}/{path}" }

// API endpoint with query parameters
{ "uriTemplate": "api://search?q={query}&limit={limit}" }

Subscriptions

Clients can subscribe to resource changes and receive real-time notifications when content updates.

// Client subscribes
{
  "method": "resources/subscribe",
  "params": { "uri": "file:///project/src/main.rs" }
}

// Server notifies on change
{
  "method": "notifications/resources/updated",
  "params": { "uri": "file:///project/src/main.rs" }
}

// Client re-reads the resource
{
  "method": "resources/read",
  "params": { "uri": "file:///project/src/main.rs" }
}

Resource Annotations

Resources can include annotations that help clients decide how to present them to the model.

{
  "uri": "file:///project/README.md",
  "name": "Project README",
  "mimeType": "text/markdown",
  "annotations": {
    "audience": ["assistant"],
    "priority": 0.8,
    "lastModified": "2025-03-15T10:30:00Z"
  }
}

What Are Prompts?

Prompts are reusable message templates that users explicitly choose to invoke. They are user-controlled — the human selects a prompt from a menu, slash command, or UI action. The server defines the template; the user triggers it.

Listing Prompts

Clients discover available prompts via prompts/list. Each prompt declares its name, description, and any required arguments.

{
  "jsonrpc": "2.0",
  "id": 4,
  "result": {
    "prompts": [
      {
        "name": "review_code",
        "description": "Review code for bugs, style issues, and improvements",
        "arguments": [
          {
            "name": "code",
            "description": "The code to review",
            "required": true
          },
          {
            "name": "language",
            "description": "Programming language",
            "required": false
          }
        ]
      },
      {
        "name": "explain_error",
        "description": "Explain an error message and suggest fixes",
        "arguments": [
          {
            "name": "error",
            "description": "The error message or stack trace",
            "required": true
          }
        ]
      }
    ]
  }
}

Getting Prompts

The client resolves a prompt template into concrete messages via prompts/get, passing any required arguments. The server interpolates the arguments and returns ready-to-use messages.

{
  "jsonrpc": "2.0",
  "id": 5,
  "method": "prompts/get",
  "params": {
    "name": "review_code",
    "arguments": {
      "code": "def hello():\n    print('world')"
    }
  }
}

{
  "jsonrpc": "2.0",
  "id": 5,
  "result": {
    "description": "Code review prompt",
    "messages": [{
      "role": "user",
      "content": {
        "type": "text",
        "text": "Please review this code:\ndef hello():\n    print('world')"
      }
    }]
  }
}

Multi-Step Prompts

Prompts can return multiple messages with different roles, creating a structured conversation flow that guides the model's behavior.

{
  "result": {
    "description": "Guided debugging workflow",
    "messages": [
      {
        "role": "user",
        "content": {
          "type": "text",
          "text": "I'm getting this error: TypeError: Cannot read properties of undefined"
        }
      },
      {
        "role": "assistant",
        "content": {
          "type": "text",
          "text": "I'll help debug this. Let me analyze the error systematically:\n\n1. First, I'll identify what variable is undefined\n2. Then trace where it should have been set\n3. Finally, suggest a fix"
        }
      },
      {
        "role": "user",
        "content": {
          "type": "text",
          "text": "Here is the relevant source code. Please proceed with the analysis."
        }
      }
    ]
  }
}

Embedded Resources

Prompt messages can embed resource content directly, combining the prompt template with live data from the server.

{
  "result": {
    "messages": [{
      "role": "user",
      "content": {
        "type": "resource",
        "resource": {
          "uri": "file:///project/src/main.rs",
          "mimeType": "text/x-rust",
          "text": "fn main() {\n    println!(\"Hello, world!\");\n}"
        }
      }
    },
    {
      "role": "user",
      "content": {
        "type": "text",
        "text": "Please review the above file for potential improvements."
      }
    }]
  }
}

Transport Overview

MCP uses JSON-RPC 2.0 messages encoded as UTF-8 over two standard transports. The protocol layer is identical regardless of transport — only the delivery mechanism changes.

stdio Transport

The simplest transport: the client launches the server as a subprocess and communicates via standard I/O streams. Messages are newline-delimited JSON-RPC.

  Client launches subprocess
    → Client writes JSON-RPC to stdin
    ← Server writes JSON-RPC to stdout
    ← Server logs to stderr (optional)

  Shutdown:
    Client closes stdin → SIGTERM → SIGKILL

Best for: Local tools, IDE integrations, same-machine processes, zero network overhead. Most development-time MCP servers use stdio.

Streamable HTTP Transport

For remote and multi-client scenarios, the server exposes a single HTTP endpoint (e.g., https://example.com/mcp). This transport supports both request-response and streaming patterns.

POST /mcp HTTP/1.1
Host: example.com
Content-Type: application/json
Accept: application/json, text/event-stream
MCP-Session-Id: abc123
MCP-Protocol-Version: 2025-03-26

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": { "location": "NYC" }
  }
}

import express from "express";
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StreamableHTTPServerTransport } from
  "@modelcontextprotocol/sdk/server/streamableHttp.js";

const app = express();
app.use(express.json());

app.all("/mcp", async (req, res) => {
  const server = new McpServer({ name: "remote", version: "1.0.0" });
  // Register tools on `server` here...
  const transport = new StreamableHTTPServerTransport({ sessionIdGenerator: undefined });
  await server.connect(transport);
  await transport.handleRequest(req, res, req.body);
});

app.listen(3000);

Best for: Remote servers, multi-tenant platforms, cloud services, cross-network integrations where multiple clients connect to the same server.

Session Management

Streamable HTTP connections use session IDs to maintain state across requests. Sessions are optional but recommended for any stateful interaction.

Security Considerations

MCP transports require careful security configuration, especially when servers accept network connections.

Transport Comparison

Python with FastMCP

FastMCP is the high-level Python framework for building MCP servers. Decorators map directly to MCP primitives — @mcp.tool for tools, @mcp.resource() for resources, and @mcp.prompt() for prompts.

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("my-server")

# Tools — model-controlled actions
@mcp.tool
def calculate(expression: str) -> str:
    """Evaluate a math expression."""
    return str(eval(expression))

# Resources — structured data with URI templates
@mcp.resource("data://users/{user_id}")
def get_user(user_id: str) -> str:
    """Fetch user profile data."""
    return json.dumps({"id": user_id, "name": "Alice"})

# Prompts — templated workflows
@mcp.prompt()
def review_code(code: str) -> str:
    """Generate a code review prompt."""
    return f"Please review this code for bugs and improvements:\n\n{code}"

TypeScript with MCP SDK

The official TypeScript SDK provides McpServer for building servers and uses Zod schemas for input validation.

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new McpServer({
  name: "my-server",
  version: "1.0.0"
});

// Register a tool with Zod schema validation
server.tool(
  "calculate",
  { expression: z.string() },
  async ({ expression }) => ({
    content: [{ type: "text", text: String(eval(expression)) }]
  })
);

// Connect via stdio transport
const transport = new StdioServerTransport();
await server.connect(transport);

Server Lifecycle

Production servers need proper startup and shutdown handling. Both SDKs support lifecycle hooks for resource management.

from contextlib import asynccontextmanager
from dataclasses import dataclass

@dataclass
class AppState:
    db: Database
    cache: Redis

@asynccontextmanager
async def lifespan(server):
    # Startup: initialize connections, load config
    db = await Database.connect("postgres://...")
    cache = await Redis.connect("redis://...")
    try:
        yield AppState(db=db, cache=cache)
    finally:
        # Shutdown: clean up resources
        await cache.close()
        await db.close()

mcp = FastMCP("my-server", lifespan=lifespan)

@mcp.tool
async def query(ctx: Context, sql: str) -> str:
    state: AppState = ctx.request_context.lifespan_context
    return str(await state.db.execute(sql))

Error Handling Patterns

MCP distinguishes between tool execution errors (reported in the result) and protocol errors (thrown as exceptions). Getting this right helps LLMs self-correct.

@mcp.tool
def get_file(path: str) -> str:
    try:
        return Path(path).read_text()
    except FileNotFoundError:
        # Return error as tool result — LLM sees this and can try another path
        raise ToolError(f"File not found: {path}. Check the path and try again.")

Testing with MCP Inspector

The MCP Inspector is an interactive debugging tool for testing servers during development. It connects to your server, discovers capabilities, and lets you call tools and read resources manually.

# Test a Python server
npx @modelcontextprotocol/inspector python server.py

# Test a Node.js server
npx @modelcontextprotocol/inspector node server.js

# Test with environment variables
npx @modelcontextprotocol/inspector -e API_KEY=sk-xxx python server.py

Client Architecture

In MCP, the host application creates one Client instance per server connection. Each client manages its own lifecycle independently — initialization, capability discovery, tool calls, and shutdown are all scoped to a single server session.

  +-------------------------------------------+
  |              HOST APPLICATION              |
  |                                            |
  |   +----------+  +----------+  +----------+ |
  |   | Client 1 |  | Client 2 |  | Client 3 | |
  |   +----+-----+  +----+-----+  +----+-----+ |
  +--------|-------------|-------------|--------+
           |             |             |
     +-----+-----+ +----+------+ +----+------+
     | Server A   | | Server B  | | Server C  |
     | (files)    | | (git)     | | (database)|
     +------------+ +-----------+ +-----------+

Python Client

The Python SDK provides ClientSession with async context managers for clean connection lifecycle management.

from mcp import ClientSession, StdioServerParameters
from mcp.client.stdio import stdio_client

# Define server connection parameters
params = StdioServerParameters(
    command="python",
    args=["server.py"]
)

# Connect and interact
async with stdio_client(params) as (read, write):
    async with ClientSession(read, write) as session:
        # Initialize the connection
        await session.initialize()

        # Discover available tools
        tools = await session.list_tools()
        for tool in tools.tools:
            print(f"{tool.name}: {tool.description}")

        # Call a tool
        result = await session.call_tool(
            "get_weather",
            {"location": "NYC"}
        )
        print(result.content[0].text)

TypeScript Client

The TypeScript SDK's Client class manages server connections with explicit transport configuration.

import { Client } from "@modelcontextprotocol/sdk/client/index.js";
import { StdioClientTransport } from "@modelcontextprotocol/sdk/client/stdio.js";

// Create transport and client
const transport = new StdioClientTransport({
  command: "python",
  args: ["server.py"]
});

const client = new Client({
  name: "my-app",
  version: "1.0.0"
});

// Connect and initialize
await client.connect(transport);

// Discover and call tools
const tools = await client.listTools();
const result = await client.callTool("get_weather", {
  location: "NYC"
});

console.log(result.content[0].text);

// Clean up
await client.close();

Capability Discovery

After initialization, clients should check what capabilities the server declared before attempting to use features. Servers also send notifications when their capabilities change.

# After session.initialize(), check server capabilities
caps = session.server_capabilities

if caps.tools:
    tools = await session.list_tools()

if caps.resources:
    resources = await session.list_resources()

if caps.prompts:
    prompts = await session.list_prompts()

Sampling

Sampling lets servers request LLM completions through the client, using sampling/createMessage. This keeps servers model-agnostic — the server asks the client to generate text, and the client decides which model to use.

  Server                    Client                   LLM
    |                         |                        |
    |  sampling/createMessage |                        |
    | ----------------------> |                        |
    |                         |   (user approval)      |
    |                         | ---------------------->|
    |                         |   completion result     |
    |                         | <----------------------|
    |   CreateMessageResult   |                        |
    | <---------------------- |                        |

# Server-side: ask the client to generate text
result = await ctx.session.create_message(
    messages=[
        {
            "role": "user",
            "content": {
                "type": "text",
                "text": "Summarize: " + document_text
            }
        }
    ],
    max_tokens=500
)

The Decision Landscape

There are several approaches for connecting AI models to external capabilities. Each has distinct trade-offs in portability, complexity, and control. Understanding when to reach for each approach is key to building robust AI integrations.

MCP vs Direct Function Calling

Direct function calling (as provided by OpenAI, Anthropic, and other APIs) defines tool schemas alongside API requests. MCP separates tool hosting into independent server processes. The choice depends on whether you need portability or simplicity.

When to use MCP: You want the same tool available in Claude Desktop, VS Code, and custom applications. You need dynamic discovery or server-managed state.

When to use direct function calling: Simple, single-app integrations where the overhead of a separate server process is not justified. You are building for one API provider and do not need portability.

MCP vs Skills & Plugins

Skills and plugins (like Claude Code skills or ChatGPT plugins) are host-specific extensions that add capabilities to a single application. MCP servers are universal -- they work with any host that speaks the protocol.

MCP vs REST APIs

MCP wraps APIs with AI-friendly metadata -- rich schemas, semantic descriptions, and tool annotations. Raw REST APIs require the host to understand each API's conventions, authentication patterns, and response formats independently.

Decision Flowchart

Use this guide when choosing how to connect your AI application to external capabilities.

  Need tool reusable across multiple AI apps?
    → YES → MCP Server
    → NO  ↓

  Building for a single AI app only?
    → YES → Direct Function Calling
    → NO  ↓

  Customizing AI behavior or persona?
    → YES → Skills / Plugins
    → NO  ↓

  Wrapping an existing API for AI consumption?
    → YES → MCP Server around the API
    → NO  ↓

  Simple one-off integration?
    → YES → Direct API Call

Popular MCP Servers

The MCP ecosystem includes a growing collection of production-ready servers for common integrations. These are some of the most widely used.

Server Registries

Finding and sharing MCP servers is supported by several registries and directories.

Debugging & Inspector

The MCP Inspector is the primary debugging tool for server development. It connects to any MCP server and lets you interactively test tools, resources, and prompts.

npx @modelcontextprotocol/inspector

The Inspector provides a web UI where you can connect to servers via stdio or HTTP, browse capabilities, invoke tools with test arguments, and inspect the raw JSON-RPC messages.

Debug checklist:

# 1. Verify config path is correct
cat ~/Library/Application\ Support/Claude/claude_desktop_config.json

# 2. Check server starts independently
python -m your_server          # Should start without errors

# 3. Test with Inspector
npx @modelcontextprotocol/inspector

# 4. Check capabilities negotiation
# Inspector shows the initialize handshake — verify tools/resources/prompts are listed

# 5. Check server stderr for errors (stdio transport)
# Server stderr is not captured by the protocol — use it for debug logging

Security Best Practices

MCP servers expose capabilities to AI models. Security requires defense in depth -- validate inputs, limit permissions, and audit all tool invocations.

Real-World Patterns

Production MCP deployments often combine multiple servers and add operational layers around the protocol.

JSON-RPC Error Codes & Retry Strategy

When protocol errors occur, the error code tells you whether retrying is safe.

Middleware Pipeline

Production HTTP servers benefit from a middleware stack around MCP tool handlers. Process requests through layers before they reach your tool logic.

Request flow:

┌─────────────────────────────────────────┐
│  1. Authentication                      │
│  Verify OAuth token / API key           │
│  ┌─────────────────────────────────────┐│
│  │  2. Rate Limiting                   ││
│  │  Per-session + per-tool limits      ││
│  │  ┌─────────────────────────────────┐││
│  │  │  3. Audit Logging               │││
│  │  │  Log tool name, args, caller    │││
│  │  │  ┌─────────────────────────────┐│││
│  │  │  │  4. Circuit Breaker         ││││
│  │  │  │  Skip if backend is down    ││││
│  │  │  │  ┌─────────────────────────┐││││
│  │  │  │  │  Tool Handler          │││││
│  │  │  │  └─────────────────────────┘││││
│  │  │  └─────────────────────────────┘│││
│  │  └─────────────────────────────────┘││
│  └─────────────────────────────────────┘│
└─────────────────────────────────────────┘