SecaniDocumentation

Secani MCP

Connectez les clients IA au serveur Model Context Protocol authentifié de Secani.

Secani MCP permet à un client IA approuvé de travailler avec Secani via le Protocole de contexte de modèle. Le serveur est conçu pour les flux de travail de conformité authentifiés, avec une approbation humaine explicite pour les modifications.

Ce que Secani MCP fournit

Secani MCP est un serveur MCP distant pour les utilisateurs Secani. Il utilise l'authentification du porteur Streamable HTTP et OAuth 2.0 via WorkOS.

Le point final de production est :

https://mcp.secani.com/mcp

Le serveur expose une petite surface d'outils progressive :

  • whoami découvre des organisations visibles, des espaces de travail, des étendues de gouvernance et un accès efficace.
  • discover_capabilities trouve des capacités pertinentes pour une intention ou une compétence ; load_skill charge le guide de flux de travail correspondant.
  • inspect_schema, search_entities, inspect_entity, et expand_entity forment le plan de lecture universel. Le premier adaptateur prend en charge les objets d'espace de travail V3.
  • create_inventory_object et revise_inventory_object créer des objets d'inventaire ou de nouvelles révisions immuables.
  • Les outils de preuves recherchent, inspectent, créent, versionnent, qualifient et attribuent des preuves. Des fichiers jusqu'à 512 Ko peuvent être envoyés en ligne ; les fichiers plus volumineux jusqu'à 10 Mio utilisent un téléchargement de courte durée lié au hachage.
  • connection_check et human_approval_number_test restent disponibles en tant qu’outils de diagnostic isolés.

Détails de connexion

ParamètreValeur
TransportHTTP diffusable
URL du serveur MCPhttps://mcp.secani.com/mcp
Métadonnées des ressources protégéeshttps://mcp.secani.com/.well-known/oauth-protected-resource/mcp
AuthentificationJeton de porteur OAuth 2.0
Portée requiseopenid
Transport au porteurAuthorization en-tête

Le point de terminaison des métadonnées de ressource protégée indique à votre client MCP quel serveur d'autorisation WorkOS utiliser. Configurez l'URL du serveur dans votre client, puis terminez le flux OAuth dans le client lorsque vous y êtes invité.

Connecter un client MCP

Configuration MCP distante générique

Pour les clients qui acceptent une définition de serveur MCP distant, ajoutez :

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

Le fichier de configuration exact et l'interface utilisateur OAuth dépendent de votre client. Utilisez le nom Secani ou secani, assurez-vous que l'URL est exactement https://mcp.secani.com/mcp, et approuvez la demande de connexion à WorkOS.

Claude Code

Ajoutez Secani en tant que serveur HTTP MCP distant :

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

Démarrez Claude Code et ouvrez son flux de gestion MCP pour autoriser la connexion. La connexion au navigateur fait partie d'OAuth ; ne collez pas de jeton de porteur dans la configuration de votre projet.

CLI du Codex

Ajoutez le serveur avec l'URL HTTP :

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

Lorsque le Codex détecte la prise en charge d'OAuth, suivez le flux d'autorisation du navigateur et revenez à la CLI.

Curseur

Ajoutez le serveur à votre configuration MCP :

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

Démarrez le serveur à partir du panneau MCP du curseur. Le curseur devrait vous demander de vous authentifier avant que les outils protégés ne soient disponibles.

Connecteur personnalisé ChatGPT

Si votre espace de travail ChatGPT prend en charge les connecteurs MCP distants personnalisés :

  1. Activez le mode développeur dans les paramètres du connecteur.
  2. Créez un connecteur personnalisé nommé Secani.
  3. Définissez l'URL du serveur MCP sur https://mcp.secani.com/mcp.
  4. Sélectionnez l'authentification OAuth.
  5. Terminez le flux d’autorisation WorkOS.

La disponibilité et les noms des menus dépendent de votre forfait ChatGPT et de la configuration de votre espace de travail.

Outils disponibles

whoami

Appelez-le d'abord pour découvrir les espaces de travail visibles, jusqu'à 50 étendues de gouvernance autorisées par espace de travail, l'état de préparation de base et l'état effectif en lecture seule ou en écriture du connecteur.

discover_capabilities

Décrivez éventuellement l'intention actuelle avec intent ou sélectionnez une compétence enregistrée. La réponse contient uniquement les fonctionnalités pertinentes disponibles dans le mode de connecteur actuel, les outils de compétences non disponibles et le nombre d'outils compacts. Convex applique toujours l'autorisation à chaque appel ultérieur.

load_skill

Charge des conseils de flux de travail Secani versionnés tels que explore-workspace-context, change-inventory-object, ou curate-evidence, y compris des liens de référence ciblés. Une compétence orchestre des outils publics mais n'accorde aucune autorisation supplémentaire et n'expose aucun outil supplémentaire. Secani utilise les mêmes compétences et noms d'outils.

inspect_schema

Charge les classes d'objets et les métadonnées de champ orientées agent pour une étendue de gouvernance autorisée. La réponse inclut des indices de volatilité, de récupération et de sensibilité du contrat de contexte d'agent V3 existant.

Recherche les objets de l'espace de travail, les tâches, les exigences du cadre et les artefacts de preuves en un seul appel et renvoie des références compactes regroupées par type d'entité avec des signaux explicites par section (ok, unauthorized, unavailable, skipped). scope: "auto" sélectionne la limite native par type d'entité : espace de travail pour l'inventaire et les tâches, portée de gouvernance actuelle pour les exigences et les preuves. Utiliser entityKinds pour restreindre la découverte et définir scope uniquement lorsqu'une limite est explicitement requise. Les requêtes structurées appartiennent au list_* outils et coups décisifs à la correspondance inspect/get outil.

search_entities

Exécute la recherche lexicale et sémantique hybride existante dans une base de référence de gouvernance autorisée et renvoie des références classées au lieu d'enregistrements complets. Les références décisives doivent être inspectées avant de raisonner ou de proposer un changement.

inspect_entity

Charge l'état actuel compact et vérifié en intégrité pour une entité incluse dans la base de référence de la portée de gouvernance autorisée et annonce le contexte facultatif sans le charger dans le contexte du modèle.

expand_entity

Charge un segment délimité annoncé par inspect_entity: relations autorisées, état instable ou besoin de protection. D'autres domaines restent derrière des projections sécurisées dédiées au lieu d'un accès aux enregistrements bruts.

list_implementations, get_implementation, et list_implementation_coverage

list_implementations répertorie les implémentations actives (mesures) de l'espace de travail avec le titre, le type, le mode de fourniture et les broches de révision, éventuellement filtrées par kind ou provisionMode. get_implementation charge exactement une implémentation et accepte le titre exact en plus de l'ID Convex. list_implementation_coverage répond "comment l'exigence X est-elle implémentée ?" : il répertorie les cibles d'exigence d'une liaison de cadre (référencées par ID, frameworkKey, ou nom) avec l'implémentation liée et l'état du lien (unimplemented, partial, implemented, unresolved), éventuellement restreint par un code/title rechercher ou linkStatus.

list_findings et get_finding

list_findings répertorie les résultats de l'évaluation active de l'espace de travail avec la gravité, la disposition, la catégorie, les épingles d'origine et le problème de remédiation lié, éventuellement filtrés côté serveur par severity, disposition, ou category. get_finding charge exactement un résultat et accepte le texte lisible par l'homme findingKey en plus de l'identifiant Convex.

list_risks et get_risk

list_risks répertorie les risques actifs de l'espace de travail avec titre, catégorie, inhérents/residual scores et niveaux, stratégie et statut, éventuellement filtrés côté serveur par category, status, strategy, ou residualLevel. get_risk charge exactement un risque, y compris ses champs de gouvernance et accepte le format lisible par l'homme riskKey ou le titre exact en plus de l'identifiant Convex.

get_isms_status, list_obligations, et get_obligation

get_isms_status renvoie l'état ISMS d'une étendue de gouvernance sous la forme isms-status/v1: les limites, les cadres avec l'applicabilité et la distribution de la mise en œuvre, les risques, les preuves, les évaluations, les conclusions, l'assurance et les étapes dérivées avec l'outil suivant pour chacun. list_obligations pages du registre des obligations de l'espace de travail ; get_obligation charge exactement une obligation par Convex ID ou titre exact.

Construction du SMSI : create_scope, attach_framework, save_risk, save_measure, set_applicability, save_obligation, et record_assessment

Ces actions construisent et maintiennent le SMSI après approbation explicite et écrivent via les mêmes commandes de domaine que l'application Secani avec l'utilisateur comme acteur. Chacun s'attend organizationSlug, workspaceSlug, un governanceScopeId pour des outils limités à la portée et un choix choisi par le client requestId (UUID); répéter un appel avec le même requestId reprend idempotent. attach_framework joint un cadre disponible par frameworkKey ou nom et en signale un déjà joint avec alreadyAttached. save_risk, save_measure, et save_obligation créer sans id et mettre à jour avec id (seuls les champs donnés changent). save_measure relie jusqu'à dix codes d'exigence via implements. set_applicability décide jusqu'à 25 exigences en une seule approbation ; not_applicable et conditional exiger un rationale, qui est stocké crypté. record_assessment démarre et termine une évaluation manuelle pour une exigence et génère éventuellement un résultat pour not_satisfied. Rapport d'actions en plusieurs étapes PARTIAL_FAILURE avec les étapes appliquées en cas d'échec partiel.

list_tasks et get_task

list_tasks répertorie les tâches actuelles de l'espace de travail (éléments de travail) avec le titre, l'état du flux de travail, la priorité, l'e-mail du responsable et les épingles de révision ; tous les filtres (workflowState, priority, assignee sous forme d'e-mail ou "me", lifecycleStatus, updatedAfter) exécuté côté serveur. get_task charge exactement une tâche avec les broches de révision actuelles faisant autorité pour les écritures ultérieures.

create_inventory_object

Crée exactement un nouvel objet (par exemple une application) dans l'inventaire de l'espace de travail donné après approbation explicite. Le serveur utilise la même commande de domaine V3 que la boîte de dialogue d'inventaire Secani, écrit un événement d'audit avec un acteur IA et n'ajoute jamais automatiquement l'objet à une étendue de gouvernance.

Saisir:

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

Le serveur demande l'approbation d'un formulaire MCP avant d'écrire. Refuser ou annuler ne change rien. Les clients qui ne peuvent pas répondre aux approbations du formulaire reçoivent une erreur et rien n'est écrit. requestId est la clé d'idempotence : répéter l'appel avec le même identifiant et le même contenu renvoie l'objet existant au lieu d'un doublon. Le périmètre de gouvernance est utilisé uniquement pour l'autorisation (inventory.create sur ce périmètre); les connecteurs en lecture seule ne peuvent pas exécuter l'action.

revise_inventory_object

Crée une nouvelle révision immuable d'un objet d'inventaire existant après approbation. L'appel nécessite l'ID d'objet ainsi que l'ID de révision actuelle et le hachage de contenu renvoyés par inspect_entity. Il peut modifier ou supprimer le nom, la description et les attributs relatifs à la révision. Si l'état actuel change entre l'inspection et l'écriture, Secani revient STALE_CURRENT au lieu d'écraser une autre modification.

Flux de travail des preuves

Pour les déclarations de forme libre sur un domaine d'information, search_framework_requirements renvoie les candidats délimités à partir du titre, de l'instruction, des conseils et de leurs parties OSCAL imbriquées dans une liaison de cadre sélectionnée. Le classement de découverte n’est pas une confiance ou une décision de conformité. Chargez chaque candidat utilisé dans une conclusion avec inspect_framework_requirement; ses détails faisant autorité comprennent le texte du catalogue assemblé limité, les paramètres, les propriétés, l'applicabilité, la liaison actuelle et les broches cibles. Divulguer partial, truncated, ou textTruncated résultats, et laisser le choix à un humain lorsque plusieurs candidats sont plausibles.

La surface Preuve conserve quatre états de domaine distincts :

  1. list_evidence_artifacts et inspect_evidence_artifact localiser les preuves existantes et leur version immuable actuelle.
  2. create_evidence_artifact crée une référence ou un fichier HTTPS ; add_evidence_version met à jour son contenu en ajoutant une version sans écraser l'historique.
  3. record_evidence_fact qualifie une version d'artefact épinglée comme une instruction prise en charge concernant une révision d'objet épinglée.
  4. link_evidence_usage attribue ce fait à une exigence de cadre épinglée. Seule cette étape réussie constitue une attribution de domaine.

list_framework_bindings, list_requirement_targets, search_framework_requirements, inspect_framework_requirement, et list_evidence_subjects fournir les broches actuelles requises et le contexte du catalogue. Les outils de lecture à portée de liaison acceptent les frameworkKey (par ex. iso27001) ou le nom du framework comme scopeFrameworkBindingId en plus de l'identifiant Convex, et inspect_framework_requirement accepte également le code d'exigence (par ex. A.8.5) comme requirementTargetId; la résolution se produit côté serveur, les références ambiguës échouent avec AMBIGUOUS_REFERENCE et une liste de candidats, et les réponses portent toujours l'ID canonique résolu. list_requirement_targets et list_evidence_artifacts supporte en outre fields pour restreindre chaque ligne aux attributs sélectionnés ainsi qu'aux broches d'identification toujours incluses, et whoami propose un appel d'identité léger sans extension de périmètre via includeScopes=false. Pour les questions sur la structure du catalogue, list_requirement_hierarchy renvoie exactement un niveau de la hiérarchie de groupe et de contrôle d'une liaison (groupes de niveau supérieur sans parentElementId, les enfants d'un élément avec lui), et get_requirement_element lit exactement un élément avec l'instruction, les conseils, les paramètres et, pour les contrôles évaluables, les références cibles épinglées. Les quatre écrits de preuves nécessitent une approbation et sont idempotents par requestId, et enregistrer la provenance de l’IA. Les fichiers jusqu'à 512 Ko utilisent la base64 canonique. Pour les fichiers plus volumineux, l'action renvoie un ticket de téléchargement de deux minutes après approbation ; le client envoie les octets inchangés avec le même support OAuth. Secani vérifie la taille exacte et SHA-256 avant de stocker quoi que ce soit.

connection_check

Utilisez cet outil en lecture seule pour vérifier la connexion après l'autorisation OAuth.

Saisir:

{
  "echo": "optional diagnostic text"
}

La réponse confirme l'identité de l'utilisateur Secani authentifié et du client MCP. C'est utile comme premier appel après la connexion d'un nouveau client.

human_approval_number_test

Utilisez cet outil pour tester un flux de travail complet avec intervention humaine. Il propose un entier et demande à l'utilisateur d'accepter, de refuser ou d'annuler la modification.

Saisir:

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

Après approbation, Secani stocke la valeur dans le champ de test de la boîte de dialogue Paramètres. Si le client ne peut pas afficher l'élicitation du formulaire MCP, la valeur demandée est traitée comme approuvée par la solution de secours de compatibilité du serveur. L'outil nécessite toujours un utilisateur Secani authentifié et un secret de test configuré.

Flux de travail recommandé

  1. Ajouter https://mcp.secani.com/mcp à votre client.
  2. Complétez l'autorisation OAuth avec le compte WorkOS qui doit accéder à Secani.
  3. Appel whoami et sélectionnez un espace de travail visible et une portée de gouvernance prête pour la référence.
  4. Utiliser discover_capabilities pour l'intention actuelle.
  5. Inspectez le schéma lorsque la signification du champ n'est pas claire ; démarrer la découverte non structurée avec search, puis utilisez la correspondance inspect/get outil. search_entities reste disponible en tant que point de terminaison de compatibilité au niveau de la gouvernance.
  6. Utiliser create_inventory_object pour des objets neufs ou, après une inspection en cours, revise_inventory_object pour les changements.
  7. Charger curate-evidence pour le travail de preuve, conservez chaque révision et hachage renvoyés, et gardez les artefacts, les faits et l'utilisation distincts.
  8. Utiliser connection_check ou human_approval_number_test uniquement à des fins de diagnostic spécifiques et approuver les modifications uniquement pour les tests intentionnels.

Dépannage

Le client rapporte 401 Unauthorized

Le serveur nécessite un jeton de support OAuth valide pour les requêtes MCP. Rouvrez le flux d'autorisation MCP du client et confirmez que le compte a terminé la connexion à WorkOS. Ne remplacez pas l'URL MCP par l'URL de l'émetteur OAuth.

La découverte OAuth échoue

Vérifiez que le client utilise le point de terminaison de production et peut accéder :

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

La réponse des métadonnées pointe le client vers le bon serveur d'autorisation et déclare les informations requises. openid portée.

L'invite d'approbation n'apparaît pas

Le client peut ne pas prendre en charge l’élicitation de formulaire MCP. Mettez à jour le client si possible. Secani dispose d'une solution de secours en matière de compatibilité pour cet outil de test, mais vous devez toujours examiner la valeur proposée avant d'autoriser la poursuite de l'appel.

Le point de terminaison s'ouvre sous forme de page Web

Le point de terminaison MCP est un transport de machine à machine, et non un tableau de bord humain. Utilisez un client MCP et le flux OAuth plutôt qu'une session de navigateur normale. Des informations MCP lisibles par l’homme sont disponibles sur secani.com/docs/mcp.

Conseils de sécurité

  • Vérifiez le nom d'hôte avant d'autoriser : mcp.secani.com est l'hôte officiel de Secani MCP.
  • Utilisez OAuth via votre client MCP ; ne validez ni ne collez jamais de jetons de porteur dans des fichiers sources, des invites ou des trackers de problèmes.
  • Vérifiez le nom du client, le compte demandé et la portée avant d'approuver l'accès.
  • Traitez les actions d’inventaire, de preuves et d’écriture de diagnostic comme des outils en mutation et gardez les approbations de formulaire activées.
  • Gardez la confirmation humaine activée pour les flux de travail pouvant apporter des modifications.
  • Connectez uniquement les clients et extensions MCP en qui vous avez confiance. Un client autorisé peut envoyer des demandes en tant qu'utilisateur Secani connecté.