Woche 7 – MCP (einem Agenten seine eigenen Tools geben, der Standardweg)

Teil meiner Reise, um meine Automatisierungsfähigkeiten zu vertiefen und das Feld bewegt sich in Richtung KI. Diese Woche dreht sich alles um Model Context Protocol (MCP) – statt Daten in einen Prompt einzufügen, erhält das LLM eine kleine Auswahl an Tools und entscheidet selbst, welche davon es in welcher Reihenfolge aufruft, um eine Frage zu beantworten.

Warum diese Woche wichtig ist: Das Festverdrahten von Daten in einem Prompt skaliert nicht über eine Demo hinaus. MCP entwickelt sich zum Standard für „hier sind deine Tools und Datenquellen, los geht’s“ – es ist genau das, was ein Agenten in Echtzeit an ein Live-System anschließt, statt nur an einen Schnappschuss.

Die Architektur

[client.py asks a question]
            |
            v
[Claude sees 3 tool definitions — no invoice data in the prompt]
            |  decides which tools to call, with what arguments
            v
[MCP server (server.py): list_invoices / get_invoice / get_purchase_order]
            |  returns live data over stdio
            v
[Claude reasons over the results and answers]

Kontinuität: In Woche 2 extrahierten und eine Rechnung aus einem Dokument. In Woche 6 gehen wir Probleme an, wie man mit einer Rechnungsausnahme umgehen soll, auf Grundlage von Daten, die der Bot bereits zur Hand hatte. In dieser Woche leben die Daten selbst hinter einem MCP-Server – ein Agent beschreibt seine eigenen Fakten, statt sie fertig geliefert zu bekommen. Kombinierst du das mit dem richtliniengeschützten Entscheidungsservice aus Woche 6, ergibt sich daraus das Portfolio-Projekt #4 auf der Roadmap: ein Agent, der Dinge nachschlägt und die Bewertung einer prüfbaren Regel-Schicht überlässt.

Related MCP server: Invoice MCP Server

Was hier ist

1. Ausführen

python -m venv .venv
.venv\Scripts\Activate.ps1
pip install -r requirements.txt
# copy .env.example to .env and paste your key

python src/client.py

client.py startet server.py selbst über stdio (so funktioniert MCP für lokale Tools typischerweise, heißt in der Woche 6 kein HTTP-Port). Beobachte, wie die [MCP tool call: ...]-Zeilen ausgegeben werden, während Claude entscheidet, was er nachschlagen muss.

Führe die Unit-Tests für die Tool-Logik aus (kein API-Schlüssel nötig):

pytest

2. Die zentrale Designidee: Tools + Daten über ein Standardprotokoll

Vor MCP bedeutete „dem Modell ein Tool geben“, für jedes Projekt ein JSON-Schema und eine Verzweigung if/elif von Hand aus zu pflegen. MCP standardisiert das: server.py deklariert die Tools einmal mit @mcp.tool(), und jeder MCP-fähige Client – das client.py dieses Repos, Claude Desktop, oder der Agent eines anderen Teams – kann sie auf demselben Weg entdecken und aufrufen. Genau darum geht es bei „Agenten mit echten Werkzeugen verbinden“: Der Werkzeuganbieter und der Agent müssen nicht von derselben Person geschrieben worden sein.

3. Was ich gelernt habe / Produktionsreife vs. Nein

• MCP trennt wem die Daten gehören von wer über sie nachdenkt – der Server weiß nicht und kümmert sich nicht darum, welches LLM ihn aufruft.

• An der Anderen Wahl des Modells gibt es auch etwas: Das ist Orchestrierung (Entscheiden, welches Tool aufgerufen wird), keine anspruchsvolle Bewertung, also ist ein günstiges/schnelles Modell (claude-haiku-4-5) der richtige Aufruf – Heb dir das Reasoning der Opus-Klasse für die Art von Entscheidung auf, die Woche 6 trifft.

• Nicht produktionsreif: Das „ERP“ ist ein In-Memory-Dictionary, der Server hat keine Authentifizierung und es gibt keine echten MCP-Ressourcen (nur Tools) – eine Produktionsversion würde die Rechnungsergebnisse wahrscheinlich auch als MCP-Ressourcen bereitstellen. (Ab Woche 8.)

Stack

Python · MCP (offizielles Python-SDK) · Claude Visage (claude-haiku-4-5 zum Steuern der Tools) · Anthropic SDK · pytest