Claude über MCP an eigene Systeme anbinden

Was ist Model Context Protocol?

Model Context Protocol, abgekürzt MCP, ist ein offener Standard, den Anthropic 2024 veröffentlicht hat. Er beschreibt, wie ein KI-Modell wie Claude strukturiert mit externen Tools und Datenquellen kommunizieren kann. Claude sendet einen Tool-Call mit Parametern, der MCP-Server führt diesen aus und gibt das Ergebnis zurück. So kann Claude eine SQL-Abfrage ausführen, einen REST-Endpunkt aufrufen oder eine Datei lesen, ohne dass der Nutzer die Rohdaten selbst liefern muss.

Das Protokoll läuft über einen separaten Server-Prozess. Dieser Server läuft lokal neben Claude Desktop oder auf einer Maschine im eigenen Netzwerk, je nach Architektur. Claude kommuniziert mit dem Server über ein standardisiertes JSON-RPC-Interface über stdin/stdout oder über eine SSE-Verbindung. Der MCP-Server übersetzt die Tool-Calls in Aktionen auf Ihrem System.

MCP ist kein Chatbot-Plugin und kein SaaS-Connector. Es ist ein Low-Level-Protokoll, das vollständige Kontrolle darüber gibt, was Claude tun darf und was nicht. Der Server definiert das Schema der verfügbaren Tools: Namen, Parameter und Beschreibungen. Claude entscheidet selbst, welches Tool am besten zur Frage des Nutzers passt.

Wie unterscheidet sich MCP von Function Calling und ChatGPT-Plugins?

OpenAIs Function Calling und ChatGPT-Plugins funktionieren ähnlich, aber es gibt wesentliche Architekturunterschiede:

• ▸MCP ist ein offener Standard. Die Spezifikation ist auf GitHub veröffentlicht und jede Partei kann einen Client oder Server implementieren. Es gibt keinen Vendor-Lock-in an eine bestimmte Cloud-Plattform.
• ▸MCP-Server laufen als eigene Prozesse. Das bedeutet, der Server kann On-Premise laufen, hinter einer Firewall, ohne dass Daten an einen externen Dienst übertragen werden.
• ▸Authentifizierung ist ein erstklassiges Konzept in der MCP-Spezifikation. OAuth 2.1 ist der empfohlene Flow für Server, die über das Netzwerk erreichbar sind. Für lokale Server reicht ein API-Key über Umgebungsvariablen.
• ▸Sowohl Claude Code als auch Claude Desktop sind MCP-Clients. Das bedeutet, ein MCP-Server, den ich baue, funktioniert in Claude Desktop für Endnutzer und in Claude Code für Entwickler.
• ▸Tool-Beschreibungen sind maschinenlesbare Schemas. Claude nutzt diese Schemas, um zu überlegen, welches Tool am besten zu einer Frage passt. Das macht MCP-Integrationen zuverlässiger als hartcodierte Prompts.

ChatGPT-Plugins wurden inzwischen durch GPT Actions ersetzt, die aber nur im OpenAI-Plattform funktionieren. MCP-Server sind in der Spezifikation modell-agnostisch, obwohl Claude derzeit der vollständigste MCP-Client ist.

Was ich mit MCP baue

Der Umfang variiert je nach Projekt. Dies sind die häufigsten MCP-Server-Typen, die ich implementiere:

• ▸Datenbank-Query-MCP-Server: Claude stellt Fragen in natürlicher Sprache, der Server übersetzt diese in SQL und gibt das Ergebnis zurück. Read-Only-Abfragen, mit einer expliziten Allowlist erlaubter Tabellen und Spalten.
• ▸REST-API-MCP-Server: ein Wrapper um Ihre interne oder externe API. Claude kann Endpunkte aufrufen, Parameter befüllen und die Antwort interpretieren. Nützlicher als Dokumentation lesen für Entwickler, die interne Tools nutzen.
• ▸File-System-MCP-Server: kontrollierter Lese- und Schreibzugriff auf Dateien an einem bestimmten Ort. Praktisch für Teams, die Claude mit lokalen Projektdateien arbeiten lassen wollen.
• ▸Internal-Tool-MCP-Server: Anbindung an Unternehmenssoftware ohne öffentliche API. Über einen Headless-Scraper oder internes SDK gebaut, mit Rate-Limiting und Fehlerbehandlung.
• ▸Knowledge-Base-MCP-Server: Vektordatenbank oder Dokumentenspeicher als Tool. Claude sucht relevante Passagen und zitiert die Quelle. Geeignet als Alternative zu RAG-Pipelines, die Sie selbst verwalten wollen.

Für jeden MCP-Server definiere ich das Tool-Schema, die Validierungsschicht, die Fehlerbehandlung und das Logging. Der Server ist vollständig zustandslos oder hat minimalen Zustand: das Protokoll erlaubt das und macht das Deployment einfacher.

Mein Stack und Deployment

Ich schreibe MCP-Server primär in TypeScript mit dem offiziellen MCP TypeScript SDK von Anthropic. Für Data Science oder internen Einsatz manchmal in Python mit dem Python SDK. Die Wahl hängt davon ab, was am besten zu Ihrer vorhandenen Technologie passt.

• ▸TypeScript SDK: typsichere Tool-Definition, automatische Parameter-Validierung über Zod-Schemas und eine starke Developer Experience. Eignet sich gut für REST-API-Wrapper und Datenbankanbindungen.
• ▸Python SDK: praktisch, wenn Ihr internes Tooling bereits in Python geschrieben ist oder wenn Sie mit Data-Science-Bibliotheken arbeiten. Gleiche MCP-Spezifikation, andere Laufzeit.
• ▸Docker-Deployment: der MCP-Server wird in einem Docker-Container verpackt. So ist die Umgebung reproduzierbar und Sie können den Server lokal testen, bevor er in Produktion geht.
• ▸Auth über OAuth 2.1 oder API-Key: für Server, die über ein Netzwerk erreichbar sind, verwende ich OAuth 2.1 mit PKCE. Für lokale Server ist ein API-Key über eine .env-Datei die einfachste Lösung.
• ▸Transport-Layer: stdio für lokale Server, SSE oder HTTP für Server, die aus einem Netzwerk angesprochen werden. Die Wahl hängt vom Client-Typ ab.

Ich liefere den Server als vollständig dokumentiertes Projekt: README mit Setup-Anleitung, Schema-Dokumentation für jedes Tool und eine Konfigurationsdatei, die direkt in die Claude Desktop Config eingetragen wird.

Konkrete Anwendungsfälle

Das sind Szenarien, in denen MCP-Integrationen direkt Mehrwert schaffen:

• ▸Claude Desktop verbunden mit Ihrer internen Datenbank: Mitarbeiter stellen Fragen wie wie viele offene Bestellungen haben wir heute und erhalten die Antwort direkt aus dem System, ohne einen Report exportieren zu müssen.
• ▸Claude Code verbunden mit internem Tooling: Entwickler können über Claude Code Befehle auf internen Systemen ausführen, Dokumentation abrufen oder Deploys starten, ohne die IDE zu wechseln.
• ▸Interner Support-Assistent: Claude verbunden mit einer Wissensbasis aus Produkten, Verfahren oder FAQ. Mitarbeiter fragen in normaler Sprache, Claude findet die relevante Passage und gibt eine Antwort mit Quellenangabe.
• ▸Automatisiertes Reporting: Claude fragt Daten über einen MCP-Server ab, aggregiert diese und schreibt einen Bericht im gewünschten Format. Kann periodisch über einen Scheduler ausgeführt werden.
• ▸Entwicklungsumgebung mit interner API: Entwickler, die mit Ihrer internen API experimentieren wollen, ohne die Dokumentation ständig geöffnet zu haben. Claude versteht die Tool-Schemas und schlägt die richtigen Endpunkte vor.

Das gemeinsame Muster ist, dass Claude als Schnittstelle für Systeme dient, die normalerweise ein separates Frontend oder Query-Tool erfordern. Das senkt die Hürde für technische und nicht-technische Nutzer gleichermaßen.

Was ich nicht tue

Es gibt Grenzen bei dem, was ich baue, und die sind bewusst gesetzt:

• ▸Keine MCP-Server ohne Security-Review. Ein MCP-Server, der SQL-Abfragen ohne Allowlist oder Parametrisierung ausführt, ist ein direkter Angriffsvektor. Jeder Server, den ich baue, hat explizite Grenzen für das, was möglich ist.
• ▸Keine öffentlichen MCP-Endpunkte ohne Rate-Limiting und Authentifizierung. Ein MCP-Server, der von außerhalb des Netzwerks ohne Auth erreichbar ist, ist kein MCP-Server, das ist eine offene API. Das baue ich nicht.
• ▸Keine MCP-Integrationen ohne klaren Business Case. Wenn ein einfacher Zapier-Workflow oder eine direkte API-Integration das Problem besser löst, sage ich das.
• ▸Keine Schreibzugriffe auf Produktionsdatenbanken ohne expliziten Bestätigungsschritt. Read-Only ist der Standard. Schreibzugriffe erfordern ein Tool-Schema mit Bestätigungsparameter und Logging.
• ▸Keine MCP-Server für Systeme, zu denen ich keinen Zugang habe oder bekomme. Ich benötige API-Dokumentation oder direkten Zugang zum System, um einen guten Server zu bauen.

Security ist bei MCP kein Nachgedanke. Das Protokoll gibt Claude direkten Zugang zu Systemen, und das erfordert, dass jede Tool-Definition sorgfältig durchdacht ist.

Weiterlesen