MCP — Tools for Agents

An agent that can only produce text is just a chatbot. The Model Context Protocol is the open standard that gives agents hands — letting an assistant like GitHub Copilot, Anthropic’s Claude, or a Cursor session query your database, hit your APIs, read your files, and act on the outside world.

The problem MCP solves

☺ Like you’re 10: Imagine every gadget in your house needed its own weird plug shape. MCP is like agreeing everyone will use the same plug, so any helper can connect to any tool without a special cable each time.

Before MCP, every AI application needed custom code for every tool it wanted to use. With M apps and N tools, the industry faced M × N bespoke integrations to build and maintain — each inventing its own authentication, sandboxing, and data-handling, all inconsistent and error-prone. Worse, models couldn’t reliably discover what tools were available or how to call them without hand-rolled prompt engineering.

MCP — released by Anthropic in late 2024 and now natively supported across the major AI platforms — turns that M × N problem into M + N. Build a tool server once, and any MCP-compatible host can use it; build a host once, and it can use any server. The common analogy: MCP is the USB-C port for AI — one standard connector instead of a drawer full of adapters.

The architecture: three roles

☺ Like you’re 10: Think of ordering food at a restaurant: you (the host) tell a waiter (the client), and the waiter walks to exactly one kitchen (the server) to get what you asked for. You never shout into the kitchen yourself — the waiter always carries the message.

MCP is a client–server protocol with three distinct roles. Getting these straight is the whole game:

• Host — the LLM application the user actually interacts with (Copilot, Claude Desktop, Cursor, Zed, Claude Code). It manages the model and creates one or more client sessions.
• Client — a connector that lives inside the host and is responsible for exactly one server (a 1:1 relationship). It maintains a stateful JSON-RPC channel, handles capability discovery, and invokes the server’s primitives.
• Server — an independent, lightweight process that exposes one domain’s capabilities (a filesystem, a database, a set of APIs). Each server is focused and modular, and enforces its own security constraints so clients only reach authorized operations.

The protocol & the lifecycle

☺ Like you’re 10: When two friends start a walkie-talkie chat, they first say hello and check which channels they both have. MCP does the same handshake so the helper and the tool agree on what each can do before they start working.

Under the hood, MCP is JSON-RPC 2.0 over a duplex transport, with stateful sessions and capability negotiation. Every message is a UTF-8 JSON-RPC request, notification, or response. That’s the whole thing — the rest is detail.

A connection follows a simple handshake:

The initialize step negotiates which features each side supports, so a host always knows exactly what a server offers. Discovery is standardized: a host finds a server’s tools via tools/list and reads data via resources/read — no bespoke prompt engineering required. The spec is date-string versioned (e.g. 2025-11-25) and negotiated during initialize.

Server-side primitives: Tools, Resources, Prompts

☺ Like you’re 10: A server offers three kinds of things, like a toy box: buttons that actually do something (tools), a picture book you can only look at (resources), and a recipe card that tells you the steps (prompts).

An MCP server exposes capabilities through exactly three primitives. This lean taxonomy covers the vast majority of real use cases:

Client-side primitives: Sampling, Roots, Elicitation

☺ Like you’re 10: The tool can talk back too. It can borrow the helper’s brain to think (sampling), it must stay inside the fenced yard it’s allowed in (roots), and it can stop to ask you a question first, like “Are you sure?” (elicitation).

MCP is bidirectional — the client offers three primitives back to the server, which is what enables richer, human-in-the-loop workflows:

• Sampling — a server can ask the client to run an LLM completion on its behalf. This lets a server use the host’s model (for summarizing, classifying, etc.) without shipping its own API keys.
• Roots — the client tells the server which filesystem roots or boundaries it is allowed to operate within. A safety boundary the server must respect.
• Elicitation — a server can request input from the user, through the client, mid-operation. This is the human-in-the-loop hook: “I need you to confirm before I delete these records.”

Together with dynamic updates (servers can notify the host when their capabilities change), these primitives make MCP a protocol for building modular, interactive, secure workflows — not just a static plugin format.

Transports: stdio vs. Streamable HTTP

☺ Like you’re 10: There are two ways to reach a tool: talking to a friend sitting right next to you (stdio, for tools on your own computer) or phoning a friend far away (Streamable HTTP, for tools online). Near ones are simple; far ones need a password to make sure it’s really you.

The spec defines two standard transport mechanisms (custom transports are allowed). Which one you use depends on whether the server runs locally or remotely:

The practical migration path: start local with stdio while developing, then go remote with Streamable HTTP + OAuth 2.1 when you’re ready for production and multiple users.

Building an MCP server

☺ Like you’re 10: Making your own tool is like snapping together LEGO bricks with labels on them. You write a short piece of code, put a clear label on each button so the helper knows what it does, and now anyone’s AI can press it.

Official SDKs exist for many languages — TypeScript, Python, Go, Kotlin, Java, C#, Swift, Rust, Ruby, PHP. The most popular Python framework is FastMCP, which makes a server a few decorators. Here’s a server exposing all three primitives:

from fastmcp import FastMCP

mcp = FastMCP("orders-service")

# 1 · A TOOL — an action with side effects. The model can call this.
@mcp.tool()
def create_ticket(order_id: str, issue: str) -> str:
    """Open a support ticket for an order. Use when a customer reports a problem."""
    ticket_id = db.insert_ticket(order_id, issue)   # real side effect
    return f"Created ticket {ticket_id}"

# 2 · A RESOURCE — read-only data the model can pull in as context.
@mcp.resource("order://{order_id}")
def order_details(order_id: str) -> dict:
    """Return status, ETA, and items for an order."""
    return db.get_order(order_id)                   # read-only

# 3 · A PROMPT — a reusable template that standardizes a task.
@mcp.prompt()
def triage(order_id: str) -> str:
    return f"Investigate order {order_id}. Check status, then summarize next steps."

if __name__ == "__main__":
    mcp.run()              # stdio by default; switch to HTTP for remote

The same in TypeScript, registering a single tool with a typed schema:

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

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

server.tool(
  "create_ticket",
  { orderId: z.string(), issue: z.string() },     // JSON-schema params
  async ({ orderId, issue }) => {
    const id = await db.insertTicket(orderId, issue);
    return { content: [{ type: "text", text: `Created ticket ${id}` }] };
  }
);

// transport wired separately: stdio locally, Streamable HTTP for remote

Notice the tool’s description and schema do the work: the model receives a structured list of available tools with descriptions, and when it decides it needs one, it emits a tool-call request with the right arguments — the client executes it through the server and returns the result. Write tool descriptions the way you’d write a SKILL.md description: they are the trigger.

Connecting an MCP server to a host

☺ Like you’re 10: Once your tool is built, you just tell your AI helper its address, like adding a new contact to a phone. After that, the helper can call it whenever it needs — the same way no matter which helper you use.

Once a server exists, you declare it in configuration and its tools become available to your host — Copilot’s agent mode, CLI, cloud agent, and SDK, or the equivalent surfaces in Claude Code, Claude Desktop, Cursor, and others — wherever you’ve enabled it. The definition is the same everywhere; only the root key and the config file differ per client. Pick yours:

// .vscode/mcp.json  (workspace-level; or the "mcp.servers" block in settings.json)
{
  "servers": {
    "filesystem": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "${workspaceFolder}"]
    },
    "orders-service": {
      "type": "http",
      "url": "https://orders.internal.example.com/mcp"
    }
  }
}

// claude_desktop_config.json  (Settings → Developer → Edit Config)
{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/you/project"]
    },
    "orders-service": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://orders.internal.example.com/mcp"]
    }
  }
}

// .mcp.json in the project root (shared with your team via git)
// or one command:  claude mcp add filesystem npx -y @modelcontextprotocol/server-filesystem .
{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "."]
    },
    "orders-service": {
      "type": "http",
      "url": "https://orders.internal.example.com/mcp"
    }
  }
}

// .cursor/mcp.json (project) — or ~/.cursor/mcp.json for every project
{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "."]
    },
    "orders-service": {
      "url": "https://orders.internal.example.com/mcp"
    }
  }
}

The first is a local stdio server (the client spawns it as a subprocess). The second is a remote HTTP server. Vendors also ship built-in servers you can drop in: GitHub offers a hosted GitHub MCP server — its tools (like list_workflow_runs) are what the example skill in Customizing Copilot relied on — and Anthropic and others publish reference servers (filesystem, fetch, and more) you wire up the same way.

From code, agent SDKs take MCP server configs directly — the Copilot SDK and Anthropic’s Claude SDK both accept a map of servers. Conceptually (shape varies by SDK — verify against the current README):

const session = await client.createSession({
  model: "claude-sonnet-4-6",
  mcpServers: {
    filesystem: { type: "stdio", command: "npx",
      args: ["-y", "@modelcontextprotocol/server-filesystem", "."] },
    docs: { type: "http", url: "https://docs.example.com/mcp" },
  },
});

MCP and the agent loop

☺ Like you’re 10: An agent works like a treasure hunt: think about what you need, do one thing to get it, look at what you got, then think again. MCP is the “do a thing and look at the result” part that keeps the hunt moving.

Here’s why MCP is foundational to everything agentic. Recall the agent loop from Agentic AI — reason, act, observe, repeat. MCP is the “act” and “observe.” When an agent reasons that it needs information or an action, it calls an MCP tool (act); the server executes and returns a result (observe); the agent reasons again. MCP is the standard plumbing for that loop:

The security model (read this twice)

☺ Like you’re 10: Giving a helper tools is like handing someone the keys to your house — handy, but you only give the keys you must, you ask before letting them do big things, and you don’t trust notes from strangers that say “now go do this.”

Tools are the most powerful and most security-sensitive primitive — they take real actions in the world. MCP defines a security model, but you are responsible for using it well:

• Auth & transport security. Remote servers use OAuth 2.1 over TLS. Never expose a write-capable server without authentication.
• Consent flows & human-in-the-loop. Use the elicitation primitive and host approval prompts to gate consequential actions. Every serious host does this — Copilot, Claude Code, and Claude Desktop all ask you to confirm before running sensitive operations for exactly this reason.
• Least privilege. Give a server only the access it needs, and connect an agent only to the servers a task requires. A changelog agent should not be wired to a database-write server.
• Sandboxing & roots. Use the roots primitive to bound filesystem access; run risky servers in containers.
• Prompt injection through tools. An agent that reads external content via a resource can encounter malicious instructions hidden in that data, which then try to drive its tool calls. Treat anything a server returns as untrusted data, not commands — and be especially careful when an agent has both broad data access and powerful action tools at once.

Ecosystem & where it’s going

☺ Like you’re 10: Because everyone agreed on the same plug, tons of people are now building tools that all snap together, and there are plans to let AI helpers team up and even hand jobs to each other — like friends passing a ball on the same team.

The MCP ecosystem is growing fast: new servers, clients, and SDKs ship constantly, and adoption across all major AI platforms means MCP skills are broadly transferable. The donation to the Linux Foundation signals long-term governance stability. Looking ahead, the maturing pieces include stateless server operation, automatic discovery via server registries, and agent-to-agent (A2A) coordination — the subject of the next lesson, Agent Protocols, which positions MCP as the integration layer beneath the multi-agent systems you will meet later. The practical guidance for 2026: make MCP your default integration layer, and design security and governance in from day one.