Building Your Own MCP Server

What this article covers

• How an MCP server is structured.
• How to define tools and resources.
• How transport works over stdio and HTTP.
• How to implement a server in Python or TypeScript.
• Deployment, security, and common pitfalls.

Introduction: Building Your Own MCP Server

MCP servers form the backbone of a modular agent ecosystem. They expose tools and data that AI agents can use. By building your own MCP server, you can connect internal databases, APIs, file systems, or specialized tools to agents without modifying the agents themselves.

Building a server is straightforward. A few lines of code define tools and resources. The real challenge is not technical but security: an MCP server with file system or database access is powerful and must be well-protected.

Why do you need your own MCP server?

Existing MCP servers cover many standard tools. But proprietary data, internal APIs, or specialized workflows require custom servers. Your own server enables you to:

• Connect internal databases
• Expose company-owned APIs
• Encapsulate security-sensitive operations
• Reuse functionality across multiple agents
• Establish a clear interface between agent and infrastructure

MCP servers explained

An MCP server responds to requests from an MCP client. It tells the client which tools and resources it offers. When needed, it executes the requested tool or returns a resource. Communication happens via JSON-RPC.

Key concepts:

• Tool: An executable function with an input schema.
• Resource: An addressable data source.
• Prompt: A predefined message template.
• Capability: A capability that the server announces.
• Transport: stdio or HTTP/SSE.
• ServerInfo: Metadata such as name and version.

Who should build an MCP server?

• Developers who want to connect internal tools to agents.
• Teams that need to provide reusable tools.
• Security teams who want to control permissions.
• Architects designing modular AI systems.

Key terminology for MCP servers

• FastMCP: A lightweight Python framework for MCP servers.
• mcp-sdk: Official SDKs for Python and TypeScript.
• StdioServerTransport: Local transport via process pipes.
• SSEServerTransport: HTTP transport for remote clients.
• Pydantic: Input validation for tools in Python.

Building an MCP server in Python with FastMCP

FastMCP greatly simplifies development:

from fastmcp import FastMCP

mcp = FastMCP('notizen-server')

@mcp.tool()
def suche_notiz(schluesselwort: str) -> str:
    """Sucht nach Notizen mit dem angegebenen Schluesselwort."""
    # Beispiel-Implementierung
    notizen = {
        'ollama': 'Ollama ist ein Tool für lokale KI.',
        'docker': 'Docker erleichtert die Bereitstellung.'
    }
    return notizen.get(schluesselwort, 'Keine Notiz gefunden.')

@mcp.resource('notizen://liste')
def notizen_liste() -> str:
    return 'Verfügbare Notizen: ollama, docker'

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

The server registers the tool and resource. A client can call either one.

Defining tools

Tools need a clear schema. In FastMCP, Python type hints and docstrings handle this:

@mcp.tool()
def temperature_in_stadt(stadt: str) -> str:
    """Gibt die aktuelle Temperatur für eine Stadt zurück."""
    return f'22 Grad in {stadt}'

The docstring gets sent to the model so it understands when to use the tool.

Choosing a transport

stdio

Suitable for local processes. The client starts the server as a subprocess.

mcp.run(transport='stdio')

SSE

Suitable for remote or long-lived connections. The server exposes an HTTP endpoint.

mcp.run(transport='sse')

Deployment

Python

python notizen-server.py

Or in Docker:

services:
  mcp-notizen:
    build: .
    command: python notizen-server.py

Security

• Input validation: Use type hints and Pydantic validation.
• Permissions: Allow only necessary operations.
• Logging: Track who calls what.
• Sandboxing: Run the server in a container or isolated environment.
• Human approval: Require confirmation for deletions, writes, or external calls.

Common pitfalls when building MCP servers

• Poor tool descriptions: The model doesn’t understand when to use the tool.
• Missing error handling: Server crashes on invalid input.
• No versioning: Interfaces change without notice.
• Excessive permissions: A server should not be able to do everything.
• Transport mismatch: Choose stdio vs. SSE based on your use case.
• No monitoring: No visibility into what the agent is calling.

Further reading and resources

• BotServ.de MCP Fundamentals
• BotServ.de AI Agents
• BotServ.de Coding Agents
• FastMCP
• MCP Specification

FAQ: MCP servers

Do I need TypeScript? No. Python works great with FastMCP.

Can I have multiple tools in one server? Yes. A server can expose any number of tools and resources.

How do I test an MCP server? Use an MCP client or the Inspector from the MCP SDK.

Do MCP servers run locally? Yes, using stdio or SSE on localhost.

Are MCP servers secure? Only as secure as their permissions and validation.

Sources and further reading

• MCP: https://modelcontextprotocol.io/
• FastMCP: https://github.com/jlowin/fastmcp
• Python SDK: https://github.com/modelcontextprotocol/python-sdk

Summary: Building your own MCP server

Your own MCP server makes internal tools and data available to AI agents. Getting started is quick with FastMCP in Python or the official SDKs. What matters is clear tool schemas, good descriptions, choosing the right transport, and security. When you pay attention to permissions, validation, and logging, you get a robust, reusable bridge between your agent and your infrastructure.