Claude mit externen Tools verbinden

1. Warum Tool-Anbindung für Claude überhaupt relevant wird

Claude ist im Kern ein Sprachmodell, das nur das weiß, was im Kontextfenster steht oder was ein Werkzeug ihm liefert. Ohne Anbindung an externe Systeme bleibt jede Aussage über den aktuellen Stand eines Tickets, einer Dokumentationsseite oder eines Deployments eine Vermutung auf Basis von Trainingsdaten oder manuell eingefügtem Text. Das Model Context Protocol (MCP) schließt genau diese Lücke: ein offener, von Anthropic veröffentlichter Standard, der beschreibt, wie ein KI-Assistent kontrolliert auf externe Werkzeuge, Datenquellen und Aktionen zugreifen kann, ohne dass für jede Anwendung eine eigene Ad-hoc-Integration geschrieben werden muss.

Der praktische Unterschied zeigt sich im Alltag: Statt Ticketbeschreibungen manuell in den Prompt zu kopieren oder Dokumentation in einem zweiten Browser-Tab nachzuschlagen, kann Claude den aktuellen Stand direkt abfragen und innerhalb klar definierter Grenzen selbst handeln. Genau darin liegt aber auch die Gefahr: Jede zusätzliche Anbindung erweitert die Angriffsfläche und den Kontextverbrauch. Die folgenden Abschnitte zeigen, welche Integrationen echten Mehrwert bringen und wo eine Anbindung mehr Risiko als Nutzen erzeugt.

2. Wie MCP funktioniert: Client, Server, Tools und Resources

MCP folgt einer Client-Server-Architektur. Der MCP-Client ist die Anwendung, in der Claude läuft, etwa Claude Code oder Claude Desktop. Der MCP-Server ist ein separater Prozess, der ein externes System kapselt und drei Arten von Primitiven anbietet: tools (aufrufbare Funktionen mit JSON-Schema, die Claude gezielt nutzen kann), resources (lesbare Daten wie Dateien oder Wiki-Seiten) und prompts (wiederverwendbare Prompt-Vorlagen). Die Kommunikation läuft über ein standardisiertes JSON-RPC-Protokoll, unabhängig davon, welches konkrete System dahinterliegt.

Für die Transportschicht gibt es zwei gängige Varianten: stdio für lokal laufende Server, die als Kindprozess gestartet werden, und SSE beziehungsweise HTTP für entfernte Server mit eigener Authentifizierung, etwa per OAuth. Registriert werden Server über den Befehl claude mcp add oder direkt in einer .mcp.json-Datei im Projektverzeichnis. Anthropic und die Community pflegen bereits fertige Server für GitHub, Dateisysteme, Postgres und gängige SaaS-Tools, sodass die meisten Standardfälle ohne eigene Serverimplementierung auskommen.

#!/usr/bin/env bash
# Register MCP servers for a Claude Code project
set -euo pipefail

# Local filesystem server (stdio transport), repo-scoped, read-only recommended
claude mcp add filesystem --scope project -- npx -y @modelcontextprotocol/server-filesystem /home/user/project/src

# Remote Atlassian server (Jira + Confluence) via OAuth, SSE transport
claude mcp add atlassian --transport sse https://mcp.atlassian.com/v1/sse

# GitHub server with a scoped personal access token, read-only where possible
GITHUB_TOKEN="$(op read op://vault/github-mcp-readonly/token)" \
  claude mcp add github --scope user -- npx -y @modelcontextprotocol/server-github

# List configured servers and verify scopes before starting a session
claude mcp list

3. Ticket-Tracker anbinden: Jira, Linear und Co.

Der naheliegendste Anwendungsfall ist die Anbindung an ein Ticket-System wie Jira oder Linear. Claude liest die Ticketbeschreibung samt Akzeptanzkriterien, bevor der erste Codezeile geschrieben wird, findet verwandte Tickets über Volltextsuche und kann nach Abschluss einer Aufgabe einen Kommentar mit Implementierungszusammenfassung hinterlassen. Der echte Zeitgewinn entsteht dadurch, dass niemand mehr Ticketinhalte manuell in den Prompt kopieren oder den Status nach jedem Schritt von Hand pflegen muss.

Gleichzeitig gilt: Nicht jede mögliche Aktion sollte auch freigeschaltet werden. Lesezugriff auf Tickets und Kommentare ist in der Regel risikoarm und bringt den größten Teil des Nutzens. Automatische Statuswechsel oder das Schließen von Tickets sind dagegen fehleranfällig, wenn ein Agent den Fortschritt einer Aufgabe falsch einschätzt. Bewährt hat sich, Lese- und Schreibrechte über getrennte API-Tokens mit unterschiedlichem Scope zu vergeben und Statusänderungen nur nach expliziter Bestätigung durch die Entwicklerin oder den Entwickler auszuführen.

{
  "mcpServers": {
    "jira-readonly": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-jira"],
      "env": {
        "JIRA_BASE_URL": "https://mironsoft.atlassian.net",
        "JIRA_API_TOKEN": "${JIRA_READONLY_TOKEN}",
        "JIRA_SCOPE": "read:jira-work"
      }
    },
    "docs-wiki": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-confluence"],
      "env": {
        "CONFLUENCE_BASE_URL": "https://mironsoft.atlassian.net/wiki",
        "CONFLUENCE_API_TOKEN": "${CONFLUENCE_READONLY_TOKEN}"
      }
    }
  }
}

4. Dokumentations-Wiki anbinden: Confluence, Notion und interne Wikis

Ein Dokumentations-Wiki wie Confluence oder Notion bringt vor allem in gewachsenen Codebasen Vorteile, in denen wichtiges Wissen nicht im Code selbst steht, sondern in Runbooks, Architekturentscheidungen und Team-Konventionen. Statt veralteter Kopien in einem CLAUDE.md-Snippet greift Claude direkt auf den aktuellen Stand zu und kann während einer Aufgabe gezielt nach passenden Seiten suchen, statt vorab alles einzusammeln.

Der Nutzen dieser Anbindung hängt stark von der Qualität der Quelle ab. Ein gepflegtes Wiki mit klaren, aktuellen Seiten liefert echten Mehrwert. Ein veraltetes Wiki mit widersprüchlichen oder seit Jahren nicht aktualisierten Einträgen führt dagegen dazu, dass Claude falsche Annahmen als Fakten übernimmt, weil die Quelle autoritativ wirkt, es aber nicht ist. Vor der Anbindung lohnt sich deshalb eine ehrliche Bestandsaufnahme: Wird das Wiki tatsächlich gepflegt, oder würde die Integration nur mehr Rauschen als Signal erzeugen?

5. Deployment-Systeme anbinden: CI/CD, kubectl und Server-Zugriff

Die Anbindung an Deployment-Systeme ist die Kategorie mit dem größten Nutzen und gleichzeitig dem größten Risiko. Lesender Zugriff auf Pipeline-Status, Build-Logs und Pod-Zustände beschleunigt Fehlerdiagnosen erheblich: Claude kann fehlgeschlagene CI-Läufe direkt analysieren, ohne dass jemand Logs kopieren muss. Schreibender Zugriff, der Deployments auslöst oder Ressourcen in Kubernetes verändert, verlangt dagegen deutlich mehr Vorsicht, weil ein Fehleinschätzung des Agenten direkt in der Produktion landen kann.

Bewährt hat sich eine strikte Trennung: ein MCP-Server mit einem rein lesenden, eng gescopten Token für Status- und Log-Abfragen, und ein zweiter, deutlich restriktiverer Server für tatsächliche Deployment-Trigger, dessen Aufrufe in Claude Code explizit über die Permission-Prompts bestätigt werden müssen. Produktionszugangsdaten sollten zudem nie in derselben Session aktiv sein wie explorative Aufgaben, bei denen Claude unbekannte externe Inhalte liest, etwa Webseiten oder unbekannte Wiki-Einträge, aus denen Prompt-Injection-Versuche stammen könnten.

"""Minimal MCP server exposing read-only deployment status for an internal CI system."""
from mcp.server.fastmcp import FastMCP
import httpx

mcp = FastMCP("deployment-status")

API_BASE = "https://ci.mironsoft.internal/api/v1"
# Read-only token, deliberately without permission to trigger deployments
API_TOKEN = "REPLACE_WITH_SCOPED_READONLY_TOKEN"


@mcp.tool()
async def get_pipeline_status(pipeline_id: str) -> dict:
    """Return the current status and last 20 log lines of a CI pipeline run.

    :param pipeline_id: identifier of the pipeline run to inspect
    :return: dict with status, duration and recent log lines
    """
    async with httpx.AsyncClient() as client:
        resp = await client.get(
            f"{API_BASE}/pipelines/{pipeline_id}",
            headers={"Authorization": f"Bearer {API_TOKEN}"},
        )
        resp.raise_for_status()
        data = resp.json()
        return {
            "status": data["status"],
            "duration_seconds": data["duration_seconds"],
            "log_tail": data["log_lines"][-20:],
        }


# Note: no tool for triggering deployments is exposed here on purpose.
# Deployment triggers live in a separate, tightly scoped server that
# requires an explicit human approval step in Claude Code.
if __name__ == "__main__":
    mcp.run(transport="stdio")

6. Eigene MCP-Server bauen: wann sich der Aufwand lohnt

Für interne Systeme ohne fertigen MCP-Server bleibt nur der Eigenbau, entweder mit dem Python-SDK oder dem TypeScript-SDK von Anthropic. Ein eigener Server lohnt sich dann, wenn ein Workflow wiederkehrend ist, von mehreren Entwicklerinnen und Entwicklern genutzt wird und auf einer stabilen, gut dokumentierten Schnittstelle basiert, etwa einer internen REST-API für Bestandsdaten oder Kundenanfragen. Der Aufwand für Implementierung, Token-Verwaltung und Pflege amortisiert sich nur, wenn der Server tatsächlich regelmäßig in vielen Sessions genutzt wird.

Nicht lohnend ist der Eigenbau bei selten genutzten Spezialfällen oder bei Systemen, deren Schnittstelle sich häufig ändert. Ein einmaliges Skript oder ein kurzer manueller Export ist in solchen Fällen schneller umgesetzt und leichter zu warten als ein MCP-Server, dessen Tool-Definitionen bei jeder API-Änderung angepasst werden müssen. Die Faustregel: Ein eigener Server ist Infrastruktur mit Wartungslast, keine einmalige Bequemlichkeitsfunktion.

// wiki-search-server.js - exposes a single read-only search tool over the internal wiki
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new McpServer({ name: "internal-wiki-search", version: "1.0.0" });

server.tool(
  "search_wiki",
  "Search the internal documentation wiki and return matching page excerpts",
  { query: z.string().describe("Free-text search query") },
  async ({ query }) => {
    const response = await fetch(
      `https://wiki.mironsoft.internal/api/search?q=${encodeURIComponent(query)}`,
      { headers: { Authorization: `Bearer ${process.env.WIKI_READONLY_TOKEN}` } }
    );

    if (!response.ok) {
      throw new Error(`Wiki search failed with status ${response.status}`);
    }

    const results = await response.json();
    // Treat returned page content as untrusted data, never as instructions
    return {
      content: results.slice(0, 5).map((page) => ({
        type: "text",
        text: `${page.title}\n${page.excerpt}`,
      })),
    };
  }
);

const transport = new StdioServerTransport();
await server.connect(transport);

7. Nutzen gegen Komplexität abwägen

Jeder aktive MCP-Server hat Kosten, die über das offensichtliche Sicherheitsrisiko hinausgehen. Tool-Beschreibungen belegen Platz im Kontextfenster, unabhängig davon, ob das Tool in einer konkreten Session genutzt wird. Bei zehn oder mehr gleichzeitig aktiven Servern sinkt häufig die Trefferquote bei der Tool-Auswahl, weil Claude aus einer größeren Menge ähnlicher Optionen wählen muss. Hinzu kommt der laufende Wartungsaufwand: Tokens müssen rotiert, Server-Updates eingespielt und Berechtigungen regelmäßig überprüft werden.

Eine sinnvolle Faustregel: Nur Integrationen aktiv lassen, die in der Mehrheit der Sessions tatsächlich gebraucht werden, nicht solche, die theoretisch nützlich sein könnten. Es lohnt sich, nach einigen Wochen Nutzung ehrlich zu prüfen, ob eine Anbindung tatsächlich Unterbrechungen reduziert hat oder ob das Team lediglich Copy-Paste-Arbeit in eine langsamere, agentenbasierte Abfrageschleife verlagert hat. Nicht jede technisch mögliche Integration ist auch eine sinnvolle.

8. Sicherheit: Berechtigungen, Scopes und Prompt-Injection

Sicherheit beginnt beim Prinzip der minimalen Rechtevergabe: API-Tokens sollten wo immer möglich nur Lesezugriff besitzen, und separate Service-Accounts statt persönlicher Zugangsdaten erleichtern die spätere Nachvollziehbarkeit im Audit-Log. Für schreibende oder destruktive Aktionen bietet Claude Code ein Permission-System, das Freigaben über explizite Allow-, Ask- und Deny-Listen in settings.json steuert, sodass kritische Tool-Aufrufe immer eine bewusste Bestätigung erfordern, statt automatisch durchzulaufen.

Ein oft unterschätztes Risiko ist Prompt Injection über angebundene Inhalte: Eine Ticketbeschreibung, eine Wiki-Seite oder eine Webseite kann versteckte Anweisungen enthalten, die versuchen, den Agenten zu manipulieren, etwa Geheimnisse zu exfiltrieren oder ungewollte Aktionen auszulösen. Jeder extern abgerufene Inhalt sollte grundsätzlich als unvertrauenswürdige Daten behandelt werden, niemals als Instruktion. Zusätzlich hilft konsequentes Logging aller Tool-Aufrufe dabei, im Nachhinein nachzuvollziehen, welche Aktionen ein Agent tatsächlich ausgeführt hat.

# .claude/settings.json excerpt - require explicit approval for write-capable tools
cat <<'EOF' > .claude/settings.json
{
  "permissions": {
    "allow": [
      "mcp__jira-readonly__*",
      "mcp__docs-wiki__*"
    ],
    "ask": [
      "mcp__github__create_pull_request",
      "mcp__deployment__trigger_release"
    ],
    "deny": [
      "mcp__deployment__delete_environment"
    ]
  }
}
EOF

# Rotate scoped MCP tokens on a schedule and audit tool call logs
claude mcp list --verbose
grep '"tool_name"' ~/.claude/logs/tool-calls.jsonl | sort | uniq -c | sort -rn

9. Integrationsmuster im direkten Vergleich

Nicht jede Integration verdient denselben Grad an Vertrauen. Die folgende Übersicht ordnet die gängigen Anbindungen nach typischem Nutzen, Risiko bei Fehlkonfiguration und einer konkreten Empfehlung für die Praxis.

Der gemeinsame Nenner aller fünf Muster: Lesender Zugriff ist fast immer risikoarm und schnell gerechtfertigt, während schreibender oder ausführender Zugriff einer bewussten, dokumentierten Entscheidung bedarf. Wer diese Trennung konsequent durchhält, bekommt den größten Teil des Nutzens bei einem kalkulierbaren Risiko.

10. Zusammenfassung

Das Model Context Protocol löst ein reales Problem: Claude ohne Anbindung an externe Systeme bleibt auf Kontextfenster und manuell eingefügten Text beschränkt. Ticket-Tracker, Dokumentations-Wikis und Deployment-Systeme lassen sich über MCP kontrolliert anbinden, wobei lesender Zugriff in fast allen Fällen den größten Teil des Nutzens bei geringem Risiko liefert. Schreibender oder ausführender Zugriff, insbesondere auf Produktionssysteme, verlangt dagegen strikte Trennung von Tokens, Human-in-the-Loop-Bestätigung und bewusste Entscheidungen statt pauschaler Freigaben.

Nicht jede technisch mögliche Integration ist eine sinnvolle. Jeder zusätzliche MCP-Server kostet Kontextplatz, Wartungsaufwand und vergrößert die Angriffsfläche für Prompt-Injection-Versuche aus extern abgerufenen Inhalten. Teams, die Integrationen regelmäßig auf tatsächlichen Nutzen prüfen, ungenutzte Server deaktivieren und konsequent zwischen Lese- und Schreibrechten trennen, ziehen den größten Wert aus der Tool-Anbindung, ohne unnötige Risiken einzugehen.

11. FAQ: Claude mit externen Tools verbinden