MCP-Server und Claude: fünf Fragen, die wir vor der ersten Codezeile beantworten

MCP (Model Context Protocol) taucht in letzter Zeit in jedem AI-Newsletter auf. Der Grund ist fair — Anthropic hat einen Standard für etwas geliefert, das jedes Team ohnehin irgendwie zusammengeschustert hat: einen kontrollierten Weg zwischen einem Modell und den Daten oder Aktionen eines fremden Systems. Sobald ein Standard da ist, erscheinen Libraries, Tutorials, und jeder mit einem Claude-API-Key baut einen Proof of Concept.

Was wir immer wieder sehen: 80 % dieser Prototypen verwechseln „Claude sieht meine Datenbank“ mit „Claude macht mit meiner Datenbank etwas Nützliches“. Dazwischen liegt eine Kluft. Die Verkabelung ist trivial. Die Nützlichkeit nicht.

In den letzten drei Monaten haben wir bei Codedock mehrere interne MCP-Prototypen gebaut — für die Arbeit mit Projektdaten, für unsere eigenen operativen Systeme und einen Proof of Concept mit einem konkreten Kunden. Die erste produktive Bereitstellung geht in den kommenden Wochen live. Aus diesen Prototypen hat sich eine Methodik herauskristallisiert: fünf Fragen, die wir beantworten, bevor eine Zeile MCP-Server-Code entsteht.

1. Für wen genau bauen wir das?

„Für unsere User“ ist eine unbrauchbare Antwort. Ein MCP-Server ohne konkretes Workflow entwirft sich nicht selbst — Sie reichen Claude hundert Tools und es weiß nicht, welches wofür gedacht ist.

Die erste Frage lautet immer: Benennen Sie drei konkrete Aufgaben, die die KI lösen soll. Nicht „ein Assistent für unser Produkt“, sondern „fasst ein Kundengespräch zusammen und schlägt einen Follow-up vor“ oder „macht aus einer CRM-Notiz einen Angebots-Draft in Vorlage X“. Je konkreter der Use Case, desto mehr entwerfen sich die Tools von selbst.

Heuristik, zu der wir gekommen sind: Wenn Sie keinen Beispieldialog in drei Turns aufschreiben können, kennen Sie den Use Case nicht gut genug, um einen guten MCP-Server zu entwerfen. Erst der Dialog. Dann das Schema.

2. Lesen zuerst, Schreiben zuletzt

Das MCP-Protokoll unterscheidet resources (Dinge zum Lesen) und tools (Aktionen, typischerweise inklusive Schreibzugriffen). Die Versuchung ist, beides sofort zu mappen. Lassen Sie es.

Regel: Am Anfang nur Resources exponieren. Lassen Sie Claude damit spielen. Beobachten Sie, wonach es sucht, was ihm fehlt, wo es strauchelt. Erst dann Tools hinzufügen — und diese nur in einem Modus, in dem Human-in-the-loop-Freigabe Pflicht ist.

Der Grund ist trivial: LLM-Guardrails versagen. Prompt Injection, unklare Anweisung, halluzinierte Gesprächsabzweigung — jedes davon bringt das Modell dazu, ein destruktives Tool zum falschen Zeitpunkt aufzurufen. Eine Read-only-Oberfläche riskiert schlimmstenfalls, dass das Modell etwas liest, was es nicht sollte. Eine Write-Oberfläche bedeutet, dass die E-Mail an die falsche Person geht, die Rechnung unsinnig ausgestellt oder ein Datenbankdatensatz gelöscht wird.

3. Granularität der Tools

Diese Frage stellen die Leute nicht und laufen dann hinein. Sie haben zwei Extreme:

• Zu feinkörnig: hundert Tools wie getUser, getUserOrders, getOrderLineItems, … — das Modell verliert sich in der Entscheidung, der Schema-Prompt sprengt das Kontextfenster, und die Latenz addiert sich mit jedem Tool-Hop.
• Zu grobkörnig: ein einziges Tool runQuery(sql) — das Modell hat sämtliche Macht und null Kontrolle, weil SQL Turing-complete ist.

Die funktionierende Mitte ist thematisch: ein Tool pro User Intent, nicht pro Datenbanktabelle. getCustomerProfileForSupport schlägt vier Tools, die ein Support-Agent aneinanderreihen muss. searchOrders(filters) schlägt fünf pro-Filter-Varianten.

Arbeitsheuristik: Wenn Ihr bester Agent dieselbe Sequenz von drei Calls fünfmal am Tag durchläuft, steckt dort ein Tool, das auf einen Namen wartet. Fassen Sie sie zusammen.

4. Trust Boundary und Scope

Jeder MCP-Server ist eine neue Authentifizierungsgrenze. Klingt offensichtlich; wird in der Praxis schlecht gemacht. Typisches Versagen: der MCP-Server läuft mit einem Service-Account mit Admin-Scope. Claude ruft ein Tool „im Namen von User X“ auf, aber der Scope ist faktisch das ganze System.

Die richtige Frage: Welchen Nutzer impersoniert der MCP-Server, und welchen Scope trägt er in diesem Moment? In der Produktion muss der MCP-Server die Identität des Aufrufers übernehmen — OAuth-Flow, Session-Token, per-Tenant-API-Key — und Tool Calls werden gegen diese Identität validiert, nicht gegen den Service-Account.

Das Zweite, was übersehen wird: Audit Trail. Jeder Tool Call braucht eine Logzeile mit Wer-Wann-Was-Warum (Tool-Name, Argumente, Aufrufer-Identität, Conversation-ID). Wenn in sechs Monaten die Frage kommt „wer hat Rechnung #12345 gelöscht“, sollten Sie die Antwort in weniger als zwei Tagen haben.

5. Woran erkennen wir, dass es funktioniert?

Die letzte Frage — und paradoxerweise die am stärksten unterschätzte. Ein MCP-Server ist kein REST-API mit deterministischer Semantik. Jeder Tool Call hängt davon ab, wie das Modell die Nutzer-Nachricht interpretiert hat. „Funktioniert“ lässt sich nicht an Unit-Tests ablesen.

Was wir messen (oder zumindest messen wollen, bevor es in Produktion geht):

• Tool Selection Accuracy: ein verfolgtes Set von User-Prompts, bei denen wir wissen, welches Tool der richtige Call war. Anteil korrekter Auswahlen über Prompt- und Modell-Versionen hinweg.
• Latenz pro Turn: Tokens sind nicht umsonst, und jeder Tool-Hop verlängert die Antwort. Ein Budget pro Conversation ist die Größe, die man setzen und überwachen muss.
• Sicheres Scheitern: Was passiert, wenn das Modell Unsinn-Input bekommt? Gibt es eine Fehlermeldung zurück oder fängt es an, Tool Calls zu halluzinieren? Letzteres ist ein Bug.
• Menschliche Kontrolle: Wieviel Prozent der Schreibvorgänge wurden freigegeben vs. abgelehnt? Bei 100 % Freigabe ist Ihr Human-in-the-loop wahrscheinlich Theater.

Ohne ein Eval-Set unterscheidet sich Ihr MCP-Server nicht von jedem AI-Demo, das irgendwo vorgeführt wurde und danach ein Jahr lang geschwiegen hat.

Eine Präzedenzfrage: bauen wir überhaupt noch Admin-UIs?

Eine Frage, die diese Arbeit an die Oberfläche bringt: Wenn ein MCP-Server die Workflows abdeckt, die sonst ein In-App-Admin-Dashboard übernehmen würde — lohnt es sich überhaupt noch, das Admin-UI für Menschen zu bauen?

Ehrliche Antwort: Wir stellen diese Frage auf jedem Projekt neu. Admin-UIs sind ergonomisch stark bei Aufgaben, die ein Mensch hundertmal pro Woche macht — Bulk-Operationen, visuelle Tabellen, schnelles Filtern im Vorbeigehen. LLMs verlieren diese Ergonomie. Sie glänzen dort, wo die Aufgabe seltener ist, aber breiten Kontext verlangt (schreibe eine Zusammenfassung, bereite einen Draft vor, verbinde drei Systeme, erkläre einen ungewöhnlichen Zustand).

In der Praxis: Für einige Kategorien interner Operationen — Reporting, Kunden-Onboarding, Incident Response, Pro-Ticket-Datenanalyse — schlägt MCP + Chat ein Custom React-Admin. Für andere (Daily Ops, hochvolumige manuelle Schritte, Metrics-Dashboards) gilt das Gegenteil. Wir entscheiden nach Häufigkeit und Aufgaben-Ergonomie, nicht danach, was gerade trendy ist.

Eine Falle passt auf: Ein Chat-Interface nimmt die direkte Sichtbarkeit des Systemzustands weg. Ein klassisches Admin-UI zeigt Ihnen „das existiert“. Ein Chat zeigt nur das, wonach Sie gefragt haben. Wenn Chat der einzige Weg ins System ist, fallen Teile des Systemzustands leise aus dem operativen Bewusstsein — bis jemand darauf hinweist. Im Design wollen Sie dann, dass der MCP-Server auch „Übersichts-“Resources bereitstellt, die Claude im Rahmen eines täglichen Routineprompts durchgeht — und Anomalien von sich aus meldet.

Wie geht es weiter

Bei Codedock baut unsere aktuelle Pipeline genau darauf auf — die Prototypen laufen intern, die Methodik formt sich aus einzelnen Erkenntnissen, und das erste produktive Kundenprojekt startet in den nächsten Wochen. Es ist domänenspezifisch (Details lasse ich hier beiseite), aber wir hatten alle fünf Fragen beantwortet, bevor wir eine Zeile Server-Code geschrieben haben.

Wenn Sie MCP im Enterprise-Kontext abwägen, ein Satz zum Mitnehmen: In 80 % der Fälle gewinnt ein einfaches Tool rund um ein Workflow gegen einen generischen „AI sieht alles“-Server. Die zweite Kategorie ist im Demo beeindruckend und in der Produktion unbrauchbar.