MCP (Model Context Protocol) erklärt: Wie konfiguriert man Datenquellen für Ihren AI Agent?

Kurz gesagt: Ihr Agent kann Code schreiben, liest aber keine GitHub Issues, kein DB-Schema und keine internen Docs — oft liegt das Problem nicht am Modell, sondern daran, dass niemand erklärt, woher die Daten kommen. Dieser Artikel beginnt beim MCP-Protokoll: Architekturschichten, die drei Primitiven Tools / Resources / Prompts, stdio vs. HTTP, dann Konfigurationsbeispiele und eine Abnahme-Checkliste für Cursor und Claude Code. Danach können Sie gängige Datenquellen selbst anbinden — ohne Glue-Code für jedes SaaS.

Weiterlesen: Claude Code MCP Setup-Anleitung · 20 MCP Server Empfehlungen · MCP mit minimalen Berechtigungen

Was ist MCP? Welches Problem löst es?

Das Model Context Protocol (MCP) ist ein Ende 2024 von Anthropic veröffentlichter offener Standard. Ziel: AI-Anwendungen (Hosts) sollen die Außenwelt — Code-Repos, Datenbanken, Dokumentation, Ticketing, Browser — einheitlich und auditierbar anbinden, ohne pro Datenquelle eine Custom-Integration.

Vor MCP wählten Teams meist einen von zwei Wegen:

• Manuelles Kopieren — Issue-Links, SQL-Ergebnisse, API-Antworten in den Chat. Genau, aber langsam und nicht skalierbar.
• Eigenes Function Calling — pro GitHub, Postgres, Notion Tool-Schema und Auth. Flexibel, aber teuer in der Wartung; beim Client-Wechsel (Cursor → Claude Code) oft Neuschreiben.

MCP ist der dritte Weg: Die Schnittstelle „Datenquelle ↔ Agent“ wird standardisiert. Einmal GitHub MCP konfiguriert — Cursor, Claude Code, VS Code Copilot und OpenAI Codex können es nutzen. Die Community pflegt tausende fertige Server für gängige SaaS und Dev-Tools.

Drei Schichten: Host, Client, Server

Für die MCP-Konfiguration zuerst die drei Rollen verstehen:

Typische Kette: Sie fragen in Cursor „Welche Dateien hat PR #42 geändert?“ → Host → Modell wählt mcp__github__get_pull_request → Client sendet per stdio oder HTTP an GitHub MCP → Server ruft GitHub API auf → strukturiertes JSON zurück → Modell antwortet mit echten Daten.

Wichtig: Sie konfigurieren die Server-Verbindung (Befehl, URL, Umgebungsvariablen). Der Host entdeckt automatisch die Tools. Keine manuelle API-Doku im Prompt — beim Start liefert der Server über tools/list die Fähigkeitsliste.

Drei Fähigkeits-Primitive: Tools, Resources, Prompts

Ein MCP Server exponiert drei Arten von Fähigkeiten — unterschiedliche Muster für Datenquellen:

Tools — „Dem Agent Handlungen ermöglichen“

Am häufigsten. Jedes Tool hat Name, Beschreibung und Input-Schema (JSON Schema); der Agent ruft es bei Bedarf auf. Beispiele: GitHub MCP search_code, Playwright MCP browser_click, DB-MCP execute_query.

Bei der Datenquellen-Konfiguration gilt: ~90 % der Fälle sind Tool-Server — Repo lesen, Tabellen abfragen, HTTP, Browser steuern.

Resources — „Statischen Kontext lesbar machen“

Resources sind adressierbare Datenschnipsel, wie schreibgeschützte Dateien mit URI. Der Server deklariert file://docs/api.md oder db://schema/users; der Host kann Inhalte vor oder während des Gesprächs laden — ohne dass der Agent raten muss, welches Tool passt.

Geeignet für: README, OpenAPI-Spec, DB-Schema-Snapshot, Config-Vorlagen — relativ stabil und aufzählbar.

Prompts — „Vorgefertigte Workflow-Einstiege“

Der Server kann benannte Prompt-Vorlagen (mit Parametern) anbieten — in Cursor z. B. „Code Review“ oder „Migrationsskript“ per Klick. Seltener in der Community als Tools, aber gut für teaminterne SOPs als wiederverwendbare Einstiege.

Datenquellentypen und gängige MCP Server

Diese Tabelle mappt „Was will ich anbinden?“ auf „Welchen Server?“. Die vollständige Liste mit 20 Servern: MCP Server Empfehlungen 2026.

Transportschicht: stdio oder HTTP?

MCP Client und Server sprechen JSON-RPC 2.0. 2026 dominieren zwei Transporte:

stdio (Standard Input/Output)

Der Host startet den Server als Subprozess, z. B. npx -y @modelcontextprotocol/server-github, Nachrichten über stdin/stdout. Vorteile: einfache Config, keine offenen Ports, ideal lokal. Nachteile: ein Prozess pro Server; volle Docker-Varianten können Cursors ~40-Tool-Limit sprengen.

Streamable HTTP / SSE (Remote)

Server remote oder offiziell gehostet; Client per HTTPS, oft OAuth. GitHub, Supabase, Linear, Sentry bieten Remote-Varianten. Vorteile: schlankere Tool-Sets, kein lokales Node/Docker, Token via OAuth. Nachteile: Netzabhängigkeit; in Unternehmensnetzen Egress prüfen.

Datenquellen in Cursor konfigurieren

Cursor: Settings → MCP oder ~/.cursor/mcp.json. Struktur: Objekt mcpServers, ein Eintrag pro Server.

Beispiel 1: Lokales stdio — Fetch MCP

{
  "mcpServers": {
    "fetch": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-fetch"]
    }
  }
}

Beispiel 2: Lokales stdio — GitHub MCP (PAT)

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_xxxxxxxx"
      }
    }
  }
}

Besser: offiziellen GitHub Remote MCP in der Cursor-UI (OAuth) — weniger Tools, kein PAT in JSON. PAT feingranular read-only; nie in git committen.

Beispiel 3: Context7 (Dokumentations-Datenquelle)

{
  "mcpServers": {
    "context7": {
      "command": "npx",
      "args": ["-y", "@upstash/context7-mcp"]
    }
  }
}

Nach dem Speichern Cursor neu starten; in Settings → MCP grüner „Connected“-Status. Im Agent-Modus: „Wie schreibt man Middleware in Next.js 15?“ — bei korrekter Config ruft das Modell Context7 auf statt zu halluzinieren.

Datenquellen in Claude Code konfigurieren

Claude Code: ~/.claude.json (Benutzer) oder .mcp.json im Projektroot. Struktur ähnlich wie Cursor, Pfade leicht anders.

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_xxxxxxxx"
      }
    },
    "codegraph": {
      "command": "codegraph",
      "args": ["mcp"]
    }
  }
}

Nach Änderungen Claude Code vollständig beenden und neu starten; im Repo claude ausführen, in der Session /mcp — verbundene Server und Tools prüfen. Erfolg: Tools mit Präfix mcp__github__*, mcp__codegraph__*.

Schritt-für-Schritt: Claude Code MCP Setup-Anleitung; Architektur-Überblick: MCP GitHub Files API Chain.

Projekt- vs. Benutzerebene: Wo schreibt man die Config?

Best Practice: Credentials und persönliche Präferenzen auf Benutzerebene (nicht in git); repo-gebundene Quellen (CodeGraph-Pfad, Projekt-Docs-Server) in .mcp.json committen — Kollegen clone-and-go. Sensitive Tokens per Env-Var, z. B. "env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_PAT}" }, von Shell oder CI injiziert.

Abnahme: Der Agent nutzt die Datenquelle wirklich

Konfiguriert ≠ funktionsfähig. Checkliste:

1. Verbindung — Cursor: Settings → MCP grün; Claude Code: /mcp ohne error.
2. Tools sichtbar — Ziel-Tool existiert, z. B. mcp__github__search_code.
3. Smoke-Task — Klare Anweisung: „Liste open issues dieses Repos via GitHub MCP“ oder „Context7: neueste Prisma migrate-Syntax“.
4. Fehler sichtbar — Ruft der Agent nichts auf: zu viele Tools, vage Aufgabe; ggf. „Bitte GitHub MCP verwenden“ im Prompt.
5. Berechtigungsgrenze — Unberechtigte Aktion (Repo löschen) muss 403 liefern, nicht still „OK“.

Berechtigungen und Sicherheitsgrenzen

Jede Datenquelle öffnet dem Agent eine Tür nach außen. Prinzip: Standard read-only, Schreiben explizit, Produktion isolieren.

• GitHub PAT — Feingranular, nur Ziel-Repos; Issues/Contents read-only reicht für die meisten Dev-Szenarien.
• DB-DSN — Dev-DB mit read-only Rolle; nie produktionsfähige Schreib-DSN in Projekt-Config.
• Filesystem MCP — args auf Projektroot begrenzen, nicht $HOME oder /.
• Interne APIs — Staging read-only; Claude-Workspace ohne Produktions-.env.

Strategie-Matrix und Angriffsketten: MCP mit minimalen Berechtigungen.

Typische Fehlerbehebung

FAQ

Was ist der Unterschied zwischen MCP und Function Calling?

Function Calling deklariert Tools in einem API-Request, oft an Modell/Anbieter gebunden. MCP ist persistente Server-Verbindung und offenes Protokoll — einmal konfiguriert, viele Clients, Community-Ökosystem. MCP ≈ standardisierte, auswechselbare Function-Calling-Runtime.

Kann ich einen eigenen MCP Server schreiben?

Ja. Offizielle SDKs für TypeScript (@modelcontextprotocol/sdk), Python u. a. Typisch: internes Wiki, Ticketing-API, Data Lake. Minimum: tools/list und tools/call, stdio — in Cursor debuggen.

Sendet MCP Daten an Modellanbieter?

Tool-Ergebnisse landen im Dialogkontext und gehen mit Ihrer Anfrage an die LLM-API des Hosts — das ist für Agent-Arbeit nötig. MCP „lädt“ nichts extra hoch; Risiko = welche Rechte Sie dem Server geben. Minimal privilege begrenzt die Fläche.

Welche Datenquellen zuerst in 2026?

Meist Context7 (Docs) + GitHub (Repo) + Playwright (Browser-Check). Backend: Supabase oder DBHub; Linear/Notion wenn das Team sie nutzt. Details: 20 MCP Server Empfehlungen.