Part 3: Model Context Protocol

00

What is MCP?

MCP (Model Context Protocol) is a standardized protocol for connecting AI models to external tools, data sources, and services. Rather than every agent system inventing its own integration layer, MCP defines a unified interface that any server can implement and any client can consume.

The real power of MCP emerges when multiple servers work together, combining their specialized capabilities through that unified interface.

The Core Idea

Think of MCP like USB-C. Before it, every device had its own port and every cable only worked with certain devices. MCP is the USB-C of AI tools: one standard connector, endless compatible devices.

01

Core Server Building Blocks

Every MCP server exposes functionality through three primitives: Tools, Resources, and Prompts. They differ in who controls them and what they are for.

Primitive	What it is	Examples	Controlled by
Tools	Functions the LLM can actively call and decides when to invoke based on context	Search flights, send messages, create calendar events	Model
Resources	Read-only data sources that provide passive context to the model	Company policies, Calendar, API reference	Application
Prompts	Pre-built instruction templates for working with specific tools and resources	"Review my open PRs", "Summarize my tasks for today"	User

⚡

Tools

Model

Tools are schema-defined interfaces using JSON Schema for validation. Each tool performs a single, well-scoped operation with clearly defined inputs and outputs. Tools may require user consent before execution, ensuring users stay in control of actions taken on their behalf.

📄

Resources

Application

Resources provide structured, read-only access to information: things like file contents, database schemas, or API documentation, that the application retrieves and injects into the model's context.

💬

Prompts

User

Prompts are reusable, parameterized templates. They allow MCP server authors to define domain-specific workflows and surface the best patterns for using their server.

02

How Multiple MCP Servers Work Together

The real power of MCP is not a single server in isolation. It is the ability to combine multiple specialized servers through one unified client, letting the model draw on different capabilities as naturally as calling local functions.

flowchart TD
    U([User]) -->|invokes prompt with params| MC[MCP Client / AI App]

    MC --> PS["Prompt: plan-vacation"]
    PS --> MC

    MC -->|reads resources| R1["calendar://my-calendar/June-2024\nCalendar Server"]
    MC -->|reads resources| R2["travel://preferences/europe\nTravel Server"]
    MC -->|reads resources| R3["travel://past-trips/Spain-2023\nTravel Server"]

    R1 & R2 & R3 -->|context injected| LLM[LLM]

    LLM -->|calls tool| T1["searchFlights\nTravel Server"]
    LLM --> T2["checkWeather\nWeather Server"]
    T1 -->|results| LLM
    T2 --> LLM

    LLM -->|user approves| T3["bookHotel\nTravel Server"]
    LLM -->|user approves| T4["createCalendarEvent\nCalendar Server"]
    LLM -->|user approves| T5["sendEmail\nCalendar Server"]

    T3 & T4 & T5 --> R([Trip booked and confirmed])

Notice the two distinct phases. First, the model passively reads resources to build up context: no side effects, no approval needed. Then it actively calls tools to change the world, with user approval gating the consequential actions.

03

Worked Example: Multi-Server Travel Planner

Consider a personalized AI travel planner connected to three MCP servers: a Travel Server (flights, hotels, itineraries), a Weather Server (climate data and forecasts), and a Calendar/Email Server (schedules and communications).

Step 1

User invokes a prompt with parameters

JSON

{
  "prompt": "plan-vacation",
  "arguments": {
    "destination": "Barcelona",
    "departure_date": "2024-06-15",
    "return_date": "2024-06-22",
    "budget": 3000,
    "travelers": 2
  }
}

Step 2

User selects resources to include as context

calendar://my-calendar/June-2024 Calendar Server surfaces available dates
travel://preferences/europe Travel Server surfaces preferred airlines and hotel types
travel://past-trips/Spain-2023 Travel Server surfaces previously enjoyed locations

Step 3

The AI reads all resources to build context

Before taking any action, the model reads the selected resources to understand constraints and preferences. This is the passive, read-only phase: no side effects yet.

Step 4

The AI executes tools (with approval where required)

Using the gathered context, the model then invokes a sequence of tools:

searchFlights() queries airlines for NYC to Barcelona flights
checkWeather() retrieves climate forecasts for the travel dates
bookHotel() finds hotels within the specified budget User approval required
createCalendarEvent() adds the trip to the user's calendar User approval required
sendEmail() sends a confirmation with full trip details User approval required

Key Design Insight

The separation between reading (Resources, no approval needed) and writing (Tools, may require consent) gives users meaningful control over what the agent actually does in the world. The model can gather all the context it needs freely, but cannot take consequential action without explicit authorization.

✓

A task that could have taken hours (cross-referencing calendars, comparing flights, checking weather, booking hotels, and sending confirmation emails) is completed in minutes by combining Resources and Tools across three specialized MCP servers through a single unified interface.