Overview
3 Actions with Model Context Protocol for AI agents
This chapter introduces the Model Context Protocol (MCP) as the unifying connector that turns language models and agents into practical, tool-using systems. Framed as a remedy to fragmented tool integrations, ad‑hoc data access, brittle multi‑agent orchestration, and uneven security controls, MCP standardizes how capabilities are exposed and consumed so developers can assemble agent workflows from reusable components rather than handcrafting bespoke adapters. The result is a rapidly growing ecosystem in which almost anything an agent needs—data, applications, or even other agents—can be plugged in and reused across projects.
The chapter explains MCP’s architecture—clients, servers, and services—communicating over JSON-RPC 2.0, and the three discoverable server components agents use: tools (actionable operations), resources (external data and configuration), and prompts (interaction templates). It covers deployment patterns and transports, showing how servers can run locally via STDIO for low-latency, single-process work or remotely over HTTP using SSE to support shared, scalable access; hybrid setups are common. MCP is positioned not just as a tools layer but as infrastructure that can augment every agent layer—actions, reasoning and planning, knowledge and memory, and evaluation and feedback. Practical utilities such as Claude Desktop and the MCP Inspector demonstrate how to register servers, discover capabilities, and test calls end-to-end.
Hands-on sections show how to wrap existing functions as MCP tools, register servers from agent code using the OpenAI Agents SDK, and switch between STDIO and SSE with minimal changes. The text walks through building simple servers (for example, a research tool), consuming standard shared servers (like filesystem or third‑party service connectors), and converting in-process tools—such as a journaling “time tracker”—into reusable MCP services. Throughout, it emphasizes separation of concerns, modularity, and reuse, while underscoring key behavioral differences between assistants (human-in-the-loop approval) and autonomous agents (programmatic, multi-step tool use). The chapter closes with guidance on validation, safety, and access control so agents wield MCP-powered tools reliably and securely.
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.
FAQ
What is the Model Context Protocol (MCP) and why is it often called “USB‑C for agents”?
MCP is an open standard from Anthropic, built on JSON-RPC 2.0, that standardizes how AI agents and LLM apps connect to external tools, data sources, and services. It’s dubbed “USB‑C for agents” because, like a universal connector, one protocol lets clients plug into many servers without bespoke integrations. It solves four big problems: fragmented tool integrations across providers, inconsistent data access patterns, complex multi‑agent orchestration, and uneven security/control.How does MCP’s architecture of clients, servers, and services fit together?
- MCP client: an agent or LLM app that connects to MCP servers, discovers capabilities, and invokes them.- MCP server: exposes tools, resources, and prompts; processes requests and returns responses over JSON‑RPC 2.0.
- Service/resource: the underlying system the server wraps (files, databases, web APIs, or even other agents).
Clients connect to one or many servers and call standardized endpoints to discover and use what the server offers.
What are “tools,” “resources,” and “prompts” in an MCP server?
- Tools: actionable functions agents/LLMs invoke to perform tasks (most commonly used).- Resources: external data or artifacts to read/consume (files, configs, databases).
- Prompts: predefined templates/instructions that standardize complex interactions.
Servers expose discovery endpoints like list_tools so clients can enumerate and use these. If a client lacks native support for resources/prompts, tools can emulate them.
Which transport types does MCP support, and when should I use each (STDIO vs SSE)?
- STDIO: client launches the server as a subprocess and exchanges JSON‑RPC over stdin/stdout. Pros: low latency, no networking, simple 1‑to‑1 link. Best for local dev, quick CLI experiments, or tightly coupled single‑machine workflows.- SSE: server runs as an HTTP service; client sends requests via POST and receives streamed responses over text/event-stream. Pros: network-addressable, multi‑client, scales behind proxies/load balancers. Best for shared, remote, or cloud deployments and browser/front‑end integrations.
What deployment patterns can I use for MCP servers?
- Local (STDIO): run as a child process on the same machine—fast, simple, great for development and single‑host setups.- Remote (SSE over HTTP): run on another process/host; supports many clients, load balancing, and cloud‑native scaling.
- Hybrid: combine local servers for sensitive operations (e.g., file access) with remote servers for shared or internet‑facing services.
How do agents differ from desktop assistants (e.g., Claude Desktop) when using MCP?
Desktop assistants follow a supervised pattern—tool calls generally require human approval. Agents act autonomously: they select, sequence, and execute tools programmatically and can run multi‑step plans without manual confirmation. This power increases responsibility—validate tools and add evaluation/feedback to prevent unintended actions.How do I quickly try MCP with Claude Desktop and the MCP Inspector?
- Implement a small FastMCP server (e.g., with a get_research_sources tool).- Install/register it via the MCP CLI so Claude Desktop can discover it.
- In Claude, enable the server and approve tool runs when prompted.
- Use mcp dev to launch the MCP Inspector, browse tools/resources/prompts, and run/test methods interactively for debugging.
How can my agent consume MCP servers locally and remotely with the OpenAI Agents SDK?
- Local (STDIO): use MCPServerStdio to launch the server as a subprocess and pass it to the agent’s mcp_servers. The agent discovers and calls tools via JSON‑RPC over stdio.- Remote (SSE): run the MCP server as an HTTP service and use MCPServerSse with its /sse URL. Swapping STDIO↔SSE is typically a small code/config change.
What shared MCP servers are available out of the box, and what can I do with them?
Examples include: Filesystem (local file read/write within a path), Sequential Thinking (planning/decomposition), Google Drive/Calendar, Notion, Slack, Brave Search (web search), GitHub, Google Maps, and Fetch (retrieve/preprocess web pages). They cover common tasks like file ops, research, planning, collaboration, and code workflows—ready to plug into agents or LLM apps.What security and best practices should I follow when exposing tools via MCP?
- Apply least privilege: scope file servers to safe directories; lock down credentials and API keys.- Validate and test with the MCP Inspector before enabling autonomous use.
- Add evaluation/feedback loops to catch misuse or regressions; beware “rogue agent” behavior.
- Isolate stateful servers; remember SSE servers may be shared by multiple agents (watch in‑memory side effects).
- Prefer building your own MCP servers when you need tighter control, auditing, or custom safeguards.
AI Agents in Action, Second Edition ebook for free
