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/mcpDer Server stellt eine kleine, progressive Tool-Oberfläche bereit:
whoamiermittelt sichtbare Organisationen, Workspaces, Governance Scopes und effektive Zugriffsrechte.discover_capabilitiesfindet die für einen Intent oder Skill relevanten Secani-Fähigkeiten;load_skilllädt die zugehörige Arbeitsanleitung.inspect_schema,search_entities,inspect_entityundexpand_entitybilden die universelle Read Plane. Der erste Adapter unterstützt V3-Workspace-Einträge.create_inventory_objectundrevise_inventory_objectlegen 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_checkundhuman_approval_number_testbleiben als isolierte Diagnosetools verfügbar.
Verbindungsdetails
| Einstellung | Wert |
|---|---|
| Transport | Streamable HTTP |
| MCP-Server-URL | https://mcp.secani.com/mcp |
| Protected-Resource-Metadaten | https://mcp.secani.com/.well-known/oauth-protected-resource/mcp |
| Authentifizierung | OAuth 2.0 Bearer-Token |
| Erforderlicher Scope | openid |
| Bearer-Übertragung | Authorization-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/mcpStarte 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/mcpWenn 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:
- Aktiviere den Entwicklermodus in den Connector-Einstellungen.
- Erstelle einen benutzerdefinierten Connector mit dem Namen
Secani. - Setze die MCP-Server-URL auf
https://mcp.secani.com/mcp. - Wähle OAuth als Authentifizierung.
- 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.
search
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:
list_evidence_artifactsundinspect_evidence_artifactfinden einen vorhandenen Nachweis und dessen aktuelle unveränderliche Version.create_evidence_artifactlegt eine HTTPS-Referenz oder Datei an;add_evidence_versionaktualisiert den Inhalt durch eine neue Version, ohne Historie zu überschreiben.record_evidence_factqualifiziert eine konkrete Artifact-Version als belegte Aussage zu einer gepinnten Eintragsrevision.link_evidence_usageordnet 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
- Füge
https://mcp.secani.com/mcpin deinem Client hinzu. - Autorisiere den WorkOS-Account, der auf Secani zugreifen soll.
- Rufe
whoamiauf und wähle einen sichtbaren Workspace sowie einen Baseline-bereiten Governance Scope. - Nutze
discover_capabilitiesfür den aktuellen Intent. - Inspiziere bei unklarer Feldbedeutung das Schema; beginne unstrukturierte Discovery mit
searchund nutze danach das passendeinspect/get-Tool.search_entitiesbleibt als scopegebundener Kompatibilitätsendpunkt verfügbar. - Nutze für Änderungen an der Bestandsaufnahme
create_inventory_objectoder nach einer aktuellen Inspektionrevise_inventory_object. - Lade für Nachweise
curate-evidence, verwende die exakten zurückgegebenen Revisionen und Hashes und unterscheide Artifact, Fact und Usage. - Verwende
connection_checkoderhuman_approval_number_testnur 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/mcpDie 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.comist 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.