Zum Hauptinhalt springen
Sie möchten, dass Ihre Agenten einen Model-Context-Protocol-(MCP-)Server nutzen — Ihren eigenen Remote-Server oder den mitgelieferten — aber Sie möchten, dass jeder Tool-Call, den er exponiert, hinter einem einzigen auditierten Engpass läuft. Der erste Schritt ist, den Server in Ihrem Workspace zu registrieren: ein Name, ein Endpunkt, ein Auth-Modus und seine Credentials. Sobald er registriert ist, bietet das MCP-Gateway seine Tools unter einer Verbindung an und wertet jeden tools/call durch Ihre Firewall-Policy aus, bevor er den echten Server erreicht. Diese Seite behandelt diese eine Aufgabe — einen Server-Datensatz anbinden und konfigurieren. Für das Runtime-Verhalten des Gateways und die Verdikte pro Aufruf siehe die MCP-Referenz; für das größere Bild starten Sie beim MCP-Sicherheit-Überblick.
Die Registrierung ist eine Konsolen-Aktion (die /api/workspace/firewall/*-Routen authentifizieren mit Ihrem Session-/ Access-Token, nicht mit einem Relay-sk-orca-…-Key). Schreibvorgänge erfordern die Developer+-Rolle; jedes Mitglied kann Server auflisten.

​
1. Wie man einen MCP-Server anbindet

Öffnen Sie Firewall → MCP Servers in der Konsole und fügen Sie einen Server hinzu, oder rufen Sie die Workspace-API direkt auf. Eine Registrierung trägt vier Dinge, die zählen:

name

Eindeutig pro Workspace. Er wird zum <server>.<tool>-Namespace-Präfix, sodass ein doppelter Name im selben Workspace mit HTTP 409 abgelehnt wird.

endpoint

Die URL Ihres Remote-MCP-Servers. Lassen Sie ihn leer, um den mitgelieferten In-Process-Server zu registrieren, sodass er sichtbar und steuerbar ist.

auth_mode

Wie sich das Gateway bei Ihrem Server authentifiziert: none, bearer, oauth oder basic.

credentials

Das modus-spezifische Secret. Gespeichert verschlüsselt im Ruhezustand und beim Lesen maskiert — es erreicht nie das Modell oder den Client.
Ein Server startet enabled und wird gänzlich aus dem Gateway weggelassen, in dem Moment, in dem Sie ihn deaktivieren — das ist der Aus-Schalter, und die Credentials eines deaktivierten Servers werden nie entschlüsselt.

​
2. Ein konkretes Beispiel

Registrieren Sie einen Remote-GitHub-MCP-Server mit einem Bearer-Token. Dies ist ein konsolen-äquivalenter REST-Aufruf; die Feldnamen sind exakt das, was das Formular schreibt. 
curl https://api.orcarouter.ai/api/workspace/firewall/mcp_servers \
  -H "Authorization: Bearer <your-session-or-access-token>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "github",
    "endpoint": "https://api.githubcopilot.com/mcp",
    "auth_mode": "bearer",
    "auth_json": "{\"token\":\"ghp_x\"}",
    "enabled": true
  }'
Die Credential-Form hängt von auth_mode ab:
{"token":"…"} — als Bearer-Token an Ihren Server gesendet.
{"access_token":"…"} — ein statisches Access-Token, das das Gateway als Bearer-Header sendet. Automatischer Client-Credentials-Austausch wird noch nicht unterstützt; ohne ein gespeichertes access_token schlägt ein Probe im oauth-Modus fehl, statt sich unauthentifiziert zu verbinden.
{"username":"…","password":"…"}.
Ein leerer String. Es werden keine Credentials angehängt.
Beim Lesen werden sowohl das Credential als auch der Endpunkt maskiert — die API gibt Sentinel-Platzhalter zurück, nicht die Rohwerte. Wenn Sie einen Server aktualisieren, spiegeln Sie diese Platzhalter unverändert zurück, um die gespeicherten Werte zu behalten; senden Sie ein frisches auth_json nur, wenn Sie das Secret tatsächlich rotieren. Siehe Credential-Rotation.

​
3. Erreichbarkeit proben

Bevor Sie Firewall-Regeln gegen die Tools eines Servers schreiben können, müssen Sie wissen, dass sie erreichbar sind und wie sie heißen. Proben Sie den Server — das Gateway führt einen MCP-initialize + tools/list-Handshake mit den entschlüsselten Credentials aus, zeichnet die Erreichbarkeit auf und gibt die angebotenen Tools zurück: 
curl -X POST \
  https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/42/probe \
  -H "Authorization: Bearer <your-session-or-access-token>"

{
  "status": "ok",
  "last_checked_at": 1700000000,
  "tools": [
    { "name": "create_issue", "description": "…", "input_schema": {} }
  ]
}
Der status landet im Server-Datensatz und steuert den Erreichbarkeits-Indikator:
statusBedeutung
okErreichbar; Tools werden vom Gateway bedient.
degradedErreichbar, aber der Handshake war partiell.
downBeim letzten Probe nicht erreichbar; der Server wird übersprungen.
Ein down-Server wird ausgelassen, wenn das Gateway seinen Tool-Satz baut, sodass ein vorübergehender Ausfall sich anmutig abbaut, statt den Dispatch zu brechen. Ein Probe gibt sein Ergebnis unabhängig vom Ausgang zurück — ein fehlgeschlagenes Probe kommt als 200 mit status: down und einem bereinigten Grund zurück, nicht als Transportfehler.
Der mitgelieferte In-Process-Server (leeres endpoint) dispatcht lokal und ist nicht probebar — sein Proben wird mit einem Fehler abgelehnt, der erklärt, dass die Registrierung keinen Endpunkt hat. Sie proben nur BYO-Server, die eine URL haben.
Jede Registrierungsänderung invalidiert den Pro-Workspace-Tool-Cache des Gateways sofort, sodass ein neu angebundener, deaktivierter oder neu geprobter Server bei der nächsten Verbindung wirksam wird statt nach einem Cache-Fenster.

​
4. Nachdem er angebunden ist

Sobald ein Server registriert ist und ok probt, sind seine Tools gesteuert:
  • Jeder Aufruf wird ausgewertet. Jeder tools/call läuft durch Ihre Firewall-Policy auf der mcp-Oberfläche, bevor er Ihren Server erreicht. Scopen Sie Regeln per tool_name_glob: github.*, jetzt, da Sie die Tool-Namen kennen.
  • Sperren Sie die Oberfläche ab. Verweigern Sie standardmäßig Tools, die Sie nicht explizit erlaubt haben — siehe MCP-Tools per Allowlist.
  • Steuern Sie, wohin er reicht. Verfassen Sie eine Egress-Regel, damit ein Tool keine beliebigen Hosts abrufen kann.
  • Achten Sie auf Änderungen. Ein Server, dem Sie vertraut haben, kann seine Tool-Definitionen im Nachhinein ändern; die Rug-Pull-Abwehr markiert diese Drift.

​
5. API-Referenz

Alle Konsolen-Routen sind workspace-bezogen und authentifizieren mit Ihrem Session-/Access-Token. List-Lesezugriffe sind für jedes Member offen (Secrets maskiert); jeder Schreibvorgang erfordert Developer+.
Methode & PfadRolleZweck
GET /api/workspace/firewall/mcp_serversMemberServer auflisten (Secrets + Endpunkt maskiert).
GET /api/workspace/firewall/mcp_servers/:idMemberEinzelner Server, maskiert.
POST /api/workspace/firewall/mcp_serversDeveloper+Einen Server registrieren (409 bei doppeltem Namen).
PUT /api/workspace/firewall/mcp_serversDeveloper+Einen Server aktualisieren (id im Body).
DELETE /api/workspace/firewall/mcp_servers/:idDeveloper+Soft-Delete; gibt den Namen frei.
POST /api/workspace/firewall/mcp_servers/:id/probeDeveloper+Erreichbarkeit proben + Tools entdecken.
Der SDK-Proxy eines Agenten liest die Runtime-Registry über das gateway-scoped Token bei GET /api/v1/firewall/mcp_servers (nur aktivierte Server). Wie man diese Seite authentifiziert, siehe das MCP-Gateway authentifizieren.
Warum überhaupt durch OrcaRouter anbinden? Damit ein Ort jeden Tool-Call sieht — eine Verbindung, eine Policy, ein auditiertes Log und Credentials, die beim Dispatch injiziert werden, statt verstreut über Agenten-Konfigurationen. Lesen Sie KI-Agenten absichern und die MCP-Tool-Poisoning-Bedrohung für die Motivation.

​
Verwandt

MCP-Sicherheit – Überblick

Das vollständige MCP-Governance-Modell, von Anfang bis Ende.

Firewall: MCP-Server

Das Runtime-Verhalten des Gateways und die Verdikte pro Aufruf.

Das Gateway authentifizieren

Prägen und scopen Sie das Token, mit dem sich Ihr Agent verbindet.

Trust-Checkliste

Alles, was zu verifizieren ist, bevor Sie einem neuen Server vertrauen.