liveBook · Manning

MCP

As explained in Building Reliable AI Systems

A protocol for connecting AI applications and agents to external data sources and tools.

A customer asks an AI assistant for waterproof hiking boots under $150. Answering requires product search and perhaps an availability check. Without a shared interface, each AI application needs custom code for each database or API. MCP standardizes how applications connect to external tools, reducing duplicated integration work. section 7.0 section 7.3

An MCP server exposes tools backed by external systems; an MCP client lets an AI application connect to them. With five applications and ten APIs, the comparison is 50 custom integrations versus five application connectors and ten MCP servers. The protocol standardizes the interface, but each tool still needs working execution logic. section 7.10 section 7.3

{
  "name": "send_email",
  "description": "Send an email via an external email API",
  "inputSchema": {
    "type": "object",
    "properties": {
      "to": {"type": "string"},
      "subject": {"type": "string"},
      "body": {"type": "string"}
    }
  }
}

A tool schema gives the model an action name, a description, and typed inputs. Those details are part of the interface: they help the model decide when and how to call the tool. section 7.3 section 7.10

To build a tool, implement its task as a Python function, decorate it with FastMCP, and run an MCP server. A client can obtain available tools from the server’s /tools/list endpoint rather than defining every function schema inline. The runtime loads those descriptions into the conversation context so the model can select and call tools. section 7.10 section 7.6.1

Product search

Expose a search_products tool that returns structured product data over HTTP. For a request about hiking boots, the model can discover the tool, use it to search the catalog, and use the result to form a response. If availability requires another tool, it can choose that next call based on the user’s request. section 7.0 section 7.6 section 7.10

A standard interface does not make a tool safe or its answer correct. Distinguish an empty result from a failed database call; return consistent success flags, error codes, and readable messages. Add input validation and timeouts. Authentication, authorization, and endpoint security remain your responsibility. section 7.10 section 7.3

How Building Reliable AI Systems covers it

How deep it goes
Works through server and client roles, schemas, discovery, implementation, and error handling; leaves tool execution and security implementation to developers.
Examples
Uses a hiking-boot product search, an email-tool schema, and a locally running HTTP product-search tool.
What it assumes
Assumes familiarity with Python functions and APIs while introducing MCP server setup and tool discovery through a concrete application.
What you can do after
Build it from scratch: implement Python tools with FastMCP and expose them for model discovery through an MCP server.
How it connects
Links agent architectures and function calling to tool discovery, tool chaining, APIs, and structured error handling.

Also explained in

Compare how 14 books explain MCP →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Building Reliable AI Systems. The section links point to the parts of the book it draws on.