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-Einträge.
  • create_inventory_object und revise_inventory_object legen Einträge 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, change-inventory-object oder curate-evidence samt Verweisen auf fokussierte Referenzen. Ein Skill orchestriert öffentliche Tools, erteilt aber keine zusätzlichen Rechte und schaltet keine Tools frei. Derselbe Skill und dieselben Tool-Namen werden in Secani verwendet.

inspect_schema

Lädt Typen 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.

Durchsucht Einträge, Aufgaben, Framework-Anforderungen und Evidence Artifacts in einem Aufruf und liefert kompakte, nach Entity-Art gruppierte Referenzen mit expliziten Abschnitts-Signalen (ok, unauthorized, unavailable, skipped). scope: "auto" wählt die passende Grenze pro Entity-Art: Workspace für Bestandsaufnahme und Aufgaben, aktueller Governance Scope für Anforderungen und Nachweise. Mit entityKinds lässt sich die Suche eingrenzen; scope sollte nur für eine ausdrücklich gewünschte Grenze gesetzt werden. Strukturierte Abfragen gehören zu den list_*-Tools, entscheidende Treffer zum passenden inspect/get-Tool.

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.

list_implementations, get_implementation und list_implementation_coverage

list_implementations listet die aktiven Implementations (Maßnahmen) des Workspace mit Titel, Art, Provision-Modus und Revisions-Pins, optional nach kind oder provisionMode gefiltert. get_implementation lädt genau eine Implementation und akzeptiert neben der Convex-ID auch den exakten Titel. list_implementation_coverage beantwortet „Wie ist Anforderung X umgesetzt?": Es listet die Requirement Targets eines Framework-Bindings (referenzierbar per ID, frameworkKey oder Name) mit verknüpfter Implementation und Link-Status (unimplemented, partial, implemented, unresolved), optional per Code-/Titel-Suche oder linkStatus verengt.

list_findings und get_finding

list_findings listet die aktiven Assessment-Findings des Workspace mit Severity, Disposition, Kategorie, Herkunfts-Pins und dem verknüpften Remediation-Issue, optional serverseitig nach severity, disposition oder category gefiltert. get_finding lädt genau ein Finding und akzeptiert neben der Convex-ID den menschenlesbaren findingKey.

list_risks und get_risk

list_risks listet die aktiven Risiken des Workspace mit Titel, Kategorie, Inherent-/Residual-Scores und -Levels, Strategie und Status, optional serverseitig nach category, status, strategy oder residualLevel gefiltert. get_risk lädt genau ein Risiko samt Governance-Feldern und akzeptiert neben der Convex-ID den menschenlesbaren riskKey oder den exakten Titel.

get_isms_status, list_obligations und get_obligation

get_isms_status liefert den ISMS-Stand eines Governance Scope als isms-status/v1: Boundary, Frameworks mit Anwendbarkeits- und Umsetzungsverteilung, Risiken, Nachweise, Assessments, Findings, Assurance und daraus abgeleitete Stufen mit dem jeweils nächsten Werkzeug. list_obligations listet das Verpflichtungsregister des Workspace seitenweise; get_obligation lädt genau eine Verpflichtung per Convex-ID oder exaktem Titel.

ISMS-Aufbau: attach_framework, save_risk, save_measure, set_applicability, save_obligation und record_assessment

Diese Actions bauen und pflegen das ISMS nach expliziter Freigabe und schreiben über dieselben Domain-Commands wie die Secani-App mit dem Nutzer als Akteur. Jede erwartet organizationSlug, workspaceSlug, bei scopegebundenen Tools governanceScopeId und eine vom Client gewählte requestId (UUID); eine Wiederholung mit derselben requestId setzt idempotent fort. attach_framework fügt ein verfügbares Framework per frameworkKey oder Name zum Workspace hinzu; jedes Framework bekommt dabei seine eigene Asset-Auswahl, die zunächst alle aktiven Einträge umfasst. save_risk, save_measure und save_obligation legen ohne id an und ändern mit id (nur genannte Felder). save_measure verknüpft per implements bis zu zehn Anforderungscodes. set_applicability entscheidet bis zu 25 Anforderungen in einer Freigabe; not_applicable und conditional verlangen eine rationale, die verschlüsselt gespeichert wird. record_assessment startet und schließt einen manuellen Assessment-Lauf für eine Anforderung ab und legt bei not_satisfied optional ein Finding an. Mehrstufige Actions melden bei einem Teilfehler PARTIAL_FAILURE mit den bereits angewendeten Schritten.

list_tasks und get_task

list_tasks listet die aktuellen Aufgaben (Work Items) des Workspace mit Titel, Workflow-Status, Priorität, Verantwortlichen-E-Mail und Revisions-Pins; alle Filter (workflowState, priority, assignee als E-Mail oder "me", lifecycleStatus, updatedAfter) laufen serverseitig. get_task lädt genau eine Aufgabe mit den autoritativen aktuellen Revisions-Pins für nachfolgende Schreibvorgänge.

create_inventory_object

Legt nach expliziter Freigabe genau einen neuen Eintrag (zum Beispiel eine Anwendung) in der Bestandsaufnahme des angegebenen Workspace an. Der Server verwendet denselben V3-Domain-Command wie der Dialog der Bestandsaufnahme der Secani-App, schreibt ein Audit-Event mit KI-Akteur und nimmt den Eintrag 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 den bestehenden Eintrag 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 Eintrags. Der Aufruf benötigt die Eintrags-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

Für freie Aussagen aus einem Informationsverbund liefert search_framework_requirements innerhalb eines ausgewählten Framework-Bindings begrenzte Kandidaten aus Titel, Statement, Guidance und deren verschachtelten OSCAL-Parts. Der Discovery-Rang ist keine Konfidenz oder Compliance-Entscheidung. Lade jeden verwendeten Kandidaten anschließend mit inspect_framework_requirement; die Detailantwort enthält begrenzt zusammengesetzten Katalogtext, Parameter, Eigenschaften, Anwendbarkeit sowie die aktuellen Binding- und Target-Pins. Bei partial, truncated, textTruncated oder mehreren plausiblen Treffern muss die Unvollständigkeit offengelegt beziehungsweise die Auswahl dem Menschen überlassen werden.

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 Eintragsrevision.
  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, search_framework_requirements, inspect_framework_requirement und list_evidence_subjects liefern die dafür benötigten aktuellen Pins und Kataloginformationen. Die binding-gebundenen Lese-Tools akzeptieren als scopeFrameworkBindingId neben der Convex-ID auch den frameworkKey (z. B. iso27001) oder den Framework-Namen, inspect_framework_requirement zusätzlich den Anforderungscode (z. B. A.8.5) als requirementTargetId; die Auflösung erfolgt serverseitig, mehrdeutige Referenzen schlagen mit AMBIGUOUS_REFERENCE samt Kandidatenliste fehl, und die Antwort enthält immer die aufgelöste kanonische ID. list_requirement_targets und list_evidence_artifacts unterstützen zusätzlich fields, um jede Zeile auf ausgewählte Attribute plus die immer enthaltenen ID-Pins zu verengen, und whoami liefert mit includeScopes=false einen leichten Identitäts-Check ohne Scope-Expansion. Für Fragen zur Katalogstruktur liefert list_requirement_hierarchy genau eine Ebene der Gruppen- und Control-Hierarchie eines Bindings (ohne parentElementId die obersten Gruppen, mit parentElementId die Kinder eines Elements), und get_requirement_element liest genau ein Element mit Statement, Guidance, Parametern und – bei assessierbaren Controls – den gepinnten Target-Referenzen. 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; beginne unstrukturierte Discovery mit search und nutze danach das passende inspect/get-Tool. search_entities bleibt als scopegebundener Kompatibilitätsendpunkt verfügbar.
  6. Nutze für Änderungen an der Bestandsaufnahme 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 Bestandsaufnahme-, 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.