Chapter 13: Building and consuming MCP servers

Introduction

The chapter introduction explains why integrating external context into agents is difficult and presents MCP as a shared way to expose and use remote tools.

• Repeated tool integration work: Explain why giving agents access to multiple external data sources has been costly: developers had to wrap each source as a tool, often across different protocols, and teams repeated that work.
  Why it matters: This is the integration problem MCP is intended to address.
• MCP tool connection model: Describe how MCP addresses repeated integration work: services expose tools through MCP servers, while agent hosts use MCP clients to discover and invoke those remote tools within existing agent architectures.
  Why it matters: The server–client relationship explains how a published tool can fit into an existing agent.
• MCP ecosystem adoption: State that MCP has gained broad adoption among major LLM providers and service publishers, with many tools available through public portals.
  Why it matters: Existing published tools make MCP useful beyond servers a developer builds personally.

Key terms: external context, tools, protocols, Model Context Protocol (MCP), MCP servers, MCP hosts, MCP clients, remote tools, public MCP portals

13.1 Introduction to MCP servers

The section explains why custom tool wrappers make external context integrations costly and how MCP offers a reusable alternative.

• Custom tool integration costs: Explain why the traditional approach to giving agents access to databases, APIs, and services creates duplicated effort and inconsistent integrations.
  Why it matters: This is the integration problem MCP is meant to reduce.
• Shared MCP tool interface: Describe how MCP changes who exposes external capabilities as tools and why that makes integrations more reusable.
  Why it matters: A shared way to expose tools reduces the need to rebuild the same integration for every agent.

Key terms: external sources of context, tools, ad hoc protocols, wrappers, MCP, context providers, common protocol, custom glue code

13.1.1 The problem: Context integration at scale

This section explains why integrating external context sources into LLM agents becomes repetitive and difficult to scale.

• Context integration scaling problem: Explain why adding external data sources to LLM agents creates a scaling problem: each source needs a wrapper tool and agent integration, often with different conventions, so many teams duplicate the same work.
  Why it matters: This is the integration problem that motivates the next section’s discussion of MCP.

Key terms: LLM agents, context source, wrapper tool

13.1.2 The solution: The Model Context Protocol

This section explains how MCP lets agents use tools exposed by servers through a standard client/server architecture.

• Standardized tool access: Explain how MCP reduces the need for each agent to wrap every service individually by letting providers expose reusable tools through MCP servers.
  Why it matters: A shared way to expose tools makes it easier to add or replace sources an agent can use.
• MCP host and server roles: Describe how an agent or application acts as an MCP host, connects through an MCP client to one or more servers, and selects the tools it needs.
  Why it matters: These roles clarify how an agent reaches tools supplied by external servers.
• Server connections and tool use: Distinguish the remote and local MCP server connections described here, and explain how configured MCP tools fit into an agent’s existing tool calling.
  Why it matters: The connection can change without necessarily changing how a well-architected agent calls tools.

Key terms: Model Context Protocol, MCP servers, tools, MCP host, MCP client, MCP server, remote MCP servers, Streamable HTTP, local MCP servers, STDIO

13.1.3 The MCP ecosystem

This section describes how growing adoption of MCP, service-provider servers, and public directories give agents access to a widening pool of tools.

• Growing MCP tool ecosystem: Explain how support from LLM providers, MCP servers offered by service providers, and public server portals make more tools available to agents and applications.
  Why it matters: The growing ecosystem makes it easier to find tools that agents can use, rather than building every tool in-house.

Key terms: MCP servers, MCP server portals, shared library of tools

13.2 How to build MCP servers

This section introduces the upcoming guidance on resources, tools, and practices for building and integrating MCP servers.

13.2.1 Essential resources for MCP server development

The section identifies the official MCP documentation and SDKs as the starting resources for server development.

• Official MCP documentation: Describe where to find the official MCP documentation and why the protocol specification is useful before writing code.
  Why it matters: The official documentation gives you a reliable reference before you start implementing an MCP server.
• Official SDKs over scratch implementations: Justify using an official language-specific MCP SDK rather than implementing the protocol from scratch.
  Why it matters: An official SDK lets you focus on your server rather than rebuilding existing protocol support.

Key terms: official hub, MCP protocol specification, technology-agnostic, official language-specific SDKs, implementing MCP from scratch

13.2.2 Official language-specific MCP SDKs

This section identifies the official language-specific MCP SDKs and explains why the book uses FastMCP 2 for its Python examples.

• Official MCP SDK Languages: Describe the availability of official MCP SDKs across several programming languages and the book’s focus on Python.
  Why it matters: You can follow the Python examples without assuming MCP is limited to Python.
• FastMCP Version Progression: Explain how FastMCP 2 builds on FastMCP 1 and identify improvements named in the section.
  Why it matters: The distinction explains why the hands-on Python examples use FastMCP 2 rather than the initial SDK.

Key terms: official SDKs, Python, FastMCP 1, FastMCP 2, Python SDK

13.2.3 Consuming MCP servers in LLM applications and agents

This section explains how applications can consume public MCP tools through OpenAI’s Responses API and what to use when MCP servers are accessible only within an organization.

• Public MCP tool consumption: Explain that OpenAI’s Responses API can discover, reference, and execute tools from public MCP servers, often without manual client code. State that applications should choose whether to approve those calls automatically or interactively.
  Why it matters: It helps you recognize when a hosted API can spare your application from implementing an MCP client.
• Organization-only MCP server access: Distinguish the two client options when an MCP server is accessible only within an organization: use the FastMCP client to connect, authenticate, and consume tools directly, or use LangChain’s MCP client integration to aggregate tools from multiple servers for a LangChain or LangGraph agent.
  Why it matters: It identifies workable integration paths when a hosted API cannot reach an internal server.

Key terms: Responses API, public MCP servers, authorization strategy, FastMCP client, LangChain MCP client library, MultiServerMCPClient

13.3 Building a weather MCP server

This section previews replacing a mock weather tool with an AccuWeather-based MCP server, then testing and connecting it to an existing agent.

13.3.1 Implementing the MCP server

This subsection sets up and starts an AccuWeather MCP server to replace a mock weather tool, and explains its basic weather-lookup flow.

• AccuWeather server setup: Describe how to prepare and start the AccuWeather MCP server: obtain an API key, put it in the project’s .env file, create the server script in ch11/mcp, and run it from that folder with the virtual environment active.
  Why it matters: These steps prepare the live weather server for testing and use.
• Live weather lookup flow: Explain the basic flow used by the server to return live weather: resolve the user’s input through AccuWeather’s locations REST endpoint, then query its API for current conditions.
  Why it matters: This distinguishes the live server from the earlier mock weather tool.

Key terms: AccuWeather API key, .env, mcp, accuweather_mcp.py, virtual environment, fastmcp, FastMCP 2, AccuWeather locations REST endpoint, current weather conditions

13.3.2 Trying out the MCP server with MCP Inspector

This section shows how to use MCP Inspector to connect to a Weather MCP server and verify its tool without writing client code.

• MCP Inspector testing setup: Explain why MCP Inspector is useful for an initial server test and describe how to launch it.
  Why it matters: It lets you check a new server before building a client for it.
• Weather server Inspector connection: Describe the Inspector settings for connecting to the Weather MCP server and how to recognize a successful connection.
  Why it matters: A confirmed connection separates server availability from whether a particular tool works.
• Weather tool live verification: Trace how to find and run the weather tool in Inspector and describe what its output verifies.
  Why it matters: A successful connection is only part of the check; running the tool verifies its behavior.

Key terms: MCP Inspector, Node.js, npx, Streamable HTTP, Via Proxy, Authentication, Connected, Tools tab, List Tools, get_weather_conditions

13.3.3 Consuming the MCP server from a test MCP host

This section uses a lightweight MCP host to test that the weather server exposes a tool and returns a protocol-compliant result.

• Programmatic MCP server test: Describe how the test MCP host connects to the weather server, discovers its tools, and calls the weather tool to verify the server programmatically.
  Why it matters: This checks through code that the server can be discovered and its tool can be called.
• Weather tool result format: Explain what the test output shows about the weather tool’s response and its compatibility with the expected tool-calling protocol.
  Why it matters: The result format shows that the server’s response can be handled through the expected tool-calling protocol.

Key terms: MCP host, MCP client, MCP server endpoint, available tools, get_ weather_conditions, CallToolResult, tool-calling protocol

13.4 Integrating the Weather MCP tool into an agent

This section introduces the planned replacement of the travel agent’s mock weather tool with a live tool from a remote MCP server.

13.4.1 Preparing the travel agent for live weather data

This section prepares the travel agent to replace its made-up weather forecasts with a tool from an AccuWeather MCP server, using the mock agent’s behavior as a baseline.

• Local-to-remote weather tool replacement: Describe the planned change to the travel agent: remove its local mock weather tool and service, then use a client to connect to the AccuWeather MCP server and retrieve the remote tool dynamically.
  Why it matters: This identifies what must change before the agent can use live weather data.
• Mock weather behavior baseline: Describe how the section checks the existing agent’s behavior before the change: copy the initial agent file, run it in debug mode, and observe that its weather response is made-up mock data.
  Why it matters: The baseline makes the difference between the old mock response and live weather information clear.

Key terms: weather_forecast tool, WeatherForecastService, AccuWeather MCP server, remote tool, main_03_01.py, main_07_01.py, debug mode, mock data

13.4.2 Integrating the AccuWeather MCP tool

13.4.3 Updating the agent chat loop

13.4.4 Combining local and remote tools

This subsection brings AccuWeather MCP tools and a local semantic search tool together in an asynchronous agent.

• Combined local and MCP tools: Describe how the agent brings together the AccuWeather tools and its local semantic search tool, and state that both main() and the chat loop are asynchronous.
  Why it matters: This is the point where the agent can use both its local search tool and the weather tools exposed through MCP.

Key terms: async main(), AccuWeather tools, local semantic search tool, MCP tools, chat loop

13.4.5 Testing and verification

This section shows how to verify that a travel agent has both local and remote tools available and actually calls its AccuWeather MCP tool.

• MCP Tool Integration Verification: Describe how to check that the updated agent has both local and remote tools available, then confirm that a weather request invokes the AccuWeather MCP server.
  Why it matters: These checks distinguish a tool being available to the agent from the agent actually using it.

Key terms: tools list, local and remote tools, AccuWeather MCP server, LangSmith trace

13.4.6 Using the agent for complex queries

This section suggests testing the travel agent with queries that combine travel information and live weather, and explains the value of its MCP weather tool.

• Combined travel and weather queries: Explain that integrating the MCP server’s weather tool lets the agent combine live weather data with its travel-information skills to give real-time, actionable answers. Describe testing this with reasoning-based queries adapted to the current season.
  Why it matters: It shows what the weather integration adds to the travel agent’s answers.

Key terms: MCP server, weather tool, live weather data, local agent skills

13.5 Summary

The section summarizes how MCP standardizes agent access to external tools, how to build and test MCP servers, and how agents consume their tools alongside local ones.