SpyBara
Go Premium

mcp.md 2026-05-02 18:14 UTC to 2026-05-04 22:58 UTC

1451 added, 0 removed.

2026
Sun 31 06:39 Sat 30 06:23 Fri 29 06:38 Thu 28 06:37 Wed 27 06:42 Tue 26 06:33 Sun 24 06:25 Sat 23 06:18 Fri 22 06:33 Thu 21 06:36 Wed 20 06:35 Tue 19 06:34 Mon 18 23:59 Sun 17 01:01 Fri 15 22:58 Thu 14 17:02 Wed 13 23:01 Tue 12 22:57 Mon 11 23:00 Sun 10 23:03 Sat 9 04:57 Fri 8 22:00 Thu 7 22:59 Tue 5 23:00 Mon 4 22:58 Sat 2 18:14 Fri 1 18:19

Claude Code mit Tools über MCP verbinden

Erfahren Sie, wie Sie Claude Code mit Ihren Tools über das Model Context Protocol verbinden.

export const MCPServersTable = ({platform = "all"}) => { const ifYouAreAnAiAgentReadingThisYouShouldInsteadFetch = 'https://api.anthropic.com/mcp-registry/docs'; const [servers, setServers] = useState([]); const [loading, setLoading] = useState(true); const [error, setError] = useState(null); useEffect(() => { const fetchServers = async () => { try { setLoading(true); const allServers = []; let cursor = null; do { const url = new URL('https://api.anthropic.com/mcp-registry/v0/servers'); url.searchParams.set('version', 'latest'); url.searchParams.set('visibility', 'commercial'); url.searchParams.set('limit', '100'); if (cursor) { url.searchParams.set('cursor', cursor); } const response = await fetch(url); if (!response.ok) { throw new Error(Failed to fetch MCP registry: ${response.status}); } const data = await response.json(); allServers.push(...data.servers); cursor = data.metadata?.nextCursor || null; } while (cursor); const transformedServers = allServers.map(item => { const server = item.server; const meta = item._meta?.['com.anthropic.api/mcp-registry'] || ({}); const worksWith = meta.worksWith || []; const availability = { claudeCode: worksWith.includes('claude-code'), mcpConnector: worksWith.includes('claude-api'), claudeDesktop: worksWith.includes('claude-desktop') }; const remotes = server.remotes || []; const httpRemote = remotes.find(r => r.type === 'streamable-http'); const sseRemote = remotes.find(r => r.type === 'sse'); const preferredRemote = httpRemote || sseRemote; const remoteUrl = preferredRemote?.url || meta.url; const remoteType = preferredRemote?.type; const isTemplatedUrl = remoteUrl?.includes('{'); let setupUrl; if (isTemplatedUrl && meta.requiredFields) { const urlField = meta.requiredFields.find(f => f.field === 'url'); setupUrl = urlField?.sourceUrl || meta.documentation; } const urls = {}; if (!isTemplatedUrl) { if (remoteType === 'streamable-http') { urls.http = remoteUrl; } else if (remoteType === 'sse') { urls.sse = remoteUrl; } } let envVars = []; if (server.packages && server.packages.length > 0) { const npmPackage = server.packages.find(p => p.registryType === 'npm'); if (npmPackage) { urls.stdio = npx -y ${npmPackage.identifier}; if (npmPackage.environmentVariables) { envVars = npmPackage.environmentVariables; } } } return { name: meta.displayName || server.title || server.name, description: meta.oneLiner || server.description, documentation: meta.documentation, urls: urls, envVars: envVars, availability: availability, customCommands: meta.claudeCodeCopyText ? { claudeCode: meta.claudeCodeCopyText } : undefined, setupUrl: setupUrl }; }); setServers(transformedServers); setError(null); } catch (err) { setError(err.message); console.error('Error fetching MCP registry:', err); } finally { setLoading(false); } }; fetchServers(); }, []); const generateClaudeCodeCommand = server => { if (server.customCommands && server.customCommands.claudeCode) { return server.customCommands.claudeCode.replace('--transport streamable-http', '--transport http'); } const serverSlug = server.name.toLowerCase().replace(/[^a-z0-9]/g, '-'); if (server.urls.http) { return claude mcp add ${serverSlug} --transport http ${server.urls.http}; } if (server.urls.sse) { return claude mcp add ${serverSlug} --transport sse ${server.urls.sse}; } if (server.urls.stdio) { const envFlags = server.envVars && server.envVars.length > 0 ? server.envVars.map(v => --env ${v.name}=YOUR_${v.name}).join(' ') : ''; const baseCommand = claude mcp add ${serverSlug} --transport stdio; return envFlags ? ${baseCommand} ${envFlags} -- ${server.urls.stdio} : ${baseCommand} -- ${server.urls.stdio}; } return null; }; if (loading) { return

Loading MCP servers...
; } if (error) { return
Error loading MCP servers: {error}
; } const filteredServers = servers.filter(server => { if (platform === "claudeCode") { return server.availability.claudeCode; } else if (platform === "mcpConnector") { return server.availability.mcpConnector; } else if (platform === "claudeDesktop") { return server.availability.claudeDesktop; } else if (platform === "all") { return true; } else { throw new Error(Unknown platform: ${platform}); } }); return <> 

  <div className="cards-container">
    {filteredServers.map(server => {
const claudeCodeCommand = generateClaudeCodeCommand(server);
const mcpUrl = server.urls.http || server.urls.sse;
const commandToShow = platform === "claudeCode" ? claudeCodeCommand : mcpUrl;
return <div key={server.name} className="server-card">
          <div>
            {server.documentation ? <a href={server.documentation}>
                <strong>{server.name}</strong>
              </a> : <strong>{server.name}</strong>}
          </div>

          <p style={{
  margin: '0.5rem 0',
  fontSize: '0.9rem'
}}>
            {server.description}
          </p>

          {server.setupUrl && <p style={{
  margin: '0.25rem 0',
  fontSize: '0.8rem',
  fontStyle: 'italic',
  opacity: 0.7
}}>
              Requires user-specific URL.{' '}
              <a href={server.setupUrl} style={{
  textDecoration: 'underline'
}}>
                Get your URL here
              </a>.
            </p>}

          {commandToShow && !server.setupUrl && <>
            <p style={{
  display: 'block',
  fontSize: '0.75rem',
  fontWeight: 500,
  minWidth: 'fit-content',
  marginTop: '0.5rem',
  marginBottom: 0
}}>
              {platform === "claudeCode" ? "Command" : "URL"}
            </p>
            <div className="command-row">
              <code>
                {commandToShow}
              </code>
            </div>
          </>}
        </div>;

})}

</>; };

Claude Code kann sich über das Model Context Protocol (MCP), einen offenen Standard für KI-Tool-Integrationen, mit Hunderten von externen Tools und Datenquellen verbinden. MCP-Server geben Claude Code Zugriff auf Ihre Tools, Datenbanken und APIs.

Verbinden Sie einen Server, wenn Sie feststellen, dass Sie Daten aus einem anderen Tool wie einem Issue-Tracker oder einem Überwachungs-Dashboard in den Chat kopieren. Nach der Verbindung kann Claude direkt auf dieses System zugreifen und handeln, anstatt mit dem zu arbeiten, was Sie einfügen.

Was Sie mit MCP tun können

Mit verbundenen MCP-Servern können Sie Claude Code auffordern:

  • Funktionen aus Issue-Trackern implementieren: „Füge die in JIRA-Issue ENG-4521 beschriebene Funktion hinzu und erstelle einen PR auf GitHub."
  • Überwachungsdaten analysieren: „Überprüfe Sentry und Statsig, um die Nutzung der in ENG-4521 beschriebenen Funktion zu überprüfen."
  • Datenbanken abfragen: „Finde E-Mail-Adressen von 10 zufälligen Benutzern, die die Funktion ENG-4521 verwendet haben, basierend auf unserer PostgreSQL-Datenbank."
  • Designs integrieren: „Aktualisiere unsere Standard-E-Mail-Vorlage basierend auf den neuen Figma-Designs, die in Slack gepostet wurden"
  • Workflows automatisieren: „Erstelle Gmail-Entwürfe, die diese 10 Benutzer zu einer Feedback-Sitzung zur neuen Funktion einladen."
  • Auf externe Ereignisse reagieren: Ein MCP-Server kann auch als Kanal fungieren, der Nachrichten in Ihre Sitzung pusht, sodass Claude auf Telegram-Nachrichten, Discord-Chats oder Webhook-Ereignisse reagiert, während Sie weg sind.

Beliebte MCP-Server

Hier sind einige häufig verwendete MCP-Server, die Sie mit Claude Code verbinden können:

MCP-Server installieren

MCP-Server können je nach Ihren Anforderungen auf drei verschiedene Arten konfiguriert werden:

Option 1: Einen Remote-HTTP-Server hinzufügen

HTTP-Server sind die empfohlene Option für die Verbindung mit Remote-MCP-Servern. Dies ist das am weitesten unterstützte Transportprotokoll für Cloud-basierte Dienste.

# Grundlegende Syntax
claude mcp add --transport http <name> <url>

# Echtes Beispiel: Mit Notion verbinden
claude mcp add --transport http notion https://mcp.notion.com/mcp

# Beispiel mit Bearer-Token
claude mcp add --transport http secure-api https://api.example.com/mcp \
  --header "Authorization: Bearer your-token"

Option 2: Einen Remote-SSE-Server hinzufügen

# Grundlegende Syntax
claude mcp add --transport sse <name> <url>

# Echtes Beispiel: Mit Asana verbinden
claude mcp add --transport sse asana https://mcp.asana.com/sse

# Beispiel mit Authentifizierungs-Header
claude mcp add --transport sse private-api https://api.company.com/sse \
  --header "X-API-Key: your-key-here"

Option 3: Einen lokalen Stdio-Server hinzufügen

Stdio-Server werden als lokale Prozesse auf Ihrem Computer ausgeführt. Sie sind ideal für Tools, die direkten Systemzugriff oder benutzerdefinierte Skripte benötigen.

# Grundlegende Syntax
claude mcp add [options] <name> -- <command> [args...]

# Echtes Beispiel: Airtable-Server hinzufügen
claude mcp add --transport stdio --env AIRTABLE_API_KEY=YOUR_KEY airtable \
  -- npx -y airtable-mcp-server

Verwalten Ihrer Server

Nach der Konfiguration können Sie Ihre MCP-Server mit diesen Befehlen verwalten:

# Alle konfigurierten Server auflisten
claude mcp list

# Details für einen bestimmten Server abrufen
claude mcp get github

# Einen Server entfernen
claude mcp remove github

# (innerhalb von Claude Code) Serverstatus überprüfen
/mcp

Dynamische Tool-Updates

Claude Code unterstützt MCP-list_changed-Benachrichtigungen, die es MCP-Servern ermöglichen, ihre verfügbaren Tools, Prompts und Ressourcen dynamisch zu aktualisieren, ohne dass Sie die Verbindung trennen und erneut verbinden müssen. Wenn ein MCP-Server eine list_changed-Benachrichtigung sendet, aktualisiert Claude Code automatisch die verfügbaren Funktionen von diesem Server.

Automatische Wiederverbindung

Wenn ein HTTP- oder SSE-Server während einer Sitzung die Verbindung trennt, verbindet sich Claude Code automatisch mit exponentiellem Backoff wieder: bis zu fünf Versuche, beginnend mit einer Verzögerung von einer Sekunde und sich jedes Mal verdoppelnd. Der Server wird als ausstehend in /mcp angezeigt, während die Wiederverbindung läuft. Nach fünf fehlgeschlagenen Versuchen wird der Server als fehlgeschlagen markiert und Sie können ihn manuell von /mcp aus erneut versuchen. Stdio-Server sind lokale Prozesse und werden nicht automatisch wiederverbunden.

Das gleiche Backoff gilt, wenn ein HTTP- oder SSE-Server beim Start seine anfängliche Verbindung nicht herstellt. Ab v2.1.121 versucht Claude Code die anfängliche Verbindung bis zu dreimal bei vorübergehenden Fehlern wie einer 5xx-Antwort, einer Verbindungsverweigerung oder einem Timeout erneut, markiert den Server dann als fehlgeschlagen, wenn er immer noch keine Verbindung herstellen kann. Authentifizierungs- und Not-Found-Fehler werden nicht erneut versucht, da sie eine Konfigurationsänderung erfordern, um behoben zu werden.

Push-Nachrichten mit Kanälen

Ein MCP-Server kann auch Nachrichten direkt in Ihre Sitzung pushen, sodass Claude auf externe Ereignisse wie CI-Ergebnisse, Überwachungswarnungen oder Chat-Nachrichten reagieren kann. Um dies zu aktivieren, deklariert Ihr Server die Funktion claude/channel und Sie aktivieren sie mit dem Flag --channels beim Start. Siehe Kanäle, um einen offiziell unterstützten Kanal zu verwenden, oder Kanäle-Referenz, um Ihren eigenen zu erstellen.

Von Plugins bereitgestellte MCP-Server

Plugins können MCP-Server bündeln und automatisch Tools und Integrationen bereitstellen, wenn das Plugin aktiviert ist. Plugin-MCP-Server funktionieren identisch mit benutzerkonfigurierten Servern.

Wie Plugin-MCP-Server funktionieren:

  • Plugins definieren MCP-Server in .mcp.json im Plugin-Root oder inline in plugin.json
  • Wenn ein Plugin aktiviert ist, starten seine MCP-Server automatisch
  • Plugin-MCP-Tools erscheinen neben manuell konfigurierten MCP-Tools
  • Plugin-Server werden durch die Plugin-Installation verwaltet (nicht durch /mcp-Befehle)

Beispiel-Plugin-MCP-Konfiguration:

In .mcp.json im Plugin-Root:

{
  "mcpServers": {
    "database-tools": {
      "command": "${CLAUDE_PLUGIN_ROOT}/servers/db-server",
      "args": ["--config", "${CLAUDE_PLUGIN_ROOT}/config.json"],
      "env": {
        "DB_URL": "${DB_URL}"
      }
    }
  }
}

Oder inline in plugin.json:

{
  "name": "my-plugin",
  "mcpServers": {
    "plugin-api": {
      "command": "${CLAUDE_PLUGIN_ROOT}/servers/api-server",
      "args": ["--port", "8080"]
    }
  }
}

Plugin-MCP-Funktionen:

  • Automatischer Lebenszyklus: Bei Sitzungsstart verbinden sich Server für aktivierte Plugins automatisch. Wenn Sie ein Plugin während einer Sitzung aktivieren oder deaktivieren, führen Sie /reload-plugins aus, um seine MCP-Server zu verbinden oder zu trennen
  • Umgebungsvariablen: Verwenden Sie ${CLAUDE_PLUGIN_ROOT} für gebündelte Plugin-Dateien und ${CLAUDE_PLUGIN_DATA} für persistente Daten, die Plugin-Updates überstehen
  • Zugriff auf Benutzerumgebung: Zugriff auf die gleichen Umgebungsvariablen wie manuell konfigurierte Server
  • Mehrere Transporttypen: Unterstützung für Stdio-, SSE- und HTTP-Transporte (die Transportunterstützung kann je nach Server variieren)

Anzeigen von Plugin-MCP-Servern:

# Innerhalb von Claude Code alle MCP-Server einschließlich Plugin-Server anzeigen
/mcp

Plugin-Server erscheinen in der Liste mit Indikatoren, die zeigen, dass sie von Plugins stammen.

Vorteile von Plugin-MCP-Servern:

  • Gebündelte Verteilung: Tools und Server zusammen verpackt
  • Automatische Einrichtung: Keine manuelle MCP-Konfiguration erforderlich
  • Team-Konsistenz: Alle erhalten die gleichen Tools, wenn das Plugin installiert ist

Siehe die Plugin-Komponenten-Referenz für Details zum Bündeln von MCP-Servern mit Plugins.

MCP-Installationsbereiche

MCP-Server können auf drei verschiedenen Bereichsebenen konfiguriert werden. Der Bereich, den Sie wählen, steuert, in welchen Projekten der Server geladen wird und ob die Konfiguration mit Ihrem Team geteilt wird.

Bereich Wird geladen in Mit Team geteilt Gespeichert in
Lokal Nur aktuelles Projekt Nein ~/.claude.json
Projekt Nur aktuelles Projekt Ja, über Versionskontrolle .mcp.json im Projekt-Root
Benutzer Alle Ihre Projekte Nein ~/.claude.json

Lokaler Bereich

Der lokale Bereich ist der Standard. Ein lokal begrenzter Server wird nur in dem Projekt geladen, in dem Sie ihn hinzugefügt haben, und bleibt privat für Sie. Claude Code speichert ihn in ~/.claude.json unter dem Pfad dieses Projekts, daher wird derselbe Server nicht in Ihren anderen Projekten angezeigt. Verwenden Sie den lokalen Bereich für persönliche Entwicklungsserver, experimentelle Konfigurationen oder Server mit Anmeldedaten, die Sie nicht in der Versionskontrolle haben möchten.

# Einen lokal begrenzten Server hinzufügen (Standard)
claude mcp add --transport http stripe https://mcp.stripe.com

# Lokalen Bereich explizit angeben
claude mcp add --transport http stripe --scope local https://mcp.stripe.com

Der Befehl schreibt den Server in den Eintrag für Ihr aktuelles Projekt in ~/.claude.json. Das folgende Beispiel zeigt das Ergebnis, wenn Sie ihn von /path/to/your/project aus ausführen:

{
  "projects": {
    "/path/to/your/project": {
      "mcpServers": {
        "stripe": {
          "type": "http",
          "url": "https://mcp.stripe.com"
        }
      }
    }
  }
}

Projektbereich

Projektbegrenzte Server ermöglichen Teamzusammenarbeit durch das Speichern von Konfigurationen in einer .mcp.json-Datei im Root-Verzeichnis Ihres Projekts. Diese Datei ist dazu bestimmt, in die Versionskontrolle eingecheckt zu werden, um sicherzustellen, dass alle Teammitglieder Zugriff auf die gleichen MCP-Tools und -Dienste haben. Wenn Sie einen projektbegrenzten Server hinzufügen, erstellt oder aktualisiert Claude Code automatisch diese Datei mit der entsprechenden Konfigurationsstruktur.

# Einen projektbegrenzten Server hinzufügen
claude mcp add --transport http paypal --scope project https://mcp.paypal.com/mcp

Die resultierende .mcp.json-Datei folgt einem standardisierten Format:

{
  "mcpServers": {
    "shared-server": {
      "command": "/path/to/server",
      "args": [],
      "env": {}
    }
  }
}

Aus Sicherheitsgründen fordert Claude Code eine Genehmigung an, bevor projektbegrenzte Server aus .mcp.json-Dateien verwendet werden. Wenn Sie diese Genehmigungswahlmöglichkeiten zurücksetzen müssen, verwenden Sie den Befehl claude mcp reset-project-choices.

Benutzerbereich

Benutzerbegrenzte Server werden in ~/.claude.json gespeichert und bieten projektübergreifende Zugänglichkeit, wodurch sie über alle Projekte auf Ihrem Computer verfügbar sind und gleichzeitig privat für Ihr Benutzerkonto bleiben. Dieser Bereich funktioniert gut für persönliche Utility-Server, Entwicklungstools oder Dienste, die Sie häufig über verschiedene Projekte hinweg verwenden.

# Einen Benutzer-Server hinzufügen
claude mcp add --transport http hubspot --scope user https://mcp.hubspot.com/anthropic

Bereichshierarchie und Vorrang

Wenn derselbe Server auf mehreren Bereichen definiert ist, verbindet sich Claude Code einmal damit und verwendet die Definition aus der höchsten Vorrangsquelle:

  1. Lokaler Bereich
  2. Projektbereich
  3. Benutzerbereich
  4. Von Plugins bereitgestellte Server
  5. Claude.ai-Connectoren

Die drei Bereiche stimmen Duplikate nach Name ab. Plugins und Connectoren stimmen nach Endpunkt ab, daher wird einer, der auf die gleiche URL oder den gleichen Befehl wie ein Server oben verweist, als Duplikat behandelt.

Umgebungsvariablen-Erweiterung in .mcp.json

Claude Code unterstützt die Umgebungsvariablen-Erweiterung in .mcp.json-Dateien, die es Teams ermöglicht, Konfigurationen zu teilen und gleichzeitig Flexibilität für maschinenspezifische Pfade und vertrauliche Werte wie API-Schlüssel zu bewahren.

Unterstützte Syntax:

  • ${VAR} - Erweitert sich zum Wert der Umgebungsvariablen VAR
  • ${VAR:-default} - Erweitert sich zu VAR, wenn gesetzt, andernfalls wird default verwendet

Erweiterungsorte: Umgebungsvariablen können erweitert werden in:

  • command - Der Server-Ausführungspfad
  • args - Befehlszeilenargumente
  • env - Umgebungsvariablen, die an den Server übergeben werden
  • url - Für HTTP-Server-Typen
  • headers - Für HTTP-Server-Authentifizierung

Beispiel mit Variablenerweiterung:

{
  "mcpServers": {
    "api-server": {
      "type": "http",
      "url": "${API_BASE_URL:-https://api.example.com}/mcp",
      "headers": {
        "Authorization": "Bearer ${API_KEY}"
      }
    }
  }
}

Wenn eine erforderliche Umgebungsvariable nicht gesetzt ist und keinen Standardwert hat, kann Claude Code die Konfiguration nicht analysieren.

Praktische Beispiele

{/* ### Beispiel: Browser-Tests mit Playwright automatisieren

claude mcp add --transport stdio playwright -- npx -y @playwright/mcp@latest

Dann schreiben und führen Sie Browser-Tests aus:

Test if the login flow works with test@example.com

Take a screenshot of the checkout page on mobile

Verify that the search feature returns results
``` */}

### Beispiel: Fehler mit Sentry überwachen

```bash theme={null}
claude mcp add --transport http sentry https://mcp.sentry.dev/mcp

Authentifizieren Sie sich mit Ihrem Sentry-Konto:

/mcp

Debuggen Sie dann Produktionsprobleme:

What are the most common errors in the last 24 hours?

Show me the stack trace for error ID abc123

Which deployment introduced these new errors?

Beispiel: Mit GitHub für Code-Reviews verbinden

GitHubs Remote-MCP-Server authentifiziert sich mit einem GitHub-Personal-Access-Token, der als Header übergeben wird. Um einen zu erhalten, öffnen Sie Ihre GitHub-Token-Einstellungen, generieren Sie ein neues feingranulares Token mit Zugriff auf die Repositories, mit denen Claude arbeiten soll, und fügen Sie dann den Server hinzu:

claude mcp add --transport http github https://api.githubcopilot.com/mcp/ \
  --header "Authorization: Bearer YOUR_GITHUB_PAT"

Arbeiten Sie dann mit GitHub:

Review PR #456 and suggest improvements

Create a new issue for the bug we just found

Show me all open PRs assigned to me

Beispiel: Ihre PostgreSQL-Datenbank abfragen

claude mcp add --transport stdio db -- npx -y @bytebase/dbhub \
  --dsn "postgresql://readonly:pass@prod.db.com:5432/analytics"

Fragen Sie dann Ihre Datenbank natürlich ab:

What's our total revenue this month?

Show me the schema for the orders table

Find customers who haven't made a purchase in 90 days

Mit Remote-MCP-Servern authentifizieren

Viele Cloud-basierte MCP-Server erfordern Authentifizierung. Claude Code unterstützt OAuth 2.0 für sichere Verbindungen.

1

Fügen Sie den Server hinzu, der Authentifizierung erfordert

Zum Beispiel:

claude mcp add --transport http sentry https://mcp.sentry.dev/mcp
2

Verwenden Sie den /mcp-Befehl innerhalb von Claude Code

In Claude Code verwenden Sie den Befehl:

/mcp

Folgen Sie dann den Schritten in Ihrem Browser, um sich anzumelden.

Verwenden Sie einen festen OAuth-Callback-Port

Einige MCP-Server erfordern einen spezifischen Redirect-URI, der im Voraus registriert ist. Standardmäßig wählt Claude Code einen zufällig verfügbaren Port für den OAuth-Callback. Verwenden Sie --callback-port, um den Port zu fixieren, damit er einem vorregistrierten Redirect-URI der Form http://localhost:PORT/callback entspricht.

Sie können --callback-port allein (mit dynamischer Client-Registrierung) oder zusammen mit --client-id (mit vorkonfigurierten Anmeldedaten) verwenden.

# Fester Callback-Port mit dynamischer Client-Registrierung
claude mcp add --transport http \
  --callback-port 8080 \
  my-server https://mcp.example.com/mcp

Verwenden Sie vorkonfigurierte OAuth-Anmeldedaten

Einige MCP-Server unterstützen keine automatische OAuth-Einrichtung über Dynamic Client Registration. Wenn Sie einen Fehler wie „Incompatible auth server: does not support dynamic client registration" sehen, erfordert der Server vorkonfigurierte Anmeldedaten. Claude Code unterstützt auch Server, die ein Client ID Metadata Document (CIMD) anstelle von Dynamic Client Registration verwenden, und erkennt diese automatisch. Wenn die automatische Erkennung fehlschlägt, registrieren Sie zunächst eine OAuth-App über das Entwicklerportal des Servers und geben Sie dann die Anmeldedaten beim Hinzufügen des Servers an.

1

Registrieren Sie eine OAuth-App beim Server

Erstellen Sie eine App über das Entwicklerportal des Servers und notieren Sie sich Ihre Client-ID und Ihren Client-Secret.

Viele Server erfordern auch einen Redirect-URI. Wenn ja, wählen Sie einen Port und registrieren Sie einen Redirect-URI im Format http://localhost:PORT/callback. Verwenden Sie denselben Port mit --callback-port im nächsten Schritt.

2

Fügen Sie den Server mit Ihren Anmeldedaten hinzu

Wählen Sie eine der folgenden Methoden. Der für --callback-port verwendete Port kann ein beliebiger verfügbarer Port sein. Er muss nur dem Redirect-URI entsprechen, den Sie im vorherigen Schritt registriert haben.

Verwenden Sie --client-id, um die Client-ID Ihrer App zu übergeben. Das Flag --client-secret fordert das Secret mit maskierter Eingabe an:

claude mcp add --transport http \
--client-id your-client-id --client-secret --callback-port 8080 \
my-server https://mcp.example.com/mcp
3

Authentifizieren Sie sich in Claude Code

Führen Sie /mcp in Claude Code aus und folgen Sie dem Browser-Login-Ablauf.

Überschreiben Sie die OAuth-Metadaten-Erkennung

Verweisen Sie Claude Code auf eine spezifische OAuth-Autorisierungsserver-Metadaten-URL, um die Standard-Erkennungskette zu umgehen. Legen Sie authServerMetadataUrl fest, wenn die Standard-Endpunkte des MCP-Servers Fehler zurückgeben, oder wenn Sie die Erkennung durch einen internen Proxy leiten möchten. Standardmäßig überprüft Claude Code zunächst RFC 9728 Protected Resource Metadata unter /.well-known/oauth-protected-resource und fällt dann auf RFC 8414 Authorization Server Metadata unter /.well-known/oauth-authorization-server zurück.

Legen Sie authServerMetadataUrl im Objekt oauth der Konfiguration Ihres Servers in .mcp.json fest:

{
  "mcpServers": {
    "my-server": {
      "type": "http",
      "url": "https://mcp.example.com/mcp",
      "oauth": {
        "authServerMetadataUrl": "https://auth.example.com/.well-known/openid-configuration"
      }
    }
  }
}

Die URL muss https:// verwenden. authServerMetadataUrl erfordert Claude Code v2.1.64 oder später. Die scopes_supported der Metadaten-URL überschreiben die Bereiche, die der Upstream-Server bewirbt.

Beschränken Sie OAuth-Bereiche

Legen Sie oauth.scopes fest, um die Bereiche zu fixieren, die Claude Code während des Autorisierungsflusses anfordert. Dies ist die unterstützte Methode, um einen MCP-Server auf eine von Ihrem Sicherheitsteam genehmigte Teilmenge zu beschränken, wenn der Upstream-Autorisierungsserver mehr Bereiche bewirbt, als Sie gewähren möchten. Der Wert ist eine einzelne durch Leerzeichen getrennte Zeichenkette, die dem scope-Parameter-Format in RFC 6749 §3.3 entspricht.

{
  "mcpServers": {
    "slack": {
      "type": "http",
      "url": "https://mcp.slack.com/mcp",
      "oauth": {
        "scopes": "channels:read chat:write search:read"
      }
    }
  }
}

oauth.scopes hat Vorrang vor sowohl authServerMetadataUrl als auch den Bereichen, die der Server unter /.well-known entdeckt. Lassen Sie es ungesetzt, damit der MCP-Server den angeforderten Bereichssatz bestimmt.

Wenn der Autorisierungsserver offline_access in scopes_supported bewirbt, fügt Claude Code es zu den fixierten Bereichen hinzu, damit das Zugriffs-Token ohne neue Browser-Anmeldung aktualisiert werden kann.

Wenn der Server später einen 403 insufficient_scope für einen Tool-Aufruf zurückgibt, authentifiziert sich Claude Code mit den gleichen fixierten Bereichen erneut. Erweitern Sie oauth.scopes, wenn ein Tool, das Sie benötigen, einen Bereich außerhalb der Fixierung erfordert.

Verwenden Sie dynamische Header für benutzerdefinierte Authentifizierung

Wenn Ihr MCP-Server ein anderes Authentifizierungsschema verwendet als OAuth (wie Kerberos, kurzlebige Token oder ein internes SSO), verwenden Sie headersHelper, um Request-Header zur Verbindungszeit zu generieren. Claude Code führt den Befehl aus und fügt seine Ausgabe in die Verbindungs-Header ein.

{
  "mcpServers": {
    "internal-api": {
      "type": "http",
      "url": "https://mcp.internal.example.com",
      "headersHelper": "/opt/bin/get-mcp-auth-headers.sh"
    }
  }
}

Der Befehl kann auch inline sein:

{
  "mcpServers": {
    "internal-api": {
      "type": "http",
      "url": "https://mcp.internal.example.com",
      "headersHelper": "echo '{\"Authorization\": \"Bearer '\"$(get-token)\"'\"}'"
    }
  }
}

Anforderungen:

  • Der Befehl muss ein JSON-Objekt mit String-Schlüssel-Wert-Paaren auf stdout schreiben
  • Der Befehl wird in einer Shell mit einem 10-Sekunden-Timeout ausgeführt
  • Dynamische Header überschreiben alle statischen headers mit dem gleichen Namen

Der Helper wird bei jeder Verbindung neu ausgeführt (beim Sitzungsstart und bei Wiederverbindung). Es gibt kein Caching, daher ist Ihr Skript für jede Token-Wiederverwendung verantwortlich.

Claude Code setzt diese Umgebungsvariablen beim Ausführen des Helpers:

Variable Wert
CLAUDE_CODE_MCP_SERVER_NAME der Name des MCP-Servers
CLAUDE_CODE_MCP_SERVER_URL die URL des MCP-Servers

Verwenden Sie diese, um ein einzelnes Helper-Skript zu schreiben, das mehrere MCP-Server bedient.

MCP-Server aus JSON-Konfiguration hinzufügen

Wenn Sie eine JSON-Konfiguration für einen MCP-Server haben, können Sie sie direkt hinzufügen:

1

Fügen Sie einen MCP-Server aus JSON hinzu

# Grundlegende Syntax
claude mcp add-json <name> '<json>'

# Beispiel: Hinzufügen eines HTTP-Servers mit JSON-Konfiguration
claude mcp add-json weather-api '{"type":"http","url":"https://api.weather.com/mcp","headers":{"Authorization":"Bearer token"}}'

# Beispiel: Hinzufügen eines Stdio-Servers mit JSON-Konfiguration
claude mcp add-json local-weather '{"type":"stdio","command":"/path/to/weather-cli","args":["--api-key","abc123"],"env":{"CACHE_DIR":"/tmp"}}'

# Beispiel: Hinzufügen eines HTTP-Servers mit vorkonfigurierten OAuth-Anmeldedaten
claude mcp add-json my-server '{"type":"http","url":"https://mcp.example.com/mcp","oauth":{"clientId":"your-client-id","callbackPort":8080}}' --client-secret
2

Überprüfen Sie, dass der Server hinzugefügt wurde

claude mcp get weather-api

MCP-Server aus Claude Desktop importieren

Wenn Sie bereits MCP-Server in Claude Desktop konfiguriert haben, können Sie diese importieren:

1

Importieren Sie Server aus Claude Desktop

# Grundlegende Syntax 
claude mcp add-from-claude-desktop
2

Wählen Sie aus, welche Server importiert werden sollen

Nach dem Ausführen des Befehls wird ein interaktives Dialogfeld angezeigt, in dem Sie auswählen können, welche Server Sie importieren möchten.

3

Überprüfen Sie, dass die Server importiert wurden

claude mcp list

MCP-Server von Claude.ai verwenden

Wenn Sie sich in Claude Code mit einem Claude.ai-Konto angemeldet haben, sind MCP-Server, die Sie in Claude.ai hinzugefügt haben, automatisch in Claude Code verfügbar:

1

Konfigurieren Sie MCP-Server in Claude.ai

Fügen Sie Server unter claude.ai/customize/connectors hinzu. Bei Team- und Enterprise-Plänen können nur Administratoren Server hinzufügen.

2

Authentifizieren Sie den MCP-Server

Führen Sie alle erforderlichen Authentifizierungsschritte in Claude.ai durch.

3

Zeigen Sie Server in Claude Code an und verwalten Sie sie

In Claude Code verwenden Sie den Befehl:

/mcp

Claude.ai-Server erscheinen in der Liste mit Indikatoren, die zeigen, dass sie von Claude.ai stammen.

Um Claude.ai-MCP-Server in Claude Code zu deaktivieren, setzen Sie die Umgebungsvariable ENABLE_CLAUDEAI_MCP_SERVERS auf false:

ENABLE_CLAUDEAI_MCP_SERVERS=false claude

Claude Code als MCP-Server verwenden

Sie können Claude Code selbst als MCP-Server verwenden, mit dem sich andere Anwendungen verbinden können:

# Starten Sie Claude als Stdio-MCP-Server
claude mcp serve

Sie können dies in Claude Desktop verwenden, indem Sie diese Konfiguration zu claude_desktop_config.json hinzufügen:

{
  "mcpServers": {
    "claude-code": {
      "type": "stdio",
      "command": "claude",
      "args": ["mcp", "serve"],
      "env": {}
    }
  }
}

MCP-Ausgabelimits und Warnungen

Wenn MCP-Tools große Ausgaben erzeugen, hilft Claude Code bei der Verwaltung der Token-Nutzung, um zu verhindern, dass Ihr Gesprächskontext überwältigt wird:

  • Ausgabe-Warnungsschwelle: Claude Code zeigt eine Warnung an, wenn eine MCP-Tool-Ausgabe 10.000 Token überschreitet
  • Konfigurierbares Limit: Sie können die maximale zulässige MCP-Ausgabe-Token mit der Umgebungsvariablen MAX_MCP_OUTPUT_TOKENS anpassen
  • Standardlimit: Das Standardmaximum beträgt 25.000 Token
  • Bereich: Die Umgebungsvariable gilt für Tools, die kein eigenes Limit deklarieren. Tools, die anthropic/maxResultSizeChars setzen, verwenden diesen Wert stattdessen für Textinhalte, unabhängig davon, auf was MAX_MCP_OUTPUT_TOKENS gesetzt ist. Tools, die Bilddaten zurückgeben, unterliegen immer noch MAX_MCP_OUTPUT_TOKENS

Um das Limit für Tools zu erhöhen, die große Ausgaben erzeugen:

export MAX_MCP_OUTPUT_TOKENS=50000
claude

Dies ist besonders nützlich bei der Arbeit mit MCP-Servern, die:

  • Große Datensätze oder Datenbanken abfragen
  • Detaillierte Berichte oder Dokumentation generieren
  • Umfangreiche Protokolldateien oder Debugging-Informationen verarbeiten

Erhöhen Sie das Limit für ein bestimmtes Tool

Wenn Sie einen MCP-Server erstellen, können Sie einzelnen Tools ermöglichen, Ergebnisse größer als die Standard-Persist-to-Disk-Schwelle zurückzugeben, indem Sie _meta["anthropic/maxResultSizeChars"] in der Tool-Antwort des tools/list einstellen. Claude Code erhöht die Schwelle dieses Tools auf den annotierten Wert, bis zu einer harten Obergrenze von 500.000 Zeichen.

Dies ist nützlich für Tools, die inhärent große, aber notwendige Ausgaben zurückgeben, wie Datenbankschemas oder vollständige Dateibäume. Ohne die Anmerkung werden Ergebnisse, die die Standard-Schwelle überschreiten, auf die Festplatte persistiert und durch eine Dateireferenz im Gespräch ersetzt.

{
  "name": "get_schema",
  "description": "Returns the full database schema",
  "_meta": {
    "anthropic/maxResultSizeChars": 200000
  }
}

Die Anmerkung gilt unabhängig von MAX_MCP_OUTPUT_TOKENS für Textinhalte, daher müssen Benutzer die Umgebungsvariable nicht für Tools erhöhen, die sie deklarieren. Tools, die Bilddaten zurückgeben, unterliegen immer noch dem Token-Limit.

Reagieren Sie auf MCP-Elicitierungsanfragen

MCP-Server können während einer Aufgabe strukturierte Eingaben von Ihnen anfordern, indem sie Elicitierung verwenden. Wenn ein Server Informationen benötigt, die er nicht selbst abrufen kann, zeigt Claude Code einen interaktiven Dialog an und leitet Ihre Antwort an den Server weiter. Auf Ihrer Seite ist keine Konfiguration erforderlich: Elicitierungs-Dialoge erscheinen automatisch, wenn ein Server sie anfordert.

Server können Eingaben auf zwei Arten anfordern:

  • Formularmodus: Claude Code zeigt einen Dialog mit Formularfeldern an, die vom Server definiert werden (zum Beispiel eine Eingabeaufforderung für Benutzername und Passwort). Füllen Sie die Felder aus und senden Sie sie ab.
  • URL-Modus: Claude Code öffnet eine Browser-URL für Authentifizierung oder Genehmigung. Führen Sie den Ablauf im Browser durch und bestätigen Sie dann in der CLI.

Um automatisch auf Elicitierungsanfragen ohne Dialog zu reagieren, verwenden Sie den Elicitation-Hook.

Wenn Sie einen MCP-Server erstellen, der Elicitierung verwendet, siehe die MCP-Elicitierungs-Spezifikation für Protokolldetails und Schema-Beispiele.

MCP-Ressourcen verwenden

MCP-Server können Ressourcen verfügbar machen, auf die Sie mit @-Erwähnungen verweisen können, ähnlich wie Sie auf Dateien verweisen.

Referenzieren Sie MCP-Ressourcen

1

Verfügbare Ressourcen auflisten

Geben Sie @ in Ihre Eingabeaufforderung ein, um verfügbare Ressourcen von allen verbundenen MCP-Servern anzuzeigen. Ressourcen erscheinen neben Dateien im Autocomplete-Menü.

2

Referenzieren Sie eine bestimmte Ressource

Verwenden Sie das Format @server:protocol://resource/path, um auf eine Ressource zu verweisen:

Can you analyze @github:issue://123 and suggest a fix?

Please review the API documentation at @docs:file://api/authentication
3

Mehrere Ressourcenreferenzen

Sie können mehrere Ressourcen in einer einzelnen Eingabeaufforderung referenzieren:

Compare @postgres:schema://users with @docs:file://database/user-model

Mit MCP-Tool-Suche skalieren

Die Tool-Suche hält die MCP-Kontextnutzung niedrig, indem Tool-Definitionen aufgeschoben werden, bis Claude sie benötigt. Nur Tool-Namen werden beim Sitzungsstart geladen, daher hat das Hinzufügen weiterer MCP-Server minimale Auswirkungen auf Ihr Kontextfenster.

Wie es funktioniert

Die Tool-Suche ist standardmäßig aktiviert. MCP-Tools werden aufgeschoben, anstatt sie vorab in den Kontext zu laden, und Claude verwendet ein Such-Tool, um relevante Tools zu entdecken, wenn eine Aufgabe sie benötigt. Nur die Tools, die Claude tatsächlich verwendet, gelangen in den Kontext. Aus Ihrer Perspektive funktionieren MCP-Tools genau wie zuvor.

Wenn Sie schwellenwertbasiertes Laden bevorzugen, setzen Sie ENABLE_TOOL_SEARCH=auto, um Schemas vorab zu laden, wenn sie in 10 % des Kontextfensters passen, und verschieben Sie nur den Überschuss. Siehe Tool-Suche konfigurieren für alle Optionen.

Für MCP-Server-Autoren

Wenn Sie einen MCP-Server erstellen, wird das Feld für Server-Anweisungen mit aktivierter Tool-Suche nützlicher. Server-Anweisungen helfen Claude zu verstehen, wann nach Ihren Tools gesucht werden soll, ähnlich wie Skills funktionieren.

Fügen Sie klare, aussagekräftige Server-Anweisungen hinzu, die erklären:

  • Welche Kategorie von Aufgaben Ihre Tools verarbeiten
  • Wann Claude nach Ihren Tools suchen sollte
  • Wichtige Funktionen, die Ihr Server bietet

Claude Code schneidet Tool-Beschreibungen und Server-Anweisungen bei 2 KB ab. Halten Sie sie prägnant, um Kürzungen zu vermeiden, und platzieren Sie kritische Details am Anfang.

Tool-Suche konfigurieren

Die Tool-Suche ist standardmäßig aktiviert: MCP-Tools werden aufgeschoben und bei Bedarf entdeckt. Sie ist standardmäßig auf Vertex AI deaktiviert, das den Tool-Search-Beta-Header nicht akzeptiert, und wenn ANTHROPIC_BASE_URL auf einen Host von Drittanbietern verweist, da die meisten Proxys tool_reference-Blöcke nicht weiterleiten. Legen Sie ENABLE_TOOL_SEARCH explizit fest, um sich anzumelden. Diese Funktion erfordert Modelle, die tool_reference-Blöcke unterstützen: Sonnet 4 und später oder Opus 4 und später. Haiku-Modelle unterstützen die Tool-Suche nicht.

Steuern Sie das Verhalten der Tool-Suche mit der Umgebungsvariablen ENABLE_TOOL_SEARCH:

Wert Verhalten
(nicht gesetzt) Alle MCP-Tools werden aufgeschoben und bei Bedarf geladen. Fällt auf das Laden vorab zurück auf Vertex AI oder wenn ANTHROPIC_BASE_URL ein Host von Drittanbietern ist
true Alle MCP-Tools werden aufgeschoben, auch auf Vertex AI und für ANTHROPIC_BASE_URL von Drittanbietern
auto Schwellenmodus: Tools werden vorab geladen, wenn sie in 10 % des Kontextfensters passen, andernfalls aufgeschoben
auto:<N> Schwellenmodus mit benutzerdefiniertem Prozentsatz, wobei <N> 0-100 ist (z. B. auto:5 für 5 %)
false Alle MCP-Tools werden vorab geladen, keine Verschiebung 
# Verwenden Sie eine benutzerdefinierte 5%-Schwelle
ENABLE_TOOL_SEARCH=auto:5 claude

# Deaktivieren Sie die Tool-Suche vollständig
ENABLE_TOOL_SEARCH=false claude

Oder legen Sie den Wert im Feld env Ihrer settings.json fest.

Sie können das ToolSearch-Tool auch spezifisch deaktivieren:

{
  "permissions": {
    "deny": ["ToolSearch"]
  }
}

Einen Server von der Verschiebung ausnehmen

Wenn die Tools eines Servers für Claude immer sichtbar sein sollten, ohne einen Suchschritt durchzuführen, setzen Sie alwaysLoad in der Konfiguration dieses Servers auf true. Jedes Tool von diesem Server wird dann beim Sitzungsstart in den Kontext geladen, unabhängig von der Einstellung ENABLE_TOOL_SEARCH. Verwenden Sie dies für eine kleine Anzahl von Tools, die Claude bei jedem Durchgang benötigt, da jedes vorab geladene Tool Kontext verbraucht, der sonst für Ihr Gespräch verfügbar wäre.

Der folgende .mcp.json-Eintrag nimmt einen HTTP-Server von der Verschiebung aus, während andere Server aufgeschoben bleiben:

{
  "mcpServers": {
    "core-tools": {
      "type": "http",
      "url": "https://mcp.example.com/mcp",
      "alwaysLoad": true
    }
  }
}

Das Feld alwaysLoad ist auf allen Server-Typen verfügbar und erfordert Claude Code v2.1.121 oder später. Ein MCP-Server kann auch einzelne Tools als immer geladen markieren, indem "anthropic/alwaysLoad": true im _meta-Objekt des Tools enthalten ist, was denselben Effekt nur für dieses Tool hat.

MCP-Prompts als Befehle verwenden

MCP-Server können Prompts verfügbar machen, die in Claude Code als Befehle verfügbar werden.

Führen Sie MCP-Prompts aus

1

Entdecken Sie verfügbare Prompts

Geben Sie / ein, um alle verfügbaren Befehle anzuzeigen, einschließlich derer von MCP-Servern. MCP-Prompts erscheinen mit dem Format /mcp__servername__promptname.

2

Führen Sie einen Prompt ohne Argumente aus

/mcp__github__list_prs
3

Führen Sie einen Prompt mit Argumenten aus

Viele Prompts akzeptieren Argumente. Übergeben Sie sie durch Leerzeichen getrennt nach dem Befehl:

/mcp__github__pr_review 456

/mcp__jira__create_issue "Bug in login flow" high

Verwaltete MCP-Konfiguration

Für Organisationen, die eine zentralisierte Kontrolle über MCP-Server benötigen, unterstützt Claude Code zwei Konfigurationsoptionen:

  1. Exklusive Kontrolle mit managed-mcp.json: Stellen Sie einen festen Satz von MCP-Servern bereit, die Benutzer nicht ändern oder erweitern können
  2. Richtlinienbasierte Kontrolle mit Allowlists/Denylists: Ermöglichen Sie Benutzern, ihre eigenen Server hinzuzufügen, aber beschränken Sie, welche zulässig sind

Diese Optionen ermöglichen IT-Administratoren:

  • Kontrollieren Sie, auf welche MCP-Server Mitarbeiter zugreifen können: Stellen Sie einen standardisierten Satz genehmigter MCP-Server in der gesamten Organisation bereit
  • Verhindern Sie nicht autorisierte MCP-Server: Beschränken Sie Benutzer daran, nicht genehmigte MCP-Server hinzuzufügen
  • Deaktivieren Sie MCP vollständig: Entfernen Sie die MCP-Funktionalität vollständig, falls erforderlich

Option 1: Exklusive Kontrolle mit managed-mcp.json

Wenn Sie eine managed-mcp.json-Datei bereitstellen, übernimmt sie die exklusive Kontrolle über alle MCP-Server. Benutzer können keine MCP-Server außer denen, die in dieser Datei definiert sind, hinzufügen, ändern oder verwenden. Dies ist der einfachste Ansatz für Organisationen, die vollständige Kontrolle wünschen.

Systemadministratoren stellen die Konfigurationsdatei in einem systemweiten Verzeichnis bereit:

  • macOS: /Library/Application Support/ClaudeCode/managed-mcp.json
  • Linux und WSL: /etc/claude-code/managed-mcp.json
  • Windows: C:\Program Files\ClaudeCode\managed-mcp.json

Die managed-mcp.json-Datei verwendet das gleiche Format wie eine Standard-.mcp.json-Datei:

{
  "mcpServers": {
    "github": {
      "type": "http",
      "url": "https://api.githubcopilot.com/mcp/"
    },
    "sentry": {
      "type": "http",
      "url": "https://mcp.sentry.dev/mcp"
    },
    "company-internal": {
      "type": "stdio",
      "command": "/usr/local/bin/company-mcp-server",
      "args": ["--config", "/etc/company/mcp-config.json"],
      "env": {
        "COMPANY_API_URL": "https://internal.company.com"
      }
    }
  }
}

Option 2: Richtlinienbasierte Kontrolle mit Allowlists und Denylists

Anstatt exklusive Kontrolle zu übernehmen, können Administratoren Benutzern erlauben, ihre eigenen MCP-Server zu konfigurieren, während sie Einschränkungen durchsetzen, welche Server zulässig sind. Dieser Ansatz verwendet allowedMcpServers und deniedMcpServers in der verwalteten Einstellungsdatei.

Einschränkungsoptionen

Jeder Eintrag in der Allowlist oder Denylist kann Server auf drei Arten einschränken:

  1. Nach Servername (serverName): Entspricht dem konfigurierten Namen des Servers
  2. Nach Befehl (serverCommand): Entspricht dem genauen Befehl und den Argumenten, die zum Starten von Stdio-Servern verwendet werden
  3. Nach URL-Muster (serverUrl): Entspricht Remote-Server-URLs mit Wildcard-Unterstützung

Wichtig: Jeder Eintrag muss genau einen von serverName, serverCommand oder serverUrl haben.

Beispielkonfiguration

{
  "allowedMcpServers": [
    // Nach Servername zulassen
    { "serverName": "github" },
    { "serverName": "sentry" },

    // Nach exaktem Befehl zulassen (für Stdio-Server)
    { "serverCommand": ["npx", "-y", "@modelcontextprotocol/server-filesystem"] },
    { "serverCommand": ["python", "/usr/local/bin/approved-server.py"] },

    // Nach URL-Muster zulassen (für Remote-Server)
    { "serverUrl": "https://mcp.company.com/*" },
    { "serverUrl": "https://*.internal.corp/*" }
  ],
  "deniedMcpServers": [
    // Nach Servername blockieren
    { "serverName": "dangerous-server" },

    // Nach exaktem Befehl blockieren (für Stdio-Server)
    { "serverCommand": ["npx", "-y", "unapproved-package"] },

    // Nach URL-Muster blockieren (für Remote-Server)
    { "serverUrl": "https://*.untrusted.com/*" }
  ]
}

Wie befehlsbasierte Einschränkungen funktionieren

Exakte Übereinstimmung:

  • Befehlsarrays müssen genau übereinstimmen – sowohl der Befehl als auch alle Argumente in der richtigen Reihenfolge
  • Beispiel: ["npx", "-y", "server"] entspricht NICHT ["npx", "server"] oder ["npx", "-y", "server", "--flag"]

Stdio-Server-Verhalten:

  • Wenn die Allowlist irgendwelche serverCommand-Einträge enthält, müssen Stdio-Server einem dieser Befehle entsprechen
  • Stdio-Server können nicht allein nach Name bestehen, wenn Befehlsbeschränkungen vorhanden sind
  • Dies stellt sicher, dass Administratoren erzwingen können, welche Befehle ausgeführt werden dürfen

Verhalten von Remote-Servern:

  • Remote-Server (HTTP, SSE, WebSocket) verwenden URL-basierte Übereinstimmung, wenn serverUrl-Einträge in der Allowlist vorhanden sind
  • Wenn keine URL-Einträge vorhanden sind, greifen Remote-Server auf namensbasierte Übereinstimmung zurück
  • Befehlsbeschränkungen gelten nicht für Remote-Server

Wie URL-basierte Einschränkungen funktionieren

URL-Muster unterstützen Wildcards mit *, um eine beliebige Zeichenfolge zu entsprechen. Dies ist nützlich, um ganze Domänen oder Subdomänen zuzulassen.

Wildcard-Beispiele:

  • https://mcp.company.com/* – Alle Pfade auf einer bestimmten Domäne zulassen
  • https://*.example.com/* – Jede Subdomain von example.com zulassen
  • http://localhost:*/* – Jeden Port auf localhost zulassen

Verhalten von Remote-Servern:

  • Wenn die Allowlist irgendwelche serverUrl-Einträge enthält, müssen Remote-Server einem dieser URL-Muster entsprechen
  • Remote-Server können nicht allein nach Name bestehen, wenn URL-Beschränkungen vorhanden sind
  • Dies stellt sicher, dass Administratoren erzwingen können, welche Remote-Endpunkte zulässig sind
Beispiel: Nur-URL-Allowlist 
{
"allowedMcpServers": [
{ "serverUrl": "https://mcp.company.com/*" },
{ "serverUrl": "https://*.internal.corp/*" }
]
}

Ergebnis:

  • HTTP-Server unter https://mcp.company.com/api: ✅ Zulässig (entspricht URL-Muster)
  • HTTP-Server unter https://api.internal.corp/mcp: ✅ Zulässig (entspricht Wildcard-Subdomain)
  • HTTP-Server unter https://external.com/mcp: ❌ Blockiert (entspricht keinem URL-Muster)
  • Stdio-Server mit beliebigem Befehl: ❌ Blockiert (keine Namen- oder Befehlseinträge zum Abgleichen)
Beispiel: Nur-Befehl-Allowlist 
{
"allowedMcpServers": [
{ "serverCommand": ["npx", "-y", "approved-package"] }
]
}

Ergebnis:

  • Stdio-Server mit ["npx", "-y", "approved-package"]: ✅ Zulässig (entspricht Befehl)
  • Stdio-Server mit ["node", "server.js"]: ❌ Blockiert (entspricht nicht dem Befehl)
  • HTTP-Server mit Namen „my-api": ❌ Blockiert (keine Nameneinträge zum Abgleichen)
Beispiel: Gemischte Namen- und Befehl-Allowlist 
{
"allowedMcpServers": [
{ "serverName": "github" },
{ "serverCommand": ["npx", "-y", "approved-package"] }
]
}

Ergebnis:

  • Stdio-Server mit Namen „local-tool" und ["npx", "-y", "approved-package"]: ✅ Zulässig (entspricht Befehl)
  • Stdio-Server mit Namen „local-tool" und ["node", "server.js"]: ❌ Blockiert (Befehlseinträge vorhanden, aber entspricht nicht)
  • Stdio-Server mit Namen „github" und ["node", "server.js"]: ❌ Blockiert (Stdio-Server müssen Befehlen entsprechen, wenn Befehlseinträge vorhanden sind)
  • HTTP-Server mit Namen „github": ✅ Zulässig (entspricht Name)
  • HTTP-Server mit Namen „other-api": ❌ Blockiert (Name entspricht nicht)
Beispiel: Nur-Namen-Allowlist 
{
"allowedMcpServers": [
{ "serverName": "github" },
{ "serverName": "internal-tool" }
]
}

Ergebnis:

  • Stdio-Server mit Namen „github" und beliebigem Befehl: ✅ Zulässig (keine Befehlsbeschränkungen)
  • Stdio-Server mit Namen „internal-tool" und beliebigem Befehl: ✅ Zulässig (keine Befehlsbeschränkungen)
  • HTTP-Server mit Namen „github": ✅ Zulässig (entspricht Name)
  • Beliebiger Server mit Namen „other": ❌ Blockiert (Name entspricht nicht)

Allowlist-Verhalten (allowedMcpServers)

  • undefined (Standard): Keine Einschränkungen – Benutzer können jeden MCP-Server konfigurieren
  • Leeres Array []: Vollständige Sperrung – Benutzer können keinen MCP-Server konfigurieren
  • Liste von Einträgen: Benutzer können nur Server konfigurieren, die nach Name, Befehl oder URL-Muster übereinstimmen

Denylist-Verhalten (deniedMcpServers)

  • undefined (Standard): Keine Server werden blockiert
  • Leeres Array []: Keine Server werden blockiert
  • Liste von Einträgen: Angegebene Server werden über alle Bereiche hinweg explizit blockiert

Wichtige Hinweise

  • Option 1 und Option 2 können kombiniert werden: Wenn managed-mcp.json vorhanden ist, hat es exklusive Kontrolle und Benutzer können keine Server hinzufügen. Allowlists/Denylists gelten immer noch für die verwalteten Server selbst.
  • Denylist hat absolute Vorrang: Wenn ein Server einem Denylist-Eintrag entspricht (nach Name, Befehl oder URL), wird er blockiert, auch wenn er auf der Allowlist ist
  • Namensbasierte, befehlsbasierte und URL-basierte Einschränkungen funktionieren zusammen: Ein Server wird zugelassen, wenn er einem Namenseintrag, einem Befehlseintrag oder einem URL-Muster entspricht (es sei denn, er wird durch Denylist blockiert)