Was ist ein MCP-Server? Neue Standard-Schnittstelle für KI-Tools

Funktionsweise & Workflow

1. Ressourcenregistrierung:
   1. Entwickler laden eine Datei, ein Datenbank-Schema oder eine externe API-Response als Resource beim MCP-Server hoch. Jede Resource erhält eine eindeutige URI (z. B. file:///projekt/konfiguration.yaml oder https://api.example.com/v1/users).
   2. Das Datenformat kann variieren: Textdateien (JSON, YAML, Markdown), Binärdateien (Bilder, PDFs) oder strukturierte Formate (CSV, SQL-Dumps).
2. Anfrage an das LLM:
   1. Wenn ein LLM im Rahmen eines Workflows auf Kontextdaten zugreifen muss (z. B. um einen Codeabschnitt zu prüfen), fordert der MCP-Client die entsprechende Resource über die URI vom Server an.
   2. Der MCP-Server gibt den Inhalt zurück oder streamt ihn, je nach Größe und Format.
3. Cache & Versionierung:
   1. Viele Implementierungen legen abgefragte Ressourcen temporär zwischen (Caching), um wiederholte Lesezugriffe zu beschleunigen.
   2. Versionierte Ressourcen (etwa Versionsstände von Dokumenten) lassen sich durch angehängte Query-Parameter oder durch spezialisierte Endpunkte anfordern.

Beispiel: Analyse eines Config-Files

1. Ein Entwickler möchte, dass das LLM den aktuellen Konfigurationsdateiinhalt analysiert. Er fragt in seiner Client-Applikation nach der Konfigurationsdatei config.yaml.
2. Der MCP-Server liefert den YAML-Inhalt als Text zurück. Das LLM erhält so vollen Zugriff und kann auf dieser Basis direkten Bezug nehmen.

Nutzen für die Praxis

• Zentralisierte Datenbereitstellung: Entwickler müssen keine separaten API-Schnittstellen bauen, um Daten für LLM-Abfragen verfügbar zu machen.
• Konsistente Kontexte: Da alle Daten über denselben MCP-Endpunkt verwaltet werden, entsteht weniger Redundanz und geringere Fehleranfälligkeit.
• Performance-Vorteil durch Caching: Häufig verwendete Ressourcen können schnell ausgeliefert werden, ohne das Backend erneut zu belasten.
• Sicherheit und Zugriffssteuerung: Zugriffskontrollen (ACLs) können serverseitig konfiguriert werden, sodass nur autorisierte Clients bestimmte Ressourcen abrufen dürfen.

2. Prompts: Intelligente Workflows einfach abrufen

Funktionsweise & Workflow

1. Prompt-Registrierung und -Katalog:
   1. Entwickler erstellen auf dem MCP-Server Prompt-Definitionen, z. B.:
   2. Diese Prompts stehen nun allen autorisierten Clients zur Verfügung.

      {
        "name": "explain-code",
        "description": "Erkläre den übergebenen Codeabschnitt in einfacher Sprache",
        "arguments": [
          { "name": "fileUri", "description": "URI der Quellcodedatei", "required": true },
          { "name": "language", "description": "Programmiersprache des Codes", "required": false }
        ]
      }

2. Prompt-Discovery (Discovery):
   1. Der MCP-Client ruft prompts/list auf:

      { "method": "prompts/list" }

   2. Der Server antwortet mit einer Liste aller verfügbaren Prompts inklusive Kurzbeschreibung und Argumentdefinitionen.
3. Prompt-Ausführung (Get / Run):

   1. Der Nutzer wählt einen Prompt aus und sendet eine prompts/get-Anfrage:

      {
        "method": "prompts/get",
        "params": {
          "name": "explain-code",
          "arguments": {
            "fileUri": "file:///projekt/src/main.py",
            "language": "python"
          }
        }
      }

   2. Der MCP-Server liefert die dazugehörigen LLM-Nachrichten (Messages) zurück:

      {
        "messages": [
          { "role": "user", "content": { "type": "text", "text": "Bitte erkläre diesen Python-Code verständlich: ..." } },
          { "role": "user", "content": { "type": "resource", "resource": { "uri": "file:///projekt/src/main.py", "text": "import os\n..." } } }
        ]
      }

   3. Der Client kann diese Nachrichten dann direkt an das LLM weiterleiten.
4. Dynamische Erweiterung und Versionierung:
   1. Prompts lassen sich versionieren, um ältere Templates beizubehalten.
   2. Änderungen an einem Prompt werden über eine prompts.listChanged-Notification an Clients kommuniziert, sodass UI-Elemente (Dropdowns, Kontextmenüs) sich automatisch aktualisieren.

Beispiel: Generierung von Git-Commit Messages

1. Eine Softwareentwicklerin möchte automatisch aussagekräftige Git-Commit-Nachrichten generieren lassen.
2. Sie wählt in der IDE den Prompt git-commit aus und übergibt das aktuelle Diff als Ressource-Argument.
3. Das LLM produziert eine strukturierte Commit-Nachricht, die im nächsten Schritt noch von einem Entwickler verfeinert werden kann.

Nutzen für die Praxis

• Standardisierung und Konsistenz: Durch vordefinierte Prompts arbeiten Teams einheitlich, ohne dass jeder Nutzer eigene LLM-Formulierungen erfinden muss.
• Zeitersparnis & Effizienz: Statt zeitintensiv Prompts manuell zu formulieren, reicht ein simpler Auswahlklick.
• Schnelle Integration in UIs: Prompts können in IDEs, Chat-Interfaces oder Web-Portale eingebunden werden (z. B. via Kontextmenü, Slash-Befehl, Formular).
• Transparenz & Governance: Administratoren können festlegen, welche Prompts für welche Teammitglieder zugänglich sind und so Compliance-Anforderungen erfüllen.

3. Tools: Externe Aktionen orchestrieren

Funktionsweise & Workflow

1. Tool-Registrierung und -Beschreibung:
   1. Entwickler implementieren einen Tool-Endpunkt auf dem MCP-Server, z. B. queryDatabase oder sendEmail.
   2. Die Metadaten (Name, Beschreibung, Parameter, Rückgabewert) werden registriert:

      {
        "name": "queryDatabase",
        "description": "Führt eine SQL-Abfrage auf der Unternehmens-Datenbank aus",
        "arguments": [
          { "name": "sql", "description": "SQL-Abfrage-String", "required": true }
        ]
      }

   3. Dieses Tool steht dem LLM bzw. Client über tools/list zur Verfügung.
2. Tool-Discovery (Discovery):
   1. Über tools/list können Clients herausfinden, welche Tools aktuell vorhanden sind und welche Parameter benötigt werden.
3. Tool-Aufruf (Invocation):

   1. Sendet der Client (bzw. das LLM) eine RPC-Anfrage an tools/call, übergibt er den Tool-Namen und die Argumente:

      {
        "method": "tools/call",
        "params": {
          "name": "queryDatabase",
          "arguments": { "sql": "SELECT COUNT(*) FROM users;" }
        }
      }

   2. Der MCP-Server verarbeitet die Anfrage, führt den Tool-Code aus (z. B. tatsächlich die SQL-Abfrage) und gibt eine strukturierte Antwort zurück:

      {
        "result": {
          "rowCount": 1,
          "rows": [ { "count": 1245 } ]
        }
      }

   3. Dieses Ergebnis kann anschließend als Teil eines LLM-Workflows weiterverwendet werden.

Beispiel: File-System-Operationen

• readFile: Liest eine Datei und gibt ihren Inhalt zurück.
• listDirectory: Gibt alle Dateien eines Verzeichnisses aus.
• writeFile: Schreibt Daten in eine Datei.
• deleteFile: Löscht eine Datei.

Beispiel: Externe API-Aktionen

• sendEmail: Versendet per SMTP oder über externen Dienst eine E-Mail.
• createIssue: Erstellt in GitHub (oder einem anderen Issue-Tracker) ein Ticket.
• invokeLambda: Löst eine AWS Lambda-Funktion aus.

Nutzen für die Praxis

• Modularität & Wiederverwendbarkeit: Tools abstrahieren technische Details in leicht verständliche Bausteine, die in unterschiedlichen Projekten wiederverwendet werden können.
• Sicherheit & Governance: Alle sensiblen Aktionen laufen über den MCP-Server, der Zugriffsrechte, Validierung und Logging zentral kontrolliert.
• Entwicklerfreundlichkeit: Statt komplexe APIs direkt anzubinden, nennt man einfach das Tool mit den erforderlichen Parametern. Das vereinfacht Entwicklungszyklen deutlich.
• LLM-getriebene Automatisierung: Ein LLM kann anhand von Daten analytische Entscheidungen treffen und anschließend Tools aufrufen, um Aktionen (z. B. E-Mail-Versand, Datenspeicherung) automatisch auszuführen.

4. Sampling: Intelligenz on Demand

Funktionsweise & Workflow

1. Sampling-Anfrage erstellen (Server → Client):
   1. Der MCP-Server sendet eine sampling/createMessage-Anfrage mit einem Nachrichtenarray (messages) und optionalen Parametern:

      {
        "method": "sampling/createMessage",
        "params": {
          "messages": [
            { "role": "user", "content": { "type": "text", "text": "Fasse die wichtigsten Punkte dieses Dokuments zusammen." } }
          ],
          "systemPrompt": "Du bist ein präziser Assistent.",
          "includeContext": "thisServer",
          "maxTokens": 150
        }
      }

   2. Das Nachrichtenarray enthält beispielsweise Nutzer-Eingaben sowie Kontext-Informationen aus Ressourcen (z. B. Dateien oder API-Daten).
2. Prüfung und Auswahl durch den Client:
   1. Der Client validiert den Prompt, zeigt ihn gegebenenfalls dem Nutzer zur Freigabe oder Anpassung, und wählt ein geeignetes Modell aus (z. B. „claude-3“).
   2. Optional kann der Nutzer Parameter wie temperature oder stopSequences anpassen, um kontrollierte Ergebnisse zu erhalten.
3. Abwicklung durch das LLM (Client → LLM):
   1. Der Client sendet die finalen Nachrichten an das ausgewählte LLM-API-Endpoint (z. B. OpenAI, Anthropic) und empfängt die fertig generierte Antwort (Completion).
4. Rückgabe an den MCP-Server (Client → Server):

   1. Nachdem die Antwort vorliegt, ruft der Client sampling/completeMessage auf:

      {
        "method": "sampling/completeMessage",
        "params": {
          "model": "cl-3.0",
          "role": "assistant",
          "content": {
            "type": "text",
            "text": "Hier ist die Zusammenfassung: …"
          },
          "stopReason": "endTurn"
        }
      }

   2. Der MCP-Server speichert das Ergebnis und leitet es an den aufrufenden Prozess weiter (z. B. eine UI, einen anderen Microservice).
5. Erweiterte Kontrolle & Sicherheit:
   1. Human-in-the-Loop: Nutzer können vor jeder Sampling-Anfrage manuell prüfen, welche Daten an das LLM gesendet werden.
   2. Datenschutz: Nur die minimal notwendigen Teile aus Ressourcen (“includeContext”: „thisServer“) dürfen weitergeleitet werden.
   3. Logging & Auditing: Alle Sampling-Anfragen und -Antworten lassen sich lückenlos protokollieren, um Compliance-Vorgaben zu erfüllen.

Nutzen für die Praxis

• Flexibilität ohne Serverseitige LLM-Haltung: Der MCP-Server bleibt leichtgewichtig; das eigentliche LLM-Processing passiert dezentral beim Client oder in der Cloud.
• Kostenkontrolle: Dank eindeutiger Parameter (z. B. maxTokens) behalten Entwickler und Entscheider Kosten und Latenz im Blick.
• Skalierbarkeit: Da mehrere Clients unterschiedliche LLM-Instanzen ansprechen können, lässt sich das System horizontal erweitern.
• Erhöhte Sicherheit: Die Inhalte, die an das LLM gehen, können vom Nutzer freigegeben und sensibel gefiltert werden.

5. Roots: Zielgerichtete Datenzugriffe steuern

Roots (Wurzeln) sind im Model Context Protocol Empfehlungen oder Vorgaben, anhand derer der MCP-Server weiß, in welchen übergeordneten Verzeichnissen, APIs oder Datenbereichen er suchen soll. Statt unkontrolliert das gesamte Dateisystem oder alle verfügbaren Datenquellen zu durchsuchen, erhält der Server durch Roots eine klare Strukturierung.

Funktionsweise & Workflow

1. Initiale Root-Definition:
   1. Beim Verbindungsaufbau zwischen Client und MCP-Server sendet der Client ein Array von URIs, z. B.

      {
        "method": "initialize",
        "params": {
          "roots": [
            "file:///home/developer/projekt-frontend",
            "file:///home/developer/projekt-backend",
            "https://api.example.com/v2"
          ]
        }
      }

   2. Der Server speichert diese Roots und nutzt sie als Filter für alle nachfolgenden Operationen.
2. Preferenzen und Filterung:
   1. Wenn der MCP-Server eine Resource-Liste (z. B. alle Dateien eines Projekts) zurückliefern soll, beschränkt er sich standardmäßig auf die Root-Pfade.
   2. Bei der Suche nach Daten oder APIs wird nur innerhalb dieser angegebenen Roots gesucht, um Performance und Relevanz zu optimieren.
3. Dynamische Anpassung:

   1. Roots lassen sich während der Laufzeit verändern

      {
        "method": "rootsChanged",
        "params": {
          "added": ["file:///home/developer/neues-modul"],
          "removed": ["https://api.example.com/v2"]
        }
      }

   2. Daraufhin passt der MCP-Server seine internen Filter an