👋This is the start of a series where I document what I'm learning about Model Context Protocol Architecture and Tool implementations

I'd been reading about MCP for a while and felt like I had a good grasp of the concepts, but I hadn't actually built anything yet. So this series is me finally putting my hands on it, documenting what I've been learning over the last few weeks, and sharing it in case it's useful to others!

My learning is coming from a mix of things: Some books, a few YouTube tutorials, conversations with DevRel peers exploring similar things, and a fair amount of AI assistance to help me understand concepts along the way 😄

Here's what I built and what I found out along the way. Let's start!

An Intro to Model Context Protocol (MCP)

In the MCP Standard book, by Srinivasan Sekarthere is a perfect analogy to explain the problem MCP solves.

Picture this: you have "M" AI models and "N" tools you want to connect to them.

• The Old Way: Without a standard, you'd have to build a unique integration for every single combination. That’s ‭$M \times N$‬‭‬ different connections and a total nightmare to maintain!
• The MCP Way: MCP acts as the universal plug. You build your tool once to the MCP standard, and it instantly works with any model that speaks it.

Does this scenario sound familiar? It's what happened with containerization before Kubernetes. Kubernetes came along and said: Here's the standard. MCP is doing the same thing for AI tooling.

The 3 MCP Roles to Understand

Before building anything, there are three roles to wrap your head around:

• The Host is the app the user interacts with directly. It decides which tools to call, keeps the conversation context, and manages clients. Think Claude Desktop, Goose, VS Code, Cursor.

• The Client lives inside the host. It maintains the connection with a concrete MCP Server.

• The Server answers client requests and exposes tools, resources, and prompts through the MCP protocol.

Before MCP, the AI agent was doing everything (fetching data, formatting it, calling the model, returning the answer. One giant piece of logic. Hard to test and hard to scale). After MCP, the agent only does one thing: reason.

Level 0: Let's build a Calculator

Not glamorous, but the perfect hello world for understanding the fundamentals

1. Using the MCP Python SDK

To build an MCP server you don't need to implement the protocol from scratch. Anthropic maintains an official open source SDK (under MIT license) under the modelcontextprotocol organisation on GitHub.

Without the SDK you'd have to manually handle the JSON-RPC messages that flow between host and server via stdin/stdout, implement the handshake, route requests, serialize responses... It's totally doable, but the SDK abstracts all of that.

There are two ways to build a server inside the Python SDK, and I decided to go with FastMCP option.

💡At this point, you're setting up the Server side of the architecture. No Host or Client involved yet, just your Python environment and the SDK.

2. Create the Server (server.py)

Not glamorous but the perfect "hello world" for understanding the fundamentals before building something actually useful.

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("calculator")

@mcp.tool()
def multiply(a: float, b: float) -> float:
    """Multiply 2 numbers"""
    return a * b

# + add, subtract, divide...

if __name__ == "__main__":
    mcp.run()

💡Your server.py is the MCP Server. It exposes tools through the protocol. No Host has connected to it yet.

3. Test Server and Tools

Before connecting to any AI host, I tested it with the official MCP Inspector

uv run mcp dev server.py

A browser UI opens. You'll see: status "Connected", server name "calculator", SDK version, and the history.

💡 The MCP Inspector is acting as both Host and Client here: doing the handshake, maintaining the connection, calling your tools

4. Connect to a Host

I tested three options:

🪿 Goose

Goose is an open-source AI agent that can act as an MCP Client and has a visual form to configure the extension name, type (STDIO), and the command it runs every time it starts. Internally, it stores config in a YAML file you never touch.

✳️ Claude Desktop

Claude Desktop needs you to configure a manual JSON such as:

{
  "mcpServers": {
    "calculator": {
      "command": "/path/to/uv",
      "args": ["run", "--directory", "/path/to/project", "python3", "server.py"]
    }
  }
}

🤖 VS Code + Copilot

Same JSON approach as Claude Desktop inside settings.json.

💡 Each host manages its own MCP Client internally. You don't write client code (the host handles that). Your job as a "server developer" is just to make sure your server speaks valid MCP.

5. Full MCP Cycle Overview

As a takeaway, let's summarize the process into this 8-step cycle:

• 1 User type the query and the Host receives it
• 2 Host passes it to the LLM for initial reasoning. LLM decides: "I need an external tool for this"
• 3 LLM signals tool invocation intent to the Host
• 4 Host delegates to the Client (the messenger)
• 5 Client serializes the request in JSON-RPC and sends it to your MCP Server via stdin/stdout
• 6 Server validates and executes your Python function
• 7 Server returns a standard MCP response
• 8 Host shows the result to the user

What's Next?

The calculator was self-contained (all logic lived in server.py). In my next post, I'll share my experience in building a GitHub Stats server to talk to an external API and how to handle authentication, rate limits, and what data to expose to the LLM.

Resources

• A Developer's Guide to Building Universal AI Tools Using MCP
• Python SDK Documentation
• MCP Inspector Documentation
• Goose Website
• Goose Repo
• Groq Console
• Ollama Website