3 Actions with Model Context Protocol for AI agents
The chapter introduces the Model Context Protocol as a standardized way for AI agents and LLM applications to connect to external tools, data sources, and even other agent workflows. It frames MCP as a kind of universal connector that reduces the friction of custom integrations, improves consistency, and makes agent systems easier to assemble, extend, and secure. By separating tool access from agent logic, MCP helps developers focus on building capabilities rather than reworking connectors for each model or platform.
It then explains the basic MCP ecosystem: clients discover and use capabilities exposed by servers, while servers mediate access to tools, resources, and prompts through JSON-RPC 2.0. The chapter contrasts local STDIO-based deployment, where a server runs as a subprocess with low latency and tight coupling to one client, with remote SSE-based deployment, where servers are network-addressable and can support shared access and distributed architectures. It also shows how MCP can support more than action tools alone, extending across reasoning, memory, and feedback layers in agent design.
Finally, the chapter demonstrates how to use MCP in practice by connecting Claude Desktop and OpenAI Agents SDK workflows to MCP servers, inspecting servers with the MCP inspector, and building simple servers that expose tools such as research sources or filesystem access. It shows how an existing agent with internal functions can be refactored into a reusable MCP server, then consumed locally or remotely with only minor code changes. Throughout, the chapter emphasizes control, validation, and safety, reminding developers that powerful tools require careful understanding because agents may act more broadly than intended if given unrestricted access.
The leading challenges AI Agent developers face when building agents include fragmented tool integration, inconsistant data access, complicated multiple-agent orchestration, and security and control.
A typical problem agent/LLM developers face when connecting to multiple services and resources is the lack of standardized connections and the need to support multiple different connectors to whatever services they need access to.
Implementing MCP as a service layer abstracts access to the various services that agent may want to connect to and use.
The basic components of MCP architecture are the client, server, and services. Here you can see some common clients (agents, LLM applications, Claude desktop, and VS code) and potential services (file operations, database queries, web APIs, and other agents) that the clients might connect to.
The main components of an MCP server include prompts, specialized system instructions; resources (used for access to files), configuration, and databases; and Tools, which are extensions of an internals agent’s ability to consume and use tools
The various deployment patterns that may be used to connect MCP servers to agents. From running locally and within a child process on the same machine, running remotely and accessible over HTTP to include hybrid architectures that blend local and remote MCP servers to single agent.
MCP can be used to add functionality in the form of tools to all the functional agent layers.
Claude desktop may consume multiple MCP servers deployed locally or remotely. The LLM that powers Claude then uses the MCP components (generally tools) to enhance its capabilities.
Shows the MCP server settings for Python file
Shows the MCP hosted tool being executed within Claude desktop
Shows the MCP Inspector interface examing available tools and executing them
The key differences between MCP tool execution from an LLM application (Claude Desktop) or through using an agent include; assistants require human supervision while agents are autonomous, assistants are interactive to agents programmatic, agents perform more complex multi-step workflows and assistants typically are limited to performing simple plans.
Shows the various ways an agent may interact with and consume MCP servers
The time tracker agent will record time events using internal function tools as it processes the events in a loop. After the loop finishes the agent is asked to summarize the events and it will use the Load Journal Evants tool to load the journal of events and summarize
The separation of tools from the agent into a standalone MCP server that could be hosted locally or remotely and access through STDIO (local) or SSE (remote). Now the agent registers the MCP server instead of individual tools and then internally discovers the tools the server supports and how to use those tools.
Summary
- MCP = “USB-C for LLMs & agents.” A JSON-RPC-2.0 spec that erases bespoke glue code for tools, data sources, and even other agents.
- MCP solves fragmentation (multiple tool schemas), brittle data access, ad-hoc orchestration, and uneven security by giving every capability a uniform interface.
- MCP supports three components: Tools (actions), Resources (data/objects), and Prompts (re-usable templates). Agents can treat any of them as callable verbs.
- MCP Architecture is in 3 parts: MCP Client, Server, and the Service/Resource it fronts. An agent is just one kind of client.
- STDIO – sub-process, zero-latency, single caller (great for local development).
- SSE – HTTP + Server-Sent Events, multi-client, cloud-friendly. Switching is literally a constructor swap.
- MCP is not just for tools/actions but can support the other functional layers (Reasoning & Planning, Knowledge & Memory, Evaluation & Feedback)
- MCP can be deployed using a mixture of patterns: Local, remote, or hybrid — mix and match to keep sensitive operations local while sharing heavy APIs remotely.
- The MCP Inspector gives a live, clickable view of any server—perfect for debugging tool schemas and outputs before wiring agents to them.
- MCP reference servers are available for use or inspection and include: filesystem, brave-search, google-calendar, github, etc.—all installable with a single npx or mcp run.
- Agents themselves can be wrapped as servers, turning an entire reasoning pipeline into a reusable, strongly typed tool.
- Typed Pydantic I/O flows end-to-end, eliminating fragile string parsing in multi-agent chains.
- MCP enables LEGO-style composition of agent systems—each block isolated, testable, and instantly swappable without touching the others.
AI Agents in Action, Second Edition ebook for free