We have reached a saturation point with basic chatbots. The novelty of asking a question and receiving a text-based answer has faded; the industry is now pivoting violently towardagency—systems that can calculate, read local files, and structure complex workflows.
This is where the Model Context Protocol (MCP) becomes the critical infrastructure of the new AI stack.
However, a word of caution before we write a single line of code:Do not reinvent the wheel.If a server already exists for your specific database or API, use it. The true value for a senior developer lies not in building redundant connectors, but in crafting bespoke servers that bridge specific, proprietary gaps in your workflow.
While tools like n8n might offer a lower barrier to entry for simple automation, coding a custom MCP server using the Python SDK offers precision, particularly when integrating complexTools,Resources, andPromptsinto a single, cohesive unit.
This article details the construction of a comprehensive "Multitool" server. We will not just build a calculator; we will build a system that understands context through documentation resources and executes complex logic through dynamic prompt templates.
The Framework: The Triad of MCP Capabilities
To build a server that actually feels "intelligent," we must move beyond simple function calling. We need to implement the three pillars of the protocol:
- Tools:Executable functions. (e.g., A calculator or API fetcher).
- Resources:Static or dynamic data context. (e.g., Reading a local SDK documentation file).
- Prompts:Structured templates that guide the LLM's behavior. (e.g., A formalized meeting summary generator).
We will use thefast-mcppython library, creating a server that offers mathematical precision, documentation access, and structured analysis simultaneously.
Part 1: Setting the Foundation
The ecosystem we are entering requires a specific stack. We are not coding like it’s 1999; we are utilizing modern tooling.
- Runtime:Python 3.12+
- Package Manager:
uv(for lightning-fast dependency management). - Development Environment:Cursor (highly recommended for its ability to digest documentation for context).
The Initialization
We begin by initializing a project structure that is clean and modular.
# Initialize the project
uv init
# Create a virtual environment
uv venv
# Activate the environment
. .venv/bin/activate # On Windows: .venv\Scripts\activate
# Install the core dependency
uv add mcp-cli
Our entry point will be a file namedserver.py. The imports set the stage: we needfast_mcpfor the server architecture and standard libraries likemathandosfor our logic. mcp.server.fastmcp import FastMCP
from mcp.server.fastmcp import FastMCP
import math
import os
# Initialize the server
mcp = FastMCP("Calculator Server")
The most direct way an LLM affects the world is through tools. We will implement a robust calculator. While trivial in logic, it demonstrates the critical requirement ofprecise description.
If you do not describe your tool accurately, the LLM will not know when to call it. Ambiguity is the enemy of agency.
Implementing the Calculator
We define tools using the@mcp.tool()decorator. Note the docstrings; these are not just comments for developers, they are instructions for the AI.()
@mcp.tool()
def add(a: int, b: int) -> int:
"""Add two numbers together."""
return a + b
@mcp.tool()
def multiply(a: int, b: int) -> int:
"""Multiply two numbers together."""
return a * b
@mcp.tool()
def power(a: float, b: float) -> float:
"""Calculate a to the power of b."""
return math.pow(a, b)
We can expand this to include subtraction, division, square roots, and functionality for percentages. The key takeaway is modularity. Each mathematical operation is a discrete tool the model can invoke.
Part 3: Resources — The Context Layer
Tools allow action, butResourcesallow understanding. A common use case is feeding the model local documentation or file content that isn't part of its training data.
In our architecture, we will expose a Markdown file containing documentation (hypothetically, a TypeScript SDK manual) as a consumable resource.
The Implementation
Resources differ from tools; they are read-only data streams. We define a path to a local markdown file and expose it via the@mcp.resourcedecorator.
# Define the path to your local documentation
resource_path = "./type_sdk.md"
@mcp.resource("file://type_sdk.md")
def get_typescript_docs() -> str:
"""
Provide access to the TypeScript SDK MCP documentation.
This resource contains detailed information about the SDK.
"""
if os.path.exists(resource_path):
with open(resource_path, 'r') as f:
return f.read()
return "Documentation file not found."
When the client (e.g., Claude Desktop) requests this resource, the server reads the file dynamically and pipes the text directly into the model's context window. This allows you to ask questions like "How do I use the TypeScript SDK?" and have the model answer based onyourlocal file, not general training data.
Part 4: Prompts — The Logical Layer
This is often the most underutilized capability.Promptsallow you to standardize workflows. Instead of manually typing "You are an executive assistant, please summarize this transcript...", you codify that into a template.
We will create a "Meeting Summary" prompt. This prompt will accept dynamic arguments: the date, the meeting title, and the transcript.
The Importance of Dynamic Prompts
The prompt template itself is a Markdown file stored in your project (e.g.,templates/prompt.md). It defines a persona and a structure:
# Meeting Summary Template
You are an executive assistant. Your task is to analyze the following meeting transcript.
**Date:** {{date}}
**Title:** {{title}}
**Transcript:** {{transcript}}
Please provide a comprehensive analysis including overview, key participants, and action items.
integrating into the Server
There is a temptation to over-engineer this using complexlist_promptsandget_promptshandlers. Avoid this. The SDK provides a cleaner abstraction using@mcp.prompt.()
@mcp.prompt()
def meeting_summary(date: str, title: str, transcript: str) -> str:
"""
A prompt template for generating meeting summaries.
Args:
date: The date of the meeting
title: The title of the meeting
transcript: The full text transcript
"""
# Logic to read the template file and replace placeholders
template_path = "templates/prompt.md"
with open(template_path, 'r') as f:
content = f.read()
# Simple replacement of dynamic variables
return content.replace("{{date}}", date)\
.replace("{{title}}", title)\
.replace("{{transcript}}", transcript)
By defining arguments in the function signature, the MCP client automatically generates a UI form for these inputs. You simply type the date and paste the transcript; the server constructs the engineered prompt.
Section 5: The Critical Link — Configuration
A server running in a vacuum is useless. We must bridge our local python process with the client, in this case, Claude Desktop.
This requires theclaude_desktop_config.jsonfile. This file tells the client: "here is a server, here is how you launch it, and here is how you talk to it."
The Configuration Structure:
{
"mcpServers": {
"calculator_server": {
"command": "uv",
"args": [
"--directory",
"C:\\Users\\Path\\To\\Your\\Project",
"run",
"server.py"
],
"env": {
"uv_project_environment": ".venv"
}
}
}
}
Key Insight:Notice we aren't just callingpython. We are invokinguv run. This ensures the server runs inside the correct virtual environment with all dependencies resolved. Breaking out of the environment is the number one cause of "module not found" errors in MCP deployment.
Section 6: Debugging with the Inspector
Debugging an MCP server by restarting Claude Desktop repeatedly is painful and inefficient. It is akin to recompiling a kernel to change a font size.
Use theMCP Inspector.
The Inspector acts as a web-based client for your server. It allows you to test:
- Tools:Input numbers and see if the calculator returns the correct integer.
- Resources:verification that the markdown file loads correctly.
- Prompts:Testing the UI fields for the Meeting Summary.
To run the Inspector:
npx @modelcontextprotocol/inspector uv run server.py
Developer Warning:When the Inspector launches, it may generate an authorization token in the URL for security. If you try to connect via a genericlocalhost:portURL without the token, it will fail. Always use the full URL provided in the terminal output, or verify if you are running with authorization disabled (only recommended for local testing).
Section 7: Final Thoughts on Transport
By default, we utilizestdio(Standard Input/Output) for communication. This is effective for local desktop integration. However, as you scale, you may wish to expose your server over a network.
Historically,SSE (Server-Sent Events)was the standard. However, the protocol is shifting. SSE as a standalone transport is being deprecated in favor ofStreamable HTTP, which incorporates SSE as a streaming mechanism but offers a more robust HTTP wrapping.
If you wish to future-proof your server for remote access (e.g., hosting it on a VM), you can switch the transport mode in your main execution block:
if __name__ == "__main__":
# Choose your transport layer
mcp.run(transport="stdio")
# OR
# mcp.run(transport="sse")
When you inspect a server running over HTTP, remember to append/mcpto your endpoint URL (e.g.,http://localhost:8000/mcp) to successfully handshake with the Inspector.
Conclusion
We have moved from an empty directory to a fully functional "Multitool" server. It possesses the ability to calculate (Tools), the ability to read and contextualize external data (Resources), and the ability to guide high-level analysis (Prompts).
You now possess the blueprint. The next step is not to add more calculator functions, but to look at your own proprietary data—your SQL databases, your internal documentation, your specific workflows—and build the bridges that allow your AI to access them. That is where the true engineering begins.
Deutsch 
Français 
Bahasa Indonesia 
Polski 
Русский 
Українська 
简体中文 