SecaniDokumentation

Secani MCP

Verbinde KI-Clients mit Secanis authentifiziertem Model-Context-Protocol-Server.

Secani MCP ermöglicht einem autorisierten KI-Client, über das Model Context Protocol mit Secani zu arbeiten. Der Server ist für authentifizierte Compliance-Workflows ausgelegt und verlangt für Änderungen eine ausdrückliche menschliche Freigabe.

Was Secani MCP bietet

Secani MCP ist ein entfernter MCP-Server für Secani-Nutzer. Er verwendet Streamable HTTP und OAuth-2.0-Bearer-Authentifizierung über WorkOS.

Der Produktionsendpunkt lautet:

https://mcp.secani.com/mcp

Der Server stellt eine kleine, progressive Tool-Oberfläche bereit:

  • whoami ermittelt sichtbare Organisationen, Workspaces, Governance Scopes und effektive Zugriffsrechte.
  • discover_capabilities findet die für einen Intent oder Skill relevanten Secani-Fähigkeiten; load_skill lädt die zugehörige Arbeitsanleitung.
  • inspect_schema, search_entities, inspect_entity und expand_entity bilden die universelle Read Plane. Der erste Adapter unterstützt V3-Workspace-Objekte.
  • create_inventory_object und revise_inventory_object legen Inventarobjekte an beziehungsweise erzeugen neue unveränderliche Revisionen.
  • Die Evidence-Tools suchen, inspizieren, erstellen, versionieren, qualifizieren und ordnen Nachweise zu. Dateien bis 512 KiB können inline übertragen werden; größere Dateien bis 10 MiB verwenden einen kurzlebigen, hashgebundenen Upload.
  • connection_check und human_approval_number_test bleiben als isolierte Diagnosetools verfügbar.

Verbindungsdetails

EinstellungWert
TransportStreamable HTTP
MCP-Server-URLhttps://mcp.secani.com/mcp
Protected-Resource-Metadatenhttps://mcp.secani.com/.well-known/oauth-protected-resource/mcp
AuthentifizierungOAuth 2.0 Bearer-Token
Erforderlicher Scopeopenid
Bearer-ÜbertragungAuthorization-Header

Der Protected-Resource-Metadatenendpunkt teilt dem MCP-Client mit, welchen WorkOS-Autorisierungsserver er verwenden soll. Konfiguriere die Server-URL in deinem Client und schließe den OAuth-Flow ab, sobald der Client dazu auffordert.

Einen MCP-Client verbinden

Allgemeine Konfiguration für entfernte MCP-Server

Für Clients, die eine entfernte MCP-Serverdefinition akzeptieren, kannst du Folgendes eintragen:

{
  "mcpServers": {
    "secani": {
      "url": "https://mcp.secani.com/mcp"
    }
  }
}

Die genaue Konfigurationsdatei und die OAuth-Oberfläche hängen vom Client ab. Verwende den Namen Secani oder secani, prüfe die URL exakt und bestätige die WorkOS-Anmeldung.

Claude Code

Füge Secani als entfernten HTTP-MCP-Server hinzu:

claude mcp add --transport http secani https://mcp.secani.com/mcp

Starte Claude Code und öffne den MCP-Verbindungsdialog zur Autorisierung. Die Browser-Anmeldung ist Teil von OAuth; Bearer-Tokens gehören nicht in deine Projektkonfiguration.

Codex CLI

Füge den Server mit der HTTP-URL hinzu:

codex mcp add secani --url https://mcp.secani.com/mcp

Wenn Codex OAuth-Unterstützung erkennt, folge dem Browser-Flow und kehre anschließend zur CLI zurück.

Cursor

Ergänze deinen MCP-Eintrag:

{
  "mcpServers": {
    "secani": {
      "url": "https://mcp.secani.com/mcp"
    }
  }
}

Starte den Server im MCP-Bereich von Cursor. Cursor sollte vor der Nutzung geschützter Tools zur Authentifizierung auffordern.

Benutzerdefinierter ChatGPT-Connector

Wenn dein ChatGPT-Workspace entfernte MCP-Connectoren unterstützt:

  1. Aktiviere den Entwicklermodus in den Connector-Einstellungen.
  2. Erstelle einen benutzerdefinierten Connector mit dem Namen Secani.
  3. Setze die MCP-Server-URL auf https://mcp.secani.com/mcp.
  4. Wähle OAuth als Authentifizierung.
  5. Schließe den WorkOS-Autorisierungsflow ab.

Verfügbarkeit und Menübezeichnungen hängen von deinem ChatGPT-Tarif und Workspace ab.

Verfügbare Tools

whoami

Rufe dieses Tool zuerst auf, um sichtbare Workspaces, bis zu 50 autorisierte Governance Scopes je Workspace, deren Baseline-Bereitschaft und den effektiven Read-only- beziehungsweise Schreibstatus des Connectors zu ermitteln.

discover_capabilities

Beschreibe den aktuellen Intent optional mit intent oder gib einen registrierten Skill an. Die Antwort enthält nur passende, im aktuellen Connector-Modus verfügbare Fähigkeiten, fehlende Skill-Tools und kompakte Toolset-Zählungen. Berechtigungen werden trotzdem bei jedem nachfolgenden Aufruf erneut in Convex geprüft.

load_skill

Lädt eine versionierte Secani-Arbeitsanleitung wie explore-workspace-context oder curate-evidence samt Verweisen auf fokussierte Referenzen. Ein Skill orchestriert öffentliche Tools, erteilt aber keine zusätzlichen Rechte. Derselbe Skill und dieselben Tool-Namen werden in Secani Eve verwendet.

inspect_schema

Lädt Objektklassen und agentenorientierte Feldmetadaten für einen autorisierten Governance Scope. Die Antwort enthält Volatilitäts-, Retrieval- und Sensitivitätshinweise aus dem bestehenden V3-Agent-Context-Vertrag.

search_entities

Führt die bestehende hybride lexikalische und semantische Suche innerhalb einer autorisierten Governance-Scope-Baseline aus und liefert gerankte Referenzen statt vollständiger Records. Entscheidende Referenzen sollten vor Reasoning oder einem Änderungsvorschlag inspiziert werden.

inspect_entity

Lädt den kompakten, integritätsgeprüften aktuellen Zustand einer Entity aus der autorisierten Governance-Scope-Baseline und nennt optionalen Kontext, ohne ihn bereits in den Modellkontext zu laden.

expand_entity

Lädt ein begrenztes, von inspect_entity angebotenes Segment: autorisierte Relationen, volatile Werte oder Schutzbedarf. Weitere Domänen bleiben hinter eigenen sicheren Projektionen statt hinter einem Raw-Record-Zugriff.

create_inventory_object

Legt nach expliziter Freigabe genau ein neues Objekt (zum Beispiel eine Anwendung) im Inventar des angegebenen Workspace an. Der Server verwendet denselben V3-Domain-Command wie der Inventar-Dialog der Secani-App, schreibt ein Audit-Event mit KI-Akteur und nimmt das Objekt nicht automatisch in einen Governance Scope auf.

Eingabe:

{
  "organizationSlug": "acme",
  "workspaceSlug": "cloud-platform",
  "governanceScopeId": "<aus whoami>",
  "objectClassCode": "application",
  "name": "test",
  "description": "optional",
  "requestId": "<uuid>"
}

Der Server fragt vor dem Schreiben per MCP-Formularfreigabe nach. Ablehnen oder Abbrechen ändert keine Daten. Clients, die keine Formularfreigaben beantworten können, erhalten einen Fehler und es wird nichts geschrieben. requestId ist der Idempotenzschlüssel: Ein wiederholter Aufruf mit derselben ID und demselben Inhalt liefert das bestehende Objekt statt eines Duplikats. Der Governance Scope dient nur der Berechtigungsprüfung (inventory.create auf dem Scope); Read-only-Connectoren können die Action nicht ausführen.

revise_inventory_object

Erzeugt nach Freigabe eine neue unveränderliche Revision eines bestehenden Inventarobjekts. Der Aufruf benötigt die Objekt-ID sowie die zuvor mit inspect_entity gelesene aktuelle Revisions-ID und deren Content-Hash. Name, Beschreibung und revision-relevante Attribute können geändert oder entfernt werden. Wenn sich der aktuelle Stand zwischen Lesen und Schreiben ändert, antwortet Secani mit STALE_CURRENT, statt fremde Änderungen zu überschreiben.

Evidence-Workflow

Die Evidence-Oberfläche trennt vier fachliche Zustände:

  1. list_evidence_artifacts und inspect_evidence_artifact finden einen vorhandenen Nachweis und dessen aktuelle unveränderliche Version.
  2. create_evidence_artifact legt eine HTTPS-Referenz oder Datei an; add_evidence_version aktualisiert den Inhalt durch eine neue Version, ohne Historie zu überschreiben.
  3. record_evidence_fact qualifiziert eine konkrete Artifact-Version als belegte Aussage zu einer gepinnten Objekt-Revision.
  4. link_evidence_usage ordnet den Fact einer gepinnten Framework-Anforderung zu. Erst dieser erfolgreiche Schritt ist eine fachliche Zuordnung.

list_framework_bindings, list_requirement_targets und list_evidence_subjects liefern die dafür benötigten aktuellen Pins. Alle vier Evidence-Writes verlangen eine Freigabe, sind per requestId idempotent und schreiben KI-Provenienz. Bei Dateien bis 512 KiB wird kanonisches Base64 verwendet. Für größere Dateien liefert die Action nach Freigabe ein zwei Minuten gültiges Upload-Ticket; der Client überträgt unveränderte Bytes mit demselben OAuth-Bearer. Größe und SHA-256 werden vor dem Speichern geprüft.

connection_check

Verwende dieses schreibgeschützte Tool, um die Verbindung nach der OAuth-Autorisierung zu prüfen.

Eingabe:

{
  "echo": "optionaler Diagnosetext"
}

Die Antwort bestätigt den authentifizierten Secani-Nutzer und die Identität des MCP-Clients. Das Tool eignet sich als erster Aufruf nach dem Verbinden eines neuen Clients.

human_approval_number_test

Mit diesem Tool testest du einen vollständigen Human-in-the-loop-Workflow. Es schlägt eine ganze Zahl vor und fragt, ob der Nutzer die Änderung annehmen, ablehnen oder abbrechen möchte.

Eingabe:

{
  "value": 42,
  "fieldLabel": "MCP-Testwert"
}

Nach der Freigabe speichert Secani den Wert im Testfeld des Einstellungsdialogs. Wenn der Client keine MCP-Formularfreigaben anzeigen kann, behandelt der Server den angeforderten Wert über einen Kompatibilitäts-Fallback als freigegeben. Auch dann sind ein authentifizierter Secani-Nutzer und das konfigurierte Test-Secret erforderlich.

Empfohlener Ablauf

  1. Füge https://mcp.secani.com/mcp in deinem Client hinzu.
  2. Autorisiere den WorkOS-Account, der auf Secani zugreifen soll.
  3. Rufe whoami auf und wähle einen sichtbaren Workspace sowie einen Baseline-bereiten Governance Scope.
  4. Nutze discover_capabilities für den aktuellen Intent.
  5. Inspiziere bei unklarer Feldbedeutung das Schema; navigiere bei Leseaufgaben mit search_entitiesinspect_entityexpand_entity.
  6. Nutze für Inventaränderungen create_inventory_object oder nach einer aktuellen Inspektion revise_inventory_object.
  7. Lade für Nachweise curate-evidence, verwende die exakten zurückgegebenen Revisionen und Hashes und unterscheide Artifact, Fact und Usage.
  8. Verwende connection_check oder human_approval_number_test nur für die jeweilige Diagnose und bestätige Änderungen nur bei beabsichtigten Tests.

Fehlerbehebung

Der Client meldet 401 Unauthorized

Der Server verlangt für MCP-Anfragen ein gültiges OAuth-Bearer-Token. Öffne den MCP-Autorisierungsflow des Clients erneut und prüfe die WorkOS-Anmeldung. Ersetze die MCP-URL nicht durch die URL des OAuth-Issuers.

Die OAuth-Erkennung schlägt fehl

Prüfe, ob dein Client den Produktionsendpunkt verwendet und diesen Metadatenendpunkt erreicht:

https://mcp.secani.com/.well-known/oauth-protected-resource/mcp

Die Metadaten verweisen auf den richtigen Autorisierungsserver und deklarieren den erforderlichen Scope openid.

Der Freigabedialog erscheint nicht

Der Client unterstützt möglicherweise keine MCP-Formularfreigaben. Aktualisiere den Client, wenn möglich. Secani besitzt für dieses Test-Tool einen Kompatibilitäts-Fallback; prüfe den vorgeschlagenen Wert trotzdem, bevor du den Aufruf fortsetzt.

Der Endpunkt öffnet sich wie eine Webseite

Der MCP-Endpunkt ist ein Maschinen-Transport und kein menschliches Dashboard. Verwende einen MCP-Client und den OAuth-Flow statt einer normalen Browser-Sitzung. Die lesbare Beschreibung steht unter secani.com/docs/mcp.

Sicherheitshinweise

  • Prüfe den Hostnamen vor der Autorisierung: mcp.secani.com ist der offizielle Secani-MCP-Host.
  • Verwende OAuth über deinen MCP-Client. Bearer-Tokens gehören niemals in Quellcode, Prompts oder Tickets.
  • Prüfe Clientname, angeforderten Account und Scope vor der Freigabe.
  • Behandle Inventar-, Evidence- und Diagnoseschreibaktionen als mutierende Tools und lasse Formularfreigaben aktiviert.
  • Lass menschliche Bestätigungen für Workflows aktiviert, die Änderungen ausführen können.
  • Verbinde nur MCP-Clients und Erweiterungen, denen du vertraust. Ein autorisierter Client kann Anfragen als der verbundene Secani-Nutzer senden.