Chapter 3: Actions with Model Context Protocol for AI agents

Introduction

The introduction presents MCP as a standard way to connect agents with tools and describes how agent workflows can themselves be offered as reusable tools.

• Standard protocol for agent tools: Explain why MCP is compared to USB-C for agents and LLMs: it provides a standard protocol for agent tools and broadens the tools available to agent workflows.
  Why it matters: This is the reason the chapter treats MCP as a connector for agents.
• Reusable agent workflows as tools: Describe how an agent can be made available as a consumable MCP server so another agent workflow can use its complex workflow as a reusable tool.
  Why it matters: MCP can connect not only agents to tools, but also one agent workflow to another.

Key terms: Model Context Protocol (MCP), standard protocol, agent tools, consumable MCP servers, agentic workflows, tools, reused like components

3.1 Understanding MCP fundamentals for agent development

Introduces MCP as an open standard for connecting AI systems to external services.

• MCP standard and purpose: Describe MCP as an open standard created by Anthropic, based on JSON-RPC 2.0, that lets AI systems connect to external services consistently, securely, and efficiently.
  Why it matters: This gives you the basic purpose of MCP before the book explains its components and use with agents.

Key terms: MCP, open standard, JSON-RPC 2.0, external services

3.1.1 The standardization problem MCP solves

This section explains why fragmented integrations made agents brittle and how MCP addresses that problem by standardizing interactions with external systems.

• Provider-Specific Tool Integration: Explain why a tool built for one LLM provider could require substantial changes for another, and how supporting multiple providers multiplied development and maintenance work.
  Why it matters: This duplication is a concrete reason developers needed a shared integration standard.
• Other Integration Barriers: Describe the problems posed by source-specific data connections, custom agent-to-agent integration, and inconsistent security and monitoring.
  Why it matters: The standardization problem extended beyond tool definitions to data, collaboration, and control.
• MCP Unified Protocol: Explain how MCP addresses the described fragmentation and why that changes the way agents can be developed.
  Why it matters: This is the central reason the chapter introduces MCP for agent development.

Key terms: fragmented tool integration, JSON schema, tool-call envelope, inconsistent data access, complex agent orchestration, access controls, monitoring, MCP, unified protocol, standardized components

3.1.2 MCP architecture: Clients, servers, and services

This section explains how MCP standardizes an agent’s connection to external services and identifies the client, server, and service roles in that connection.

• Standardized service integration: Explain why MCP reduces the custom integration work needed to connect an agent to multiple services, while identifying concerns it does not remove.
  Why it matters: This explains both the practical benefit of MCP and the limits of what standardization solves.
• Client server service roles: Describe the three-component view of an MCP connection and how requests and responses pass between the client and server.
  Why it matters: These roles clarify what an agent connects to and where the external capability resides.
• Server capability primitives: Distinguish the three capabilities an MCP server can expose and explain how the section uses the word service.
  Why it matters: This distinction prevents confusing what a server exposes with the external system it connects to.

Key terms: MCP, MCP server, service, per-provider schema and call-format work, MCP client, JSON-RPC 2.0, discovery, tools, resources, prompts

3.1.3 Core components: Tools, resources, and prompts

This section distinguishes MCP tools, resources, and prompts by their purposes and who typically chooses when to use them, then explains why some clients expose only tools.

• MCP component purposes: Distinguish tools, resources, and prompts by what each provides to an agent or LLM, and describe how a server makes its components discoverable.
  Why it matters: These distinctions clarify what an agent can do with an MCP server versus what it can consume from one.
• Control over component use: Explain who typically decides when tools, resources, and prompts are used in an MCP conversation.
  Why it matters: Who initiates their use explains why MCP keeps these capabilities as separate categories.
• Tool only client workarounds: Explain why prompt-style or resource-style functionality may be wrapped in tools, and why the section treats that as a workaround.
  Why it matters: It explains why a tool-focused example need not imply that MCP's three primitives are interchangeable.

Key terms: tools, resources, prompts, discoverable endpoints, list_tools, model-controlled, user-controlled, application-controlled, MCP client, OpenAI Agents SDK

3.1.4 MCP deployment patterns for agents

This section compares local and remote MCP server deployments and explains that a hybrid setup means an agent uses a mix of servers, not that an individual server is hybrid.

• Local and remote deployments: Distinguish local MCP servers that communicate with an agent through STDIO from remote servers that can communicate over HTTP using SSE. Explain why local deployment suits single-machine development and remote deployment supports shared, distributed services.
  Why it matters: The connection pattern helps determine whether a server is best suited to local development or to services shared across agents.
• Meaning of hybrid deployment: Explain that a hybrid setup connects an agent to separate local and remote MCP servers at the same time, rather than making any single server both local and remote.
  Why it matters: This distinction prevents a mixed agent setup from being mistaken for a third deployment mode for an individual server.

Key terms: local deployment, STDIO transport, remote deployment, SSE transport, hybrid deployments, local servers, remote servers, protocol level

3.1.5 MCP powers the functional agent layers

This section shows that MCP can connect agents to capabilities across multiple functional layers, not only to tools for taking actions.

• MCP Across Agent Layers: Explain why MCP should be understood as a connection pattern for multiple agent functions rather than only as a way to add action tools.
  Why it matters: This broader view helps you recognize uses for MCP beyond connecting an agent to apps it acts on.
• Layer Specific MCP Capabilities: Describe the kinds of capabilities MCP servers provide to the four agent layers illustrated here, with examples of what the agent can do through them.
  Why it matters: Matching a server's capability to the agent function it supports makes the section's broader claim concrete.

Key terms: MCP, functional agent layers, connection pattern, tools and actions, reasoning and planning, knowledge and memory, evaluation and feedback, sequential thinking server

3.2 Getting started with MCP servers

Introduces Claude Desktop as a way to connect to MCP servers and explains why the same basic pattern applies across MCP clients.

• Claude Desktop server connections: Describe how Claude Desktop can consume MCP servers and what becomes available to its underlying LLM after a connection is configured.
  Why it matters: This is the basic connection pattern behind using MCP capabilities from an LLM client.
• MCP patterns across clients: Explain why MCP patterns learned with Claude Desktop transfer to other clients and what can differ between clients.
  Why it matters: Using Claude Desktop for the example does not make the underlying MCP pattern Claude-specific.
• Claude Desktop teaching choice: Justify the section's use of Claude Desktop as the initial MCP teaching environment.
  Why it matters: It explains why the examples start with Claude Desktop without implying MCP is limited to it.

Key terms: Claude Desktop, MCP servers, tools, prompts, resources, MCP, clients, configuration surface, capability primitives, configuration file

3.2.1 Coding up an MCP server for Claude

This section shows how to expose an existing Python tool through an MCP server and try it in Claude Desktop.

• MCP tool schema registration: Explain how @mcp.tool() exposes the existing get_research_sources function as an MCP tool and how its signature, docstring, and return type inform the agent.
  Why it matters: The function’s description helps the agent choose the right tool, not just a human understand the code.
• Claude Desktop server setup: Describe how the section installs the Python MCP server for Claude Desktop, checks that it is running, and tries its tool.
  Why it matters: Checking the server before invoking the tool separates setup problems from tool behavior.
• Tool execution permission: Explain why Claude Desktop asks for permission before executing the tool and what caution the section draws for agent development.
  Why it matters: A Desktop approval prompt should not be assumed to protect every agent that uses the same tool.
• Tool result and LLM response: Distinguish the tool’s configured list of research sources from the additional information the LLM may put in its response.
  Why it matters: The displayed answer may include the model’s additions, not just the tool’s configured content.

Key terms: @mcp.tool(), tool schema, signature, docstring, return type annotations, MCP CLI tools, Claude Desktop, Developer, get_research_sources, permission

3.2.2 Using the MCP inspector

This section shows how to inspect and debug an MCP server, then clarifies why the example server uses STDIO transport.

• MCP inspector diagnostics: Explain how the MCP inspector helps diagnose a server whose tools are not working as expected, including checking the schema the agent sees, calling tools directly, and examining errors or traffic.
  Why it matters: The inspector lets you test what an agent actually encounters before guessing why tool use failed.
• Inspector launch and interface: Describe the path requirement when running the inspector command and what the illustrated Tools page shows after connecting to the research server.
  Why it matters: Using the right path gets the server running, while the interface lets you verify a tool call and its result.
• Transport versus package runner: Distinguish why the illustrated local server uses STDIO from the role of uv, and explain what determines whether the server uses STDIO, HTTP, or SSE.
  Why it matters: Separating the process runner from transport prevents you from attributing the server’s communication method to uv.

Key terms: MCP inspector, tool list, decorator-generated schema, JSON-RPC traffic, initialization errors, absolute path, Tools page, Run Tool, get_research_sources, history of operations

3.2.3 Understanding MCP transport types

The section identifies MCP’s two transport types and explains why the distinction matters when building or consuming MCP clients and servers.

• MCP transport types: State that MCP supports STDIO and SSE as communication transport types, and explain that the distinction matters when consuming or building MCP clients or servers.
  Why it matters: Recognizing the two transport options prepares you to consider how an MCP client connects to a server.

Key terms: MCP, STDIO, SSE, transport types

3.2.4 From desktop to agents: The key differences

This section distinguishes an MCP-using assistant from an agent by the agent’s autonomous, multi-step loop, then explains the risks that autonomy creates and the safeguards it calls for.

• Assistant and agent autonomy: Distinguish an assistant’s single-request tool use from an agent’s ability to call tools, observe results, and continue toward a goal across multiple steps. Explain why asking permission does not, by itself, make a system an assistant rather than an agent.
  Why it matters: This distinction helps you recognize agency even when a system asks for approval before acting.
• Compounding risks of agent tools: Explain why a mistaken tool call is more consequential for an agent than for a single-step assistant, and describe examples of harm from the tools or tool outputs an agent can access.
  Why it matters: Tool access can let one error or malicious input affect many subsequent agent actions.
• Defense-in-depth for agent tools: Describe the safeguards the section recommends pairing with MCP in production agent systems and explain what kinds of risk they limit.
  Why it matters: Layered safeguards reduce the damage an autonomous agent can do before a person notices.

Key terms: assistant, agent, autonomy, loop, permission prompts, tool selection, destructive actions, data exfiltration, cost runaways, prompt injection through tool outputs

3.3 Using MCP servers for agents

This section defines agent actions, outlines ways agents connect to MCP servers, and explains when MCP is worth its overhead.

• Scope of agent actions: Explain that an agent action is any act that helps complete a goal, and that MCP servers can provide more than tool calls.
  Why it matters: This broader meaning of action helps you recognize what an MCP server can provide to an agent.
• MCP server connection patterns: Describe the three server locations and connections presented: a local subprocess over STDIO, a separate process on the same machine or container over SSE and HTTP, and a remote server over SSE and HTTP.
  Why it matters: Server location and connection type distinguish the ways an agent can consume MCP capabilities.
• MCP versus in-process calls: Justify when to use MCP rather than an in-process function call by weighing separation and sharing against added latency, failure modes, and operational work.
  Why it matters: This rule of thumb helps you avoid adding infrastructure where a simple function call would work better.

Key terms: MCP servers, agent actions, tool, resource, MCP server, STDIO, SSE over HTTP, subprocess, separation of concerns, in-process function calls

3.3.1 Using agents with local MCP servers over STDIO

This section explains how an agent can run a local MCP server over STDIO and why MCP lets agents and servers written in different languages work together.

• Local STDIO server lifecycle: Describe how an agent launches a local MCP server as a command-line subprocess over STDIO, making its tool available while the hosting block runs and shutting the server down when the block exits.
  Why it matters: This pattern keeps a local tool’s availability and server lifecycle under the agent service’s control.
• Cross-language MCP interoperability: Explain why a Python agent can consume an MCP server implemented in another language without a language-specific bridge.
  Why it matters: MCP can serve as a portable integration layer instead of tying an agent to one framework or language.

Key terms: STDIO, MCP server, subprocess, get_research_sources, language agnostic, MCP protocol, portable integration layer

3.3.2 Using local MCP servers over SSE with agents

This section explains why an agent might connect to a separately running MCP server over SSE and what changes from an in-process STDIO connection.

• SSE Server Connection Rationale: Explain why an MCP server might be run externally as an HTTP server using SSE instead of being hosted locally in process.
  Why it matters: It explains when a separately running SSE server is useful rather than merely naming another transport.
• Agent Connection Switch: Describe the change needed in the agent example to connect to the SSE server rather than launch the MCP server with a command.
  Why it matters: It identifies the practical difference between launching a local server and connecting to one that is already running.

Key terms: MCP server, HTTP server, SSE, STDIO, FastMCP, URL, command, server implementation

3.3.3 Connecting to the standard MCP servers

This section shows how to use a standard MCP Filesystem server and why its file access must be handled carefully.

• Standard server connection: Explain how a shared MCP server can supply tools without building a server, and describe how the example runs the Filesystem server locally.
  Why it matters: A standard server can add useful tools to an agent without requiring you to implement those tools yourself.
• Filesystem access and safeguards: Describe what access the Filesystem server grants the agent and justify isolating its folder and verifying any MCP server's capabilities.
  Why it matters: The folder and tools you expose determine what an agent can do on your behalf, including actions you might not intend.

Key terms: shared servers, MCPServerStdio, MCP Filesystem server, npx, isolate the folder, validate and verify, MCP tools

3.4 Building MCP servers for agents

The section uses a time-tracker agent to show how journal tools preserve information across fresh invocations, while noting the limits of its in-memory implementation.

• Time-Tracker Journal Workflow: Trace how the example agent records time-travel events and later produces a journal summary using its internal tools.
  Why it matters: The example makes the purpose of the two journal tools concrete before they are moved into an MCP server.
• Scratchpad Memory Purpose: Explain why the example agent needs a journal across loop cycles and how such storage helps when reviewing information.
  Why it matters: The journal explains how separate agent invocations can work with earlier events without keeping all of them in the current context.
• In-Memory Journal Scope: Distinguish why the example’s module-level in-memory journal suits its single-agent process but changes meaning when multiple agents connect to one MCP server.
  Why it matters: Moving the same journal code into a shared server changes who can access its contents.

Key terms: record_event, load_journal, journal, temporary or scratchpad memory, fresh invocation, context overload, module-level in-memory list, shared state, single process

3.4.1 Converting tools to an MCP server

The section moves the time-travel tracker’s journal tools into an MCP server and explains how the resulting interface separates the agent from tool implementations.

• Standalone MCP Tool Server: Describe how the existing journal tools are moved into a separate MCP server file while the agent remains in its own file, and how the MCP decorator exposes the tools through MCP.
  Why it matters: This is the concrete change that turns the existing journal tools into tools the agent can consume through MCP.
• Tool Interface and Separation: Explain how the rewrite replaces direct access between the agent and journal tools with an MCP interface, and why that makes tool implementations replaceable and reusable.
  Why it matters: The benefit is not just moving code: the agent can keep using the same tool interface even when its backing implementation changes.

Key terms: MCP server, MCP decorator, tool discovery, separation of concerns, interface contract, tool schema, implementation

3.4.2 Consuming MCP servers locally or remotely

This section shows how an agent consumes journaling tools from an MCP server over STDIO or SSE, and explains the practical difference between the two connections.

• MCP server connection options: Describe how the agent consumes the journaling-tool server locally over STDIO or through an SSE (HTTP) connection, and how the server is made available to the agent in each case.
  Why it matters: The connection choice changes how you start the server, even though the agent uses the tools in much the same way.
• Shared SSE journal state: Explain why SSE and STDIO can produce similar results but the SSE example may show duplicate journal entries when multiple agents connect.
  Why it matters: Shared server state explains a surprising result you might see when testing the SSE example.
• Tools encapsulated in servers: Explain the benefits the section attributes to wrapping sets of tools in MCP servers.
  Why it matters: Thinking of tools as server-hosted sets makes their reuse across applications easier to understand.

Key terms: MCP server, STDIO, SSE, with clause, journaling tools, in-memory journal, duplicate journal results, MCP servers, encapsulating tools, code reuse

3.5 Exercises

Five exercises practice inspecting an MCP server, connecting agents over STDIO and SSE, restricting exposed tools, and making an agent available as an MCP tool.

3.6 Summary

Summarizes how MCP standardizes agent capabilities, supports different connection and deployment patterns, and enables composable agent systems.