Understanding MCP: AI's Bridge to the Outside World

I've previously shared about MCP (Model Context Protocol) — a standardized conversation protocol that lets AI models (LLMs) talk to all kinds of external tools and data sources in the same way. In the past, if you wanted to connect AI to Google Drive, you had to write a whole integration just for Google Drive; to connect to Notion, you'd need to write another one. Now, with MCP, as long as everyone follows this protocol, AI can plug into all sorts of things with ease.

This post won't get too deep into theory — let's get straight to the point so you can quickly understand how MCP works, and I'll even walk you through building one yourself!

Core Architecture: Host vs. Client vs. Server¶

To understand MCP, you first need to distinguish between its three core roles: Host, Client, and Server.

1. Host (the main application)¶

Who is the Host?

Simply put, the Host is the application you're directly talking to. It's the "interface" for the AI.

What does it do?

The Host is responsible for displaying the AI's responses and receiving your input. Most importantly, it decides "when" an external tool needs to be called in to help, and hands that instruction off to its internal Client.

Examples:

• Claude Desktop
• Cursor (the well-known AI IDE)
• VS Code (with Copilot)
• A Python script you wrote yourself (if it can run an LLM and call tools)

2. Client (the client instance)¶

Who is the Client?

The Client is a module embedded inside the Host. Think of it as the Host's "communications officer."

What does it do?

The Client handles the "handshake" and "message passing." When the Host needs to use a tool (say, reading a file from Google Drive), the Client connects to the corresponding MCP Server, sends the instruction over, and relays the Server's response back to the Host. A Host can run multiple Clients at once, each connected to a different Server.

3. Server¶

Who is the Server?

The Server is the one actually providing tools or data. Think of it as the AI's "toolbox" or "library."

What does it do?

The Server defines a number of capabilities (in MCP terms: Resources, Prompts, and Tools). When it receives an instruction from the Client, it carries out the corresponding action — fetching a file from Google Drive, running a piece of Python code, searching the web — and sends the result back.

Examples:

• Hugging Face MCP Server (search models, papers)
• Google Drive MCP Server (access files)
• Jupyter MCP Server (lets AI run code in your Jupyter environment)
• A custom Server you wrote yourself with FastMCP

Comparing Channels: STDIO vs. SSE¶

How does the Client inside the Host actually talk to the Server? That's where the transport channel comes in. The two most common standard channels right now are STDIO and SSE, and they're suited for completely different scenarios.

1. STDIO (Standard Input/Output)¶

This is the most direct and conventional connection method, typically used when the Host and Server are running on the same machine.

• How does it work?

The Host (e.g., Claude Desktop) launches the Server's executable (or Docker container) as a subprocess. The Host sends JSON instructions through the Server's standard input (stdin) and reads responses from its standard output (stdout).
* Pros:

• No network configuration needed: no IPs, no ports — connecting is dead simple.
• Excellent performance: local process communication means latency is basically negligible.
• Synchronized lifecycle: when the Host shuts down, the Server process shuts down with it — no leftover processes.

• Cons:

• Can only connect to a Server running on your own machine.

2. SSE (Server-Sent Events)¶

If you want to connect to a remote Server (say, one hosted in the cloud or on a NAS), you'll need SSE.

• How does it work?

This is based on standard HTTP web technology. The Client (Host) first does a handshake with the Server, and then the Server opens a persistent HTTP stream. Through this stream, the Server can proactively push updated data or results to the Client.
* Pros:

• Supports remote connections: the Server can be hosted anywhere with network access.
• Multi-client support: a single Server can serve many Clients at once.

• Cons:

• Setup is more complex — you need to deal with networking, firewalls, port forwarding, and authentication.

Quick Comparison¶

Hands-On Practice¶

Enough talk — let's get hands-on. Here are two simple implementation examples.

1. FastMCP: Build and Dockerize Your Own MCP Server¶

This is an example of building a custom Server using Python's FastMCP library, then packaging it as Docker. We use Docker's -i (interactive) flag so the Server inside the container can communicate with the Host via STDIO.

Step A: Write a simple my_server.py

from fastmcp import FastMCP

# Create a FastMCP instance
mcp = FastMCP("My Cool Server")

# Define a simple tool: addition
@mcp.tool()
async def add_numbers(a: int, b: int) -> int:
    """Add two numbers together."""
    return a + b

if __name__ == "__main__":
    # Start the server in stdio mode
    mcp.run(transport="stdio")

Step B: Write a Dockerfile

FROM python:3.11-slim

# Set the working directory
WORKDIR /app

# Install the FastMCP library
RUN pip install --no-cache-dir fastmcp

# Copy the code into the container
COPY my_server.py .

# Default startup command
ENTRYPOINT ["python", "my_server.py"]

Step C: Build and start the container (Host side)

On your Host machine (terminal), build the Docker image:

docker build -t my-mcp-server .

Finally, configure your MCP config file (e.g., claude_desktop_config.json):

"mcpServers": {
  "my-docker-server": {
    "command": "docker",
    "args": ["run", "-i", "--rm", "my-mcp-server:latest"]
  }
}

At this point, Claude will start this container for you and connect to it via stdio.

2. Jupyter STDIO: Let AI Control Your Local Jupyter Environment¶

If you want a Host like Claude Desktop to directly operate Jupyter on your machine for data analysis, you can use jupyter-mcp-server.

Step A: Install the package

Run in your terminal:

# If installed in your Python environment
pip install jupyter-mcp-server

# Or, if you have uv, run it directly
uvx --install jupyter-mcp-server

Step B: Configure it in the Host's config file (using STDIO)

Configure it directly in your MCP config file (e.g., claude_desktop_config.json):

"mcpServers": {
  "my-jupyter": {
    "command": "jupyter-mcp-server",
    "args": []
  }
}

Now that you understand the differences between Host, Client, Server, and the transport channels, you should have a much clearer picture of how MCP works. Whether you use an off-the-shelf Server or build your own, MCP opens up endless possibilities for AI agent development. Go give it a try!