Model Context Protocol (MCP)

"Standards are wonderful. That is why every vendor invents their own."

Pip, Protocol-Weary AI Agent

1. What Is MCP?

The Model Context Protocol (MCP) is an open standard created by Anthropic that defines how LLM applications connect to external data sources and tools. Think of it as USB for AI: a universal interface that lets any MCP-compatible application connect to any MCP server without custom integration code. Before MCP, every tool integration required bespoke code for each LLM provider and each data source. MCP standardizes this into a single protocol with well-defined message formats, capability negotiation, and transport layers.

The adoption has been rapid. As of early 2026, the MCP ecosystem includes over 6,400 community-built servers covering databases, APIs, file systems, development tools, and cloud services. The TypeScript and Python SDKs see over 97 million monthly downloads combined. Major AI applications including Claude Desktop, Cursor, Windsurf, and numerous open-source agent frameworks support MCP natively. This ecosystem effect means that building one MCP server makes your tool available to every MCP-compatible agent, rather than requiring separate integrations for each platform.

MCP follows a client-server architecture. The MCP host is the LLM application (Claude Desktop, your custom agent). The MCP client is a protocol handler within the host that manages connections. MCP servers expose tools, resources (data), and prompts through the protocol. A single host can connect to multiple servers simultaneously, giving the agent access to a rich set of capabilities through a unified interface.

MCP Architecture

Input: MCP host (LLM application), MCP server (tool provider)
Output: established session with discovered capabilities

1. Host opens transport (stdio pipe or HTTP/SSE connection)
2. Host sends initialize request:
 { protocolVersion, clientInfo, capabilities }
3. Server responds with initialize result:
 { protocolVersion, serverInfo, capabilities }
 // capabilities declare: tools, resources, prompts
4. Host sends initialized notification
 // handshake complete, session is now active
5. Host calls tools/list to discover available tools
6. Server returns tool schemas (name, description, inputSchema)
7. for each user interaction:
 a. LLM selects a tool and generates arguments
 b. Host sends tools/call { name, arguments }
 c. Server executes tool, returns result content
 d. Host feeds result back to LLM for next step
 

# Building a simple MCP server with the Python SDK
from mcp.server import Server
from mcp.types import Tool, TextContent
import mcp.server.stdio

server = Server("weather-server")

@server.list_tools()
async def list_tools():
 return [
 Tool(
 name="get_weather",
 description="Get current weather for a city. Returns temperature, "
 "conditions, humidity, and wind speed.",
 inputSchema={
 "type": "object",
 "properties": {
 "city": {
 "type": "string",
 "description": "City name, e.g. 'London' or 'Tokyo'",
 },
 },
 "required": ["city"],
 },
 )
 ]

@server.call_tool()
async def call_tool(name: str, arguments: dict):
 if name == "get_weather":
 city = arguments["city"]
 # In production, call a real weather API here
 weather = fetch_weather(city)
 return [TextContent(
 type="text",
 text=f"Weather in {city}: {weather['temp']}C, "
 f"{weather['conditions']}, "
 f"Humidity: {weather['humidity']}%"
 )]
 raise ValueError(f"Unknown tool: {name}")

async def main():
 async with mcp.server.stdio.stdio_server() as (read, write):
 await server.run(read, write, server.create_initialization_options())

if __name__ == "__main__":
 import asyncio
 asyncio.run(main())

from langchain_core.tools import tool

@tool
def get_weather(city: str) -> str:
 """Get current weather for a city."""
 return f"Weather in {city}: 18C, partly cloudy, humidity 65%"

# Bind the tool to any chat model that supports function calling
llm_with_tools = chat_model.bind_tools([get_weather])

2. Building MCP Servers

An MCP server exposes capabilities through the protocol. The simplest servers wrap a single API or database. More sophisticated servers expose multiple tools, resources, and prompts. The key design decisions are: what granularity of tools to expose (one broad tool vs. many specific tools), what data to surface as resources (schema information, documentation, recent results), and how to handle authentication and rate limiting.

The MCP SDK handles protocol negotiation, message serialization, and transport (stdio for local servers, SSE/HTTP for remote servers). Your job is to implement the tool logic and define clear schemas. A well-designed MCP server follows the same principles as a good REST API: clear naming, comprehensive descriptions, sensible defaults, and informative error messages. The model reads your tool descriptions to decide when and how to call them, so invest time in writing descriptions that are precise and include usage examples.

For database access, consider exposing both query tools (let the model write SQL) and structured access tools (predefined queries with parameters). The query approach is more flexible but requires careful sandboxing to prevent destructive operations. The structured approach is safer but limits what the agent can do. Many production deployments use a hybrid: structured tools for common operations, a read-only SQL tool for ad-hoc queries, and no write access through MCP at all.

3. The MCP Ecosystem

The MCP ecosystem has grown rapidly through community contributions. Major categories of available servers include: database access (PostgreSQL, MySQL, SQLite, MongoDB), cloud services (AWS, GCP, Azure), development tools (GitHub, GitLab, Jira, Linear), communication (Slack, Discord, email), file systems (local, S3, Google Drive), and specialized domains (financial data, weather, geolocation). The MCP registry at github.com/modelcontextprotocol/servers catalogs officially maintained servers, while thousands more community servers are available through npm and PyPI.

Composing multiple MCP servers is where the protocol's value becomes most apparent. A development agent can simultaneously connect to GitHub (for code and issues), Jira (for project management), Slack (for team communication), and a database server (for application data). Each server is maintained independently, and the agent seamlessly uses tools from all of them within a single conversation. This composability would require significant custom integration work without a standardized protocol.

Lab: Build an MCP Server and Client

pip install torch transformers numpy

# TODO: Implement setup code here

# Complete solution for this lab exercise
# TODO: Full implementation here

Exercises