Die erste Hälfte von 2025 habe ich damit verbracht, Custom-API-Wrapper zu schreiben, damit KI-Modelle mit unseren internen Tools reden können. Ein Wrapper für die Marketing-API, einer für das Sales Dashboard, einer für die JetBrains Marketplace Stats, zwei weitere für Deployment-Skripte. Jeder Wrapper war ein bisschen anders. Jeder ging kaputt, wenn sich die API des Tools änderte. Und jedes Mal, wenn ich einen neuen KI-Client anbinden wollte, musste ich die Integration nochmal schreiben.
Dann hat Anthropic das Model Context Protocol veröffentlicht und ich habe alle fünf an einem Wochenende umgeschrieben.
MCP ist ein Standard, um KI-Modelle mit Tools zu verbinden. Man kann es sich vorstellen wie LSP - Language Server Protocol - nur dass man statt einem Editor Zugriff auf einen Compiler einem KI-Modell Zugriff auf Datenbanken, APIs, Dateisysteme gibt, alles was man in eine Funktion packen kann. Einen Server schreiben, und jeder MCP-kompatible Client kann ihn nutzen. Claude Code, ein JetBrains-Plugin, ein eigenes Automatisierungsskript - gleicher Server, keine Änderungen.
Wie ein minimaler Server aussieht
from mcp.server import Server
from mcp.types import TextContent
server = Server("my-tools")
@server.tool()
async def get_weather(city: str) -> list[TextContent]:
"""Get current weather for a city."""
data = await fetch_weather_api(city)
return [TextContent(
type="text",
text=f"Weather in {city}: {data['temp']}C, {data['condition']}"
)]
if __name__ == "__main__":
server.run()
Der Decorator registriert die Funktion. Die Type Hints werden zum Input-Schema. Der Docstring wird zur Beschreibung. Das SDK übernimmt Transport und Error Handling. Das war es wirklich.
Um ihn mit Claude Code zu verbinden, fügt man ihn in .mcp.json ein:
{
"mcpServers": {
"my-tools": {
"command": "python",
"args": ["path/to/server.py"]
}
}
}
Client neu starten, und die Tools tauchen automatisch auf.
Was ich nach mehreren davon gelernt habe
Zusammengehörige Tools in einen Server packen. Unser Marketing-Server hat 22 Tools - Queue-Management, Content-Validierung, Channel-Publishing. Ein Prozess, eine Verbindung, eine Stelle zum Warten. Die Versuchung ist groß, pro Tool einen Server zu bauen, aber das sind viele Prozesse ohne Grund.
Strukturierte Daten zurückgeben, keinen Fließtext. Das Modell entscheidet, wie es die Daten präsentiert. Der Server liefert sauberes JSON oder strukturierten Text. Ich habe am Anfang den Fehler gemacht, ein Tool eine formatierte Zusammenfassung zurückgeben zu lassen, und dann hat das Modell sie nochmal umformatiert, und das Ergebnis war schlechter, als wenn ich einfach die Rohdaten geliefert hätte.
Rate-Limiting auf der Server-Seite. Modelle sind enthusiastisch. Sie rufen Tools in schneller Folge auf, wenn man sie lässt. Ich habe einen einfachen Sliding-Window-Rate-Limiter zu unserem Marketing-Server hinzugefügt, nachdem er versucht hat, 40 Posts in 90 Sekunden zu veröffentlichen. Gut, dass ich an dem Tag den Shadow Mode an hatte.
Fehler als Text behandeln, nicht als Exceptions. Das Modell kann mit “API returned 429, try again in 60 seconds” viel besser umgehen als mit einem Stack Trace. Fehlermeldungen als Content zurückgeben und das Modell entscheiden lassen, was es damit macht.
Wo wir gelandet sind
Slaide hat einen MCP-Server und einen Agent Skill, sodass jeder KI-Agent eine Präsentation erstellen kann, indem er eine Textdatei schreibt. Smart Inference nutzt MCP für Routing-Transparenz. Unser Marketing-System läuft mit 22 Tools über einen Server.
Ehrlich gesagt: MCP ist noch jung. Das TypeScript-SDK ist weiter als das Python-SDK. Die Dokumentation ist stellenweise lückenhaft. Und nicht jeder KI-Client unterstützt es bisher, obwohl die Adoption schnell vorangeht.
Ich habe ein Wochenende gebraucht, um fünf Integrationen umzuschreiben. Diese fünf hatten mich Monate gekostet. Manchmal kommen Standards genau zum richtigen Zeitpunkt.