Model Context Protocol

Tools einfach intelligent?

von Robert Jeutter

12.06.2025

Die bisherigen LLM Werkzeuge

Beispiel Microsoft Copilot

Verfügbar in Office, Windows, GitHub Copilot etc.
Integration oft monolithisch und proprietär
Hoher Entwicklungsaufwand, Integration noch im Fluss

Anthropic stellt MCP vor (November 2024)

Offenes Protokoll zur Tool-/Datenanbindung für LLMs
Vision: viele Tools über eine einheitliche Schnittstelle verbinden
Erste Roadmap und grundlegende Architektur skizziert

MCP: Motivation und Ziele

Standardisierung der Tool-/Daten-Integration
Vendor-unabhängig (Claude, lokale LLMs, OpenAI, …)
Schutz von Daten und Kontrolle durch Nutzer

MCP-Architektur im Überblick

Rollen: Host ↔ Client ↔ Server
Kommunikation via JSON-RPC 2.0
Transport-Abstraktion: stdio / HTTP-SSE
Initialisierungshandshake: initialize / initialized

Rollen: Host, Client, Server

Host: LLM-Anwendung (z.B. Claude Desktop, Ollama-Host)
Client: Vermittlungsmodul, hält 1:1 Verbindung zu Server
Server: Liefert Tools, Resources, Prompts

MCP-Nachrichtenformat (JSON-RPC 2.0)

Request: {"jsonrpc":"2.0","id":X,"method":"...","params":{...}}
Response: {"jsonrpc":"2.0","id":X,"result":{...}} oder {"jsonrpc":"2.0","id":X,"error":{code,message}}
Notification: {"jsonrpc":"2.0","method":"...","params":{...}}

– Die ID verknüpft Request und Response.
– Beispiel für Request:

{
        "jsonrpc": "2.0",
        "id": 1,
        "method": "tools/list",
        "params": {}
}

– Beispiel für Response (Ergebnisliste):

      {
        "jsonrpc": "2.0",
        "id": 1,
        "result": { "tools": [ … ] }
      }

– Notifications brauchen keine ID, werden als Einbahnkommunikation genutzt.
– JSON-RPC ist unkritisch klein, leichtgewichtig und sprachneutral.

Transport-Schicht: stdio vs. HTTP-SSE

Stdio: Kommunikation über Standard Input/Output (lokaler Prozess)
HTTP + SSE: Server-Sent Events (Server→Client), HTTP POST (Client→Server)
Vorteile stdio: Einfach, kein Netzwerk-Stack nötig
Vorteile SSE: Geeignet für entfernte MCP-Server; Persistent Connection

Konfigurationsgrundlagen (`config.json`)

{"mcpServers": { "sqlite": { "command": "uvx", "args": ["mcp-server-sqlite","--db-path","/path/Car_Database.db"] } }}
command: ausführbares Programm
args: Argument-Liste für den Server-Start
Pfadangaben: Windows (Backslashes \) vs. Unix (Forward-Slash /)

– Beispiel unter Windows:

“command”: “C:\\Users\\data\\Anaconda3\\Scripts\\uvx.exe”, “args”: [“mcp-server-sqlite”,“—db-path”,“C:\\Users\\data\\Car_Database.db”]

– Unix:

“command”: “uvx”, “args”: [“mcp-server-sqlite”,“—db-path”,“/home/user/Car_Database.db”]

– Zusätzliche globale Settings: “globalShortcut”: “Ctrl+Space” für Host-Bedienung.
– Die Konfiguration steuert, welche MCP-Server der Host beim Start lädt.
– Tipp: Nur notwendige Server eintragen, um LLM-Entscheidungen zu fokussieren.

Komponente: Roots (Wurzel-URIs)

Client definiert Fokusbereiche als URI-Liste
Beispiele: file:///home/user/projekt/, https://api.example.com/v1
Zweck: Orientierung, Priorisierung von Operationen, vollständige Übersicht
Runtime-Änderung: notifications/roots/changed

Komponente: Resources (Datenkontext)

Text-Ressourcen: UTF-8 kodierte Texte (z.B. Quelldateien, Logs)
Binary-Ressourcen: Base64-kodierte Daten (z.B. Bilder, PDFs)
API:

resources/list – Metadaten aller verfügbaren Ressourcen
resources/read – Inhalte per URI abfragen

Dynamische URI-Templates z.B. logs://recent?timeframe=1h

– Beispiel: resources/list Response:

      {
        "resources": [
          { "uri":"file:///home/user/projekt/code.py","name":"Code-Datei","mimeType":"text/x-python" },
          { "uri":"logs://recent?timeframe=1h","name":"Letzte Logs","mimeType":"text/plain" }
        ]
      }

– resources/read:

      {
        "contents": [
          { "uri":"file:///home/user/projekt/code.py","text":"def foo(): ..." }
        ]
      }

– Dynamische Templates: Client füllt Parameter ein (z.B. Datum, Zeitfenster).
– Live-Updates:

resources/subscribe → Notifications bei Änderung
User kann dann neue Inhalte abrufen oder unsubscribe

– Hinweis: Ressourcen müssen vom Nutzer ausgewählt werden, damit LLM sie sehen kann (Privacy).

Komponente: Prompts (vordefinierte Workflows)

Wiederverwendbare Prompt-Vorlagen mit Argumenten
Discovery: prompts/list
Verwendung: prompts/get mit Argumenten (Parameter)
Beispiele:

“analyze-code” mit Parameter language
”summarize-logs” mit timeframe und fileUri

– prompts/list liefert:

      {
        "prompts": [
          { "name":"analyze-code","description":"Code analysieren","arguments":[{"name":"language","required":true}] },
          { "name":"summarize-logs","description":"Logs zusammenfassen","arguments":[{"name":"timeframe","required":true},{"name":"fileUri","required":true}] }
        ]
      }

– prompts/get: Client setzt Argumentwerte ein, Server liefert fertige Nachrichten:

      {
        "messages":[
          { "role":"user","content":{"type":"text","text":"Analysiere folgenden Code: ..."}} 
        ]
      }

– Multi-Step-Prompts: Zusammenspiel von Text- und Resource-Inhalten möglich.
– UX: Client zeigt Prompt-Auswahl im UI (Dropdown/Slash-Command).
– Vorteil: Konsistente Interaktionen, weniger Tippaufwand.

Komponente: Tools (exekutive Funktionen)

Tools führen Aktionen aus (z.B. execute_command, query_sql)
Definition:

name: eindeutiger Bezeichner
description: Kurzbeschreibung
inputSchema: JSON-Schema für Parameter
annotations: Hinweise (z.B. readOnlyHint, destructiveHint)

Discovery: tools/list
Aufruf: tools/call mit Parameter-Objekt

– Beispiel-Tool-Definition “calculate_sum”:

      {
        "name":"calculate_sum",
        "description":"Addiere zwei Zahlen",
        "inputSchema":{
          "type":"object",
          "properties":{"a":{"type":"number"},"b":{"type":"number"}},
          "required":["a","b"]
        }
      }

– Beispiel-Call:

      {
        "jsonrpc":"2.0",
        "id":5,
        "method":"tools/call",
        "params":{"name":"calculate_sum","arguments":{"a":5,"b":7}}
      }

– Antwort:

      {
        "jsonrpc":"2.0",
        "id":5,
        "result":{"content":[{"type":"text","text":"12"}]}
      }

– Annotationen:

readOnlyHint=true → kein Datenbank-Update
destructiveHint=true → vorsichtig, löscht/ändert Daten
openWorldHint=true → kommuniziert extern (z.B. Web-API)
idempotentHint=true → wiederholbar ohne Seiteneffekt

– Wichtig: Client zeigt dem Nutzer Name + Beschreibung an, bevor Tool ausgeführt wird.

Sicherheitsaspekte bei Tools

Input-Validierung: JSON-Schema prüfen, Sanitizing (Pfad- und SQL-Injection verhindern)
Zugriffsrechte: Sandbox, minimale Privilegien (z.B. nur Lesezugriff auf notwendige Pfade)
Output-Validation: Tool-Ausgaben prüfen, damit kein bösartiger Prompt Injection stattfindet
User-Bestätigung: Vor Ausführen kritischer Tools (z.B. Lösch-Operationen) explizit bestätigen lassen

Komponente: Sampling (Server-initiierte LLM-Abfragen)

Server sendet sampling/createMessage an Client
Client validiert Prompt (Nutzer-Review), führt LLM-Sampling durch
Client sendet generierte Completion per sampling/return zurück
Erlaubt Server, LLM als Subroutine zu nutzen (z.B. Zusammenfassung, Klassifikation)

– Ablauf:

Server → Client: { "method":"sampling/createMessage", "params":{ "messages":[{role:"user",content:{type:"text",text:"Summarize this:"}},…], "maxTokens":100 } }

– Client kann Prompt modifizieren (Filter unerwünschter Inhalte).
– Nach dem Sampling:

      {
        "jsonrpc":"2.0",
        "id":42,
        "result":{ "model":"qwen2.5","role":"assistant","content":{ "type":"text","text":"Kurzzusammenfassung…" } }
      }

– Use-Case: Server erstellt Agent, der TO-DOs in Projekt-Pipeline anhand Logs erkennt.
– Derzeit (Stand Q1 2025) noch nicht in allen Hosts implementiert; in Claude experimentell.
– Sicherheitsaspekte: Keine vertraulichen Daten im Sampling-Prompt ohne Filter.

Zusammenfassung Architektur & Komponenten

Client-Server Rollen & Handshake (initialize, initialized)
Transportschicht: stdio / HTTP-SSE
Wichtige Konzepte:

Roots: Fokus-URIs
Resources: Lesbare Datensätze
Prompts: Vordefinierte Templates
Tools: Exekutive Funktionen
Sampling: Server-initiierte LLM-Nutzung

Übergang: Beispiel-Szenario vorstellen

Ziel: Lokales LLM (Ollama) nutzt MCP, um SQL-Datenbank zu befragen
Warum SQL? Typischer Entwickler-Use-Case, leicht verständlich
Benötigte MCP-Server: SQLite-Server
LLM-Host: Ollama (lokal)

Beispiel: Setup-Übersicht

Komponenten:

Ollama: Lokaler LLM-Host (z.B. Qwen-2.5)
SQLite-MCP-Server: Service „mcp-server-sqlite“
config.json: Verknüpfung beider

Ablauf:

Host startet Ollama-LLM und MCP-Client
MCP-Client verbindet zu SQLite-Server
LLM kann via tools/call SQL-Queries absetzen

Beispiel: `config.json` (Detailliert)

{
  "mcpServers": {
    "sqlite": {
      "command": "uvx",
      "args": [
        "mcp-server-sqlite",
        "--db-path",
        "/pfad/Car_Database.db"
      ]
    }
  }
}

command: ausführbares Programm (uvx für MCP-Server)
args: Argumente, hier der Server-Name + Datenbankpfad
Pfadangaben: bei Windows Doppelslashes, bei Unix einfacher Pfad

– Windows-Beispiel:

{
  "mcpServers": {
    "sqlite": {
      "command": "C:\\Users\\data\\Anaconda3\\Scripts\\uvx.exe",
      "args": [
        "mcp-server-sqlite",
        "--db-path",
        "C:\\Users\\data\\OneDrive\\Desktop\\Car_Database.db"
      ]
    }
  }
}

– Unix:

      {
  "mcpServers": {
    "sqlite": {
      "command": "uvx",
      "args": ["mcp-server-sqlite","--db-path","/home/user/Car_Database.db"]
    }
  }
}

– Tipp: Nur das notwendige Minimum konfigurieren, damit LLM nicht zu viele Tools sieht.
– Bei mehreren Servern: einfach weitere Einträge unter “mcpServers” ergänzen.

Beispiel: SQLite-MCP-Server Übersicht

Tool: “execute_sql” oder “query”
InputSchema:

{"type":"object","properties":{"sql":{"type":"string"}},"required":["sql"]}

Output:

Tabellarische Daten als JSON/Text

– Grober Pseudocode des SQLite-Servers:

server.setRequestHandler(ListToolsRequestSchema, async () => {
  return {
    tools: [{
      name: "execute_sql",
      description: "SQL-Query ausführen",
      inputSchema: {
        type: "object",
        properties: { sql: { type: "string" } },
        required: ["sql"]
      }
    }]
  };
});

server.setRequestHandler(CallToolRequestSchema, async (request) => {
if (request.params.name === "execute\_sql") {
const { sql } = request.params.arguments;
const result = await db.execute(sql);
return { content: \[{ type: "text", text: formatTable(result) }] };
}
throw new Error("Tool nicht gefunden");
});

– Intern: Öffnen der SQLite-DB, Ausführung der Query, Serialisieren des Ergebnisses. – Fehlerbehandlung: Bei Syntaxfehler isError=true setzen und Fehlertext zurückgeben.

Beispiel: Ollama als Host-Client

Kommando:

mcphost -m ollama:qwen2.5 —config /pfad/config.json

Ollama lädt Modell qwen2.5 lokal
MCP-Client startet automatisch den SQLite-Server
Host verbindet LLM und MCP-Client

Beispiel: Interaction Flow

1. Nutzer: „Wie viele Einträge aus Baujahr 2015?“
2. LLM generiert Tool-Call:

{
  "jsonrpc":"2.0",
  "id":101,
  "method":"tools/call",
  "params":{
    "name":"execute_sql",
    "arguments":{"sql":"SELECT COUNT(*) FROM Cars WHERE year=2015"}
  }
}

3. Client leitet Request an SQLite-Server weiter
4. Server führt Query, liefert z.B.: {"content":[{"type":"text","text":"42"}]}
5. LLM baut finale Antwort: „42 Autos aus 2015.“

Beispiel: Detaillierter Tool-Call (JSON)

JSON-RPC-Request:

{
  "jsonrpc": "2.0",
  "id": 101,
  "method": "tools/call",
  "params": {
    "name": "execute_sql",
    "arguments": {
      "sql": "SELECT * FROM Cars LIMIT 5"
    }
  }
}

JSON-RPC-Response:

{
  "jsonrpc": "2.0",
  "id": 101,
  "result": {
    "content": [
      { "type": "text", "text": "id | model | year\n1  | Civic  | 2015\n2  | Corolla| 2016\n…" }
    ]
  }
}

– Erklärung, wie das LLM diese tabellarischen Daten weiterverarbeitet:
– Option 1: LLM gibt Rohtext zurück
– Option 2: LLM formatiert Antwort in Fließtext
– Hinweis: Bei großen Ergebnismengen use-casebedingt nur erste 5-10 Zeilen abrufen
– Error-Fall:

{
  "jsonrpc":"2.0",
  "id":101,
  "result":{ "isError": true, "content":[{"type":"text","text":"SQL-Syntaxfehler"}] }
}

– LLM erkennt isError und antwortet: „Bitte korrigiere die Query…“.

Beispiel: Demo-Outline / Code-Ausschnitte

Host-Pseudocode (TypeScript):

const client = new MCPClient("sqlite");
async function queryCars() {
  const response = await client.callTool("execute_sql", {
    sql: "SELECT COUNT(*) FROM Cars WHERE year=2015"
  });
  console.log("Anzahl:", response.content[0].text);
}
queryCars();

LLM-Antwort (Beispiel): „In der Datenbank sind 42 Autos des Baujahres 2015.“
Link zum vollständigen Beispielcode-Repo (GitHub)

Zusammenfassung des Beispiels

Lokaler SQL-Server + Ollama = Umgebung eingerichtet
LLM schreibt SQL-Queries und führt sie über MCP aus
Volle Datenkontrolle lokal, keine Cloud-Kosten
Erweiterungsmöglichkeiten:

Parameterisierte Queries (z.B. User Input abfragen)
Live-Resource-Subscriptions (automatische Aktualisierung von Tabellen)

Vor- und Nachteile von MCP (Teil 1: Vorteile)

Standardisierung: Einheitliche Schnittstelle zu vielen Tools
Datenkontrolle: Client/Nutzer behält Kontrolle über Zugriff
Flexibilität: Wechsel zwischen LLM-Anbietern (Claude, Ollama, OpenAI)
Skalierbarkeit: M+N Integrationen statt M×N
Community-Ecosystem: Schnell wachsende Zahl an MCP-Servern

Vor- und Nachteile von MCP (Teil 2: Nachteile & Risiken)

Security-Lücken: Keine eingebaute Authentifizierung, potenziell unsichere Tools
Komplexität: Einrichtung (config, Host, mehrere Prozesse)
Reifegrad: Spezifikation noch jung, Breaking Changes möglich
Modell-Limitationen: Kontextfenster, Multi-Step-Logik, Prompt-Injection-Risiken
Host-Abhängigkeit: Noch wenige Hosts (Claude, Ollama, Cursor, …)

Sicherheitsbest Practices & Empfehlungen

TLS/HTTPS: für SSE-Transports
Auth & Access Control: eigene Layer (API-Keys, JWT, OAuth)
Sandboxing: Tools isoliert ausführen (Container, minimaler User)
Output-Validation: Tool-Antworten prüfen und filtern
Logging & Auditing: Alle MCP-Interaktionen protokollieren

Zukunftsaussichten & Roadmap

Geplante Erweiterungen:

Batches & Streaming (HTTP/2, gRPC)
Auth-Spec & Fine-Grained Access Control
Sampling-Unterstützung in mehr Hosts
Standardisiertes Logging/Metrik-API

Erwartete Adoption:

Weitere LLM-Anbieter (OpenAI GPT-4, Anthropic Claude 4, etc.)
Verbreitung bei Enterprise-Produkten (Ideen: GitHub, AWS, Azure)

Zusammenfassung & Takeaways

MCP schafft klare Trennung: LLM ↔ Tools/Daten ↔ Ausführung
Ermöglicht Entwickler-Workflows, bei denen KI direkt in Systemlandschaften eingebunden ist
Aktuell frühe Phase, daher Sorgfalt bei Sicherheit und Setup erforderlich
Große Chancen für vielseitige KI-Assistenz-Szenarien

Q&A / Diskussion

Offene Fragen der Teilnehmer
Brainstorming: Eigene MCP-Use-Cases

Dankeschön & Kontakt

Vielen Dank für Ihre Aufmerksamkeit!
Kontakt & Ressourcen:

Email: vorname.nachname@firma.de
GitHub: github.com/username
Folien-Repo: github.com/username/mcp-praesentation
Beispielcode: github.com/username/mcp-examples

Community-Kanäle:

Discord: discord.gg/mcp
Twitter: @MCPProtocol

Zeit für eure Fragen
& Diskussionen

WieErWill.dev/vcard.vcf

WieErWill.dev