Model Context Protocol Python Tutorial: Baue deinen ersten MCP-Server
Lerne Model Context Protocol mit Python anhand eines praktischen Tutorials für den ersten Server, der zentralen MCP-Konzepte und des schnellsten Wegs von eigenen Skripten zu wiederverwendbarem KI-Tooling.
Die meisten Inhalte zu MCP bleiben bei der großen Idee stehen: eine standardisierte Möglichkeit, KI-Tools mit externen Systemen zu verbinden. Das ist nützlich, hilft aber wenig, wenn du vor einem Python-Projekt sitzt und dich fragst, was du zuerst bauen sollst. Dieser Leitfaden geht den praktischen Weg. Wenn du Model Context Protocol Python gut genug verstehen willst, um etwas auszuliefern, ist ein kleiner Server der beste Ausgangspunkt, der ein Tool, eine Ressource und einen klaren Anwendungsfall bereitstellt.
Dieser Blickwinkel hat im Moment eine starke Suchintention, weil Entwickler über generische „KI-Agenten”-Experimente hinausgehen und eine engere Frage stellen: Wie verbinde ich Modelle mit echten Dateien, APIs und Geschäftslogik, ohne jedes Mal eine eigene Klebeschicht zu erfinden? Wenn du noch deinen ersten Agenten baust, beginne mit unserem Leitfaden KI-Agenten mit Python erstellen.
Warum dieses Thema gerade im Trend liegt
MCP hat sich von einem Nischen-Protokollthema in den Mainstream-Workflow von Entwicklern bewegt.
Anthropic kündigte im Dezember 2025 an, dass MCP mit Unterstützung von Anthropic, OpenAI, Microsoft, Google, AWS, Cloudflare, Block und Bloomberg an die Agentic AI Foundation gespendet wird. In derselben Ankündigung erklärte Anthropic, dass MCP mehr als 10.000 aktive öffentliche Server hatte und von Produkten wie ChatGPT, Cursor, Gemini, Microsoft Copilot und VS Code übernommen worden war. Das ist von Bedeutung, weil es MCP von einer interessanten Idee in einen Vertriebskanal verwandelt.
Für Python-Entwickler ist der Zeitpunkt besonders günstig. Die offizielle SDK-Seite listet Python als Tier-1-SDK, was auf ein starkes Wartungsengagement und Feature-Vollständigkeit hinweist. Mit anderen Worten: Der Python-MCP-Stack ist kein spekulatives Keyword mehr. Er entspricht einer Toolchain, die bereits über offizielle Dokumentation, ein aktives SDK und klare Implementierungsmuster verfügt.
Was MCP Python-Entwicklern tatsächlich bietet
Am einfachsten lässt sich MCP so verstehen: Es standardisiert die Grenze zwischen einer KI-Anwendung und dem Kontext oder den Aktionen, die sie nutzen kann.
Das offizielle Python-SDK beschreibt drei zentrale Server-Bausteine:
- tools für Aktionen, die das Modell aufrufen kann
- resources für schreibgeschützten Kontext, den die Anwendung laden kann
- prompts für wiederverwendbare Interaktionsvorlagen
Diese Unterscheidung ist wichtig.
Tools
Tools sind der aktive Teil deiner Integration. Sie können Code ausführen, APIs aufrufen, Daten schreiben oder Seiteneffekte auslösen. Wenn dein Assistent ein Ticket erstellen, eine Wetter-API abfragen oder einen Job starten muss, gehört das in ein Tool.
Resources
Resources sind der passive Teil. Sie verhalten sich eher wie GET-Endpunkte in einer traditionellen API. Sie stellen nützlichen Kontext wie Dokumentation, Konfiguration oder Referenzdaten bereit, ohne etwas zu verändern.
Prompts
Prompts ermöglichen es dir, wiederverwendbare Anweisungen oder Interaktionsmuster zu bündeln, damit Clients sie strukturiert aufrufen können.
Diese Trennung ist der eigentliche Wert. Vor MCP packten viele Teams alles in ein überdimensioniertes Tool-Schema oder allein in Prompt-Engineering. Mit diesem Protokoll wird die Architektur leichter nachvollziehbar und über Clients hinweg leichter wiederverwendbar.
Aus meiner Erfahrung beim Einsatz von Tool-Calling-Mustern bei Codiste hätte uns diese Unterscheidung zwischen tools und resources erhebliche Refactoring-Zeit erspart. Als ich ein Document-AI-System mit feinabgestimmten Transformern baute, stellten wir das Parsen von Dokumenten zunächst sowohl als Aktion als auch als Datenquelle über dieselbe Schnittstelle bereit, was Verwirrung darüber stiftete, wann das Modell es aufrufen sollte und wann der Kontext vorgeladen werden sollte. Eine Trennung auf Protokollebene, wie sie MCP erzwingt, hätte das vollständig verhindert.
Baue zuerst einen kleinen MCP-Server
Der Schnellstart des offiziellen Python-SDK verwendet FastMCP, was der richtige Ausgangspunkt ist. Es hält Protokolldetails aus dem Weg, sodass du dich auf die eigentliche Fähigkeit konzentrieren kannst, die du bereitstellen möchtest.
Installiere es mit uv oder pip:
1
uv add "mcp[cli]"
oder:
1
pip install "mcp[cli]"
Beginne dann mit einem minimalen Server:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("Demo", json_response=True)
@mcp.tool()
def add(a: int, b: int) -> int:
"""Add two numbers."""
return a + b
@mcp.resource("greeting://{name}")
def greeting(name: str) -> str:
"""Return a greeting resource."""
return f"Hello, {name}!"
@mcp.prompt()
def greet_user(name: str) -> str:
return f"Write a friendly greeting for {name}."
if __name__ == "__main__":
mcp.run(transport="streamable-http")
Dieses winzige Beispiel lehrt das Modell, dem du bei fast jedem echten Server folgen solltest:
- die Fähigkeit definieren
- sie als Tool, Resource oder Prompt klassifizieren
- den Server mit einem Standard-Transport ausführen
- ihn aus einer Host-Anwendung oder einem Inspector verbinden
Das ist der praktische Keyword-Blickwinkel, der Model Context Protocol Python lohnenswert macht, ins Visier zu nehmen. Suchende wollen in der Regel keinen Protokoll-Aufsatz. Sie wollen einen ersten funktionierenden Server, den sie noch heute anpassen können.
Wann MCP besser ist als selbstgebauter Tool-Klebstoff
Wenn du nur einen privaten Helfer für eine App brauchst, kann ein direkter SDK-Aufruf ausreichen. Aber MCP beginnt zu gewinnen, sobald Wiederverwendung und Interoperabilität wichtig werden.
Verwende MCP, wenn:
- dieselbe Fähigkeit über mehrere KI-Clients hinweg funktionieren soll
- du einen sauberen Vertrag zwischen deiner App und deinen Tools willst
- dein Team tools, resources und prompts klar getrennt halten muss
- du erwartest, dass die Integrationsfläche im Laufe der Zeit wächst
Vermeide Überengineering, wenn:
- du einen Wegwerf-Prototypen testest
- die Logik eng an eine einzige App gekoppelt ist und nicht wiederverwendet wird
- du noch nicht weißt, ob die Fähigkeit eine formale Schnittstelle verdient
Die zentrale Erkenntnis ist, dass es bei MCP nicht nur um Modellzugriff geht. Es geht darum, Kontext und Aktionen so zu verpacken, dass andere Clients sie verstehen können. Das ist eine stärkere langfristige Geschichte als das wiederholte Schreiben einmaliger Function-Calling-Wrapper. Du könntest zum Beispiel ein RAG-System als MCP-Resource bereitstellen, sodass jeder Agent deine Wissensbasis abfragen kann.
Best Practices für einen produktionsfreundlichen Start
Das offizielle SDK-README und die Server-Konzept-Dokumentation verweisen auf einige Gewohnheiten, die es sich lohnt, früh anzunehmen.
Halte Tools eng gefasst
Erstelle nicht ein einziges Tool namens do_everything. Kleinere Tools sind für Modelle leichter richtig auszuwählen und für dich leichter zu testen. Als ich KI-Agenten-Workflows für die Bildsegmentierung mit ControlNet baute, lernte ich das auf die harte Tour – ein breites „process_image”-Tool verursachte ständiges Fehlrouting, während die Aufteilung in „segment_image”, „apply_controlnet” und „postprocess_output” dem Modell klare Entscheidungsgrenzen gab.
Lege schreibgeschützte Daten in Resources ab
Wenn etwas als Kontext geladen und nicht als Aktion ausgeführt werden soll, stelle es als Resource bereit. Das hält die Semantik klar.
Verwende Kontext nur dort, wo er hilft
Das Python-SDK unterstützt Kontextinjektion für Tools, einschließlich Fortschrittsberichten und Zugriff auf Lifespan-verwaltete Ressourcen. Das ist mächtig, aber du brauchst es nicht für jeden Endpunkt.
Beginne mit einem Transport und einem Client
Das SDK unterstützt Transporte wie stdio, SSE und Streamable HTTP. Wähle einen Weg, beweise den Workflow und erweitere dann. Das OpenAI Agents SDK ist ein Client, der gut mit MCP-Servern funktioniert.
Teste mit Inspector-artigem Tooling
Der Schnellstart verweist ausdrücklich auf den MCP Inspector als Möglichkeit, deinen Server zu testen, bevor du ihn in eine vollständige Host-Anwendung einbindest. Das ist eine gute Gewohnheit, weil sie Protokollprobleme von Produktproblemen isoliert.
Fazit
Der Grund, warum Model Context Protocol Python gerade jetzt echten SEO-Wert hat, ist einfach: Es kombiniert Trend-Momentum mit unmittelbarer Umsetzungsabsicht. Entwickler hören in großen KI-Produkten von MCP und suchen dann nach dem schnellsten Python-Weg, es selbst zu nutzen.
Wenn das dein Ziel ist, beginne nicht mit einer vollständigen Agentenplattform. Beginne mit einem nützlichen MCP-Server innerhalb eines Python-Projekts, das du bereits verstehst. Stelle ein kleines Tool bereit, füge eine Resource hinzu, teste es mit dem Inspector und verbinde es mit dem Client, den du tatsächlich verwendest.
Dieser Workflow lehrt das Protokoll schneller, als abstraktes Lesen es je könnte. Sobald es funktioniert, kannst du von einem einzelnen lokalen Server zu einer wiederverwendbaren Schnittstelle für interne Tools, Dokumentationssysteme, Support-Workflows oder Entwickler-Automatisierung wachsen.
Wenn du diese Woche einen konkreten nächsten Schritt willst, baue einen winzigen MCP-Server rund um eine Aufgabe, die du bereits manuell wiederholst. Das ist meist der kürzeste Weg von der Neugier zu etwas wirklich Nützlichem.
Verwandte Beiträge
- OpenAI Agents SDK Python Tutorial - Baue Multi-Agenten-Workflows, die MCP-Tools und -Resources nutzen
- KI-Agenten mit Python erstellen - Verstehe die Agentenschleife, die Tool-Nutzung und die Speichermuster, die MCP standardisiert
- RAG mit Python: Retrieval-Augmented Generation - Baue ein Wissensabrufsystem, das du als MCP-Resource bereitstellen kannst
Quellen
Machine Learning Engineer at Codiste, specializing in Generative AI, NLP, and Computer Vision. Building production AI systems with Python.