MCP-Tools

Externe Tool-Server hinter derselben Compliance-Schleuse, mit Grants pro Schlüssel, standardmäßig verweigert.

Registrieren Sie externe MCP-Tool-Server (HTTP, SSE oder stdio) in der Console mit Residency-Tags; Auth-Secrets werden im Credential-Vault versiegelt und niemals zurückgegeben.

Jeder Tool-Aufruf durchläuft dieselbe Schleuse wie eine Chat Completion: Prüfen (Datenschutz auf den Argumenten), Routen (Residency auf dem Server), Versiegeln (Audit-Kette), Messen (Rate und Budget). Tool-Grants gelten pro Key und sind standardmäßig verboten. Sluis beantwortet außerdem POST /v1/mcp selbst als MCP-Server und stellt genau die Tools bereit, die dem aufrufenden Key gewährt sind.

# list the tools this key is granted (deny-by-default)
curl https://api.sluis.ai/v1/mcp \
  -H "Authorization: Bearer $SLUIS_KEY" \
  -d '{ "jsonrpc": "2.0", "id": 1, "method": "tools/list" }'

# every tools/call clears Inspect → Route → Seal → Meter

# invoke a granted tool — the call clears Inspect → Route → Seal → Meter
curl https://api.sluis.ai/v1/mcp \
  -H "Authorization: Bearer $SLUIS_KEY" \
  -d '{ "jsonrpc": "2.0", "id": 2, "method": "tools/call",
        "params": { "name": "crm.lookup", "arguments": { "email": "j.devries@acme.nl" } } }'

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "content": [{ "type": "text", "text": "1 match: account 8817, status active" }]
  }
}

MCP-Authentifizierung: zwei Richtungen

Statische Server-Zugangsdaten

Verwenden Sie headers für feste Header. Der bisherige Wert oauth bezeichnet ein statisches OAuth-Bearer-Token im Vault, keine Browser-Anmeldung.

Kontomodus

Bei interaktivem OAuth: Organisation (account_mode=organization) verwendet eine gemeinsame Identität, die ein Admin ausdrücklich per OAuth verbindet. Persönliche Zugangsdaten werden nie wiederverwendet. Jeder Benutzer (account_mode=user) verwendet nur die Verbindung des handelnden Mitglieds. Die Authentifizierung ist davon getrennt: Interaktives OAuth verwendet user_oauth; der bisherige Wert oauth bleibt ein statisches Bearer-Token.

Persönliche Upstream-Verbindungen

Melden Sie sich im Modus Jeder Benutzer unter Workspace → Einstellungen → Verbindungen beim externen Dienst an. Von Admins hinzugefügte Server müssen zuerst für Workspace freigegeben werden. Eine Verbindung umgeht weder Tool-Berechtigungen noch Residency, Datenschutz oder Budgets. Admins können den Status einsehen und Verbindungen widerrufen, aber nicht die Identität anderer Mitglieder nutzen. Aufrufe ohne Benutzeridentität, einschließlich organisationsweiter Schlüssel, werden in diesem Modus abgewiesen. GET/PUT /chat/settings bietet mcp_enabled (Boolean, standardmäßig true für neue Organisationen, ältere Einstellungen und ein fehlendes Antwortfeld). Wird es bei PUT weggelassen, bleibt der aktuelle Wert erhalten, auch false. Bei false entdeckt Workspace keine MCP-Tools und verweigert deren Ausführung, auch bei zuvor entdeckten Tools in bestehenden Gesprächen, Agents und Subagents. Registrierungen, Genehmigungen, Berechtigungen und Zugangsdaten bleiben erhalten. Externe /agent/mcp, /v1/mcp und der Playground der Konsole bleiben unverändert. Die Registrierungsrichtlinie für persönliche Server bleibt unabhängig und organisationsweit. Eigentümer und Admins schalten dies mit MCP-Tools in Workspace-Gesprächen in der Workspace-Konfiguration der Console um. Erreicht ein Tool-Aufruf in Workspace einen Server im Modus Jeder Benutzer, mit dem Sie noch nicht verbunden sind, oder akzeptiert der Dienst Ihre Anmeldung nicht mehr, liefert das Tool connect_required, und die Antwort zeigt eine Aktion Verbinden für diesen Server; nichts läuft unter einer anderen Identität.

Persönliche MCP-Vorschläge

Persönliche MCP-Vorschläge sind standardmäßig Aus. Admin-Genehmigung erforderlich erlaubt Vorschläge für private Server, die nur dem Antragsteller dienen. Admins prüfen Tools, Residency und Authentifizierung ausdrücklich; eine Genehmigung erteilt weder Wildcard-Zugriff noch eine automatische organisationsweite Freigabe. Private Server unterstützen none (ohne Upstream-Anmeldung) oder interaktives OAuth, keine persönlichen statischen Geheimnisse. Aus pausiert bestehende persönliche Server, blockiert aber keine Anmeldung bei Servern, die Admins hinzugefügt haben. Der Antrag eines Mitglieds nennt nur den Server und seinen Endpunkt; solange er offen ist, kontaktiert er den Server nicht und gibt keine Tools frei. Die Genehmigung legt die geprüfte Konfiguration und eine ausdrückliche Liste von Tool-Namen fest, nur für den Antragsteller, der sich danach unter Verbindungen anmeldet, wenn der Server OAuth nutzt. Wird ein genehmigter Antrag entfernt, werden der Server und seine Verbindungen widerrufen.

Von einem MCP-Client bei Sluis anmelden

Eingehendes OAuth unter /agent/mcp meldet den Client über den Browser bei Sluis an. Dies ist von der Upstream-Anmeldung mit user_oauth getrennt. Genehmigen Sie den Zugriff in der gewünschten Organisation. Sluis erstellt oder verwendet automatisch persönliche Tool-Zugangsdaten für diesen Client. Bestehende Plugin-Bindungen, Tool-Berechtigungen und Richtlinien gelten weiterhin. In diese OAuth-Konfiguration für Tools wird kein Schlüssel eingefügt; die Schlüsselkonfiguration für Modelle bleibt unverändert. Der Client findet Sluis über die veröffentlichten Discovery-Dokumente, registriert sich und öffnet Ihren Browser auf der Zustimmungsseite /console/mcp-authorize, die Client, Organisation und erreichbare Tools zeigt; dort genehmigen oder verweigern Sie. Die Organisation muss Agent Harness aktiviert haben. Zugriffstokens gelten eine Stunde, Refresh-Tokens wechseln bei jeder Nutzung. Widerrufen Sie einen Client unter Agent Harness › Verbundene Clients; das trennt seine Tokens und seinen persönlichen Agent-Schlüssel.

claude mcp add --transport http sluis https://<gateway>/agent/mcp

codex mcp add sluis --url https://<gateway>/agent/mcp
codex mcp login sluis

Konfigurationsbeispiele, keine verifizierte Interoperabilitätsmatrix. Diese Beispiele belegen keine Interoperabilität mit externen Claude-, Codex- oder Upstream-Diensten.