Secani MCP

Secani MCP consente a un client IA approvato di lavorare con Secani tramite Protocollo del contesto modello. Il server è progettato per flussi di lavoro di conformità autenticati, con l'esplicita approvazione umana per le modifiche.

Cosa offre Secani MCP

Secani MCP è un server MCP remoto per gli utenti Secani. Utilizza l'autenticazione della portante Streamable HTTP e OAuth 2.0 tramite WorkOS.

L'endpoint di produzione è:

https://mcp.secani.com/mcp

Il server espone una piccola superficie progressiva dello strumento:

whoami scopre organizzazioni visibili, spazi di lavoro, ambiti di governance e accesso effettivo.
discover_capabilities trova capacità rilevanti per un intento o un'abilità; load_skill carica la guida al flusso di lavoro corrispondente.
inspect_schema, search_entities, inspect_entity, e expand_entity costituiscono il piano di lettura universale. Il primo adattatore supporta gli oggetti dell'area di lavoro V3.
create_inventory_object e revise_inventory_object creare oggetti di inventario o nuove revisioni immutabili.
Gli strumenti per le prove trovano, esaminano, creano, eseguono versioni, qualificano e assegnano prove. È possibile inviare in linea file fino a 512 KiB; i file più grandi fino a 10 MiB utilizzano un caricamento hash-bound di breve durata.
connection_check e human_approval_number_test rimangono disponibili come strumenti diagnostici isolati.

Dettagli di connessione

Collocamento	Valore
Trasporto	HTTP streaming
URL del server MCP	`https://mcp.secani.com/mcp`
Metadati delle risorse protette	`https://mcp.secani.com/.well-known/oauth-protected-resource/mcp`
Autenticazione	Token portatore OAuth 2.0
Ambito richiesto	`openid`
Trasporto al portatore	`Authorization` intestazione

L'endpoint dei metadati delle risorse protette indica al client MCP quale server di autorizzazione WorkOS utilizzare. Configura l'URL del server nel client, quindi completa il flusso OAuth nel client quando richiesto.

Connetti un client MCP

Configurazione MCP remota generica

Per i client che accettano una definizione di server MCP remoto, aggiungere:

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

Il file di configurazione esatto e l'interfaccia utente OAuth dipendono dal client. Usa il nome Secani o secani, assicurati che l'URL sia esatto https://mcp.secani.com/mcp, e approvare la richiesta di accesso a WorkOS.

Codice Claudio

Aggiungi Secani come server MCP HTTP remoto:

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

Avvia Claude Code e apri il suo flusso di gestione MCP per autorizzare la connessione. L'accesso al browser fa parte di OAuth; non incollare un token al portatore nella configurazione del progetto.

Codice CLI

Aggiungi il server con l'URL HTTP:

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

Quando Codex rileva il supporto OAuth, segui il flusso di autorizzazione del browser e torna alla CLI.

Cursore

Aggiungi il server alla configurazione del tuo MCP:

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

Avviare il server dal pannello MCP del cursore. Il cursore dovrebbe chiederti di autenticarti prima che gli strumenti protetti siano disponibili.

Connettore personalizzato ChatGPT

Se l'area di lavoro ChatGPT supporta connettori MCP remoti personalizzati:

Abilita la modalità sviluppatore nelle impostazioni del connettore.
Crea un connettore personalizzato denominato Secani.
Imposta l'URL del server MCP su https://mcp.secani.com/mcp.
Seleziona Autenticazione OAuth.
Completa il flusso di autorizzazione di WorkOS.

La disponibilità e i nomi dei menu dipendono dal piano ChatGPT e dalla configurazione dell'area di lavoro.

Strumenti disponibili

`whoami`

Chiamalo prima per scoprire le aree di lavoro visibili, fino a 50 ambiti di governance autorizzati per area di lavoro, la disponibilità di base e lo stato di sola lettura o scrittura effettivo del connettore.

`discover_capabilities`

Facoltativamente, descrivi l'intento corrente con intent oppure seleziona una competenza registrata. La risposta contiene solo le funzionalità pertinenti disponibili nella modalità connettore corrente, gli strumenti delle competenze non disponibili e i conteggi dei set di strumenti compatti. Convex applica comunque l'autorizzazione a ogni chiamata successiva.

`load_skill`

Carica la guida al flusso di lavoro Secani con versione come explore-workspace-context, change-inventory-object, o curate-evidence, compresi collegamenti di riferimento mirati. Una competenza orchestra gli strumenti pubblici ma non concede autorizzazioni aggiuntive e non espone strumenti aggiuntivi. Secani utilizza le stesse abilità e nomi di strumenti.

`inspect_schema`

Carica classi di oggetti e metadati di campo orientati all'agente per un ambito di governance autorizzato. La risposta include suggerimenti su volatilità, recupero e sensibilità dal contratto V3 Agent Context esistente.

`search`

Cerca oggetti dell'area di lavoro, attività, requisiti del framework e elementi di prova in una chiamata e restituisce riferimenti compatti raggruppati per tipo di entità con segnali espliciti per sezione (ok, unauthorized, unavailable, skipped). scope: "auto" seleziona il confine nativo per tipo di entità: area di lavoro per inventario e attività, ambito di governance attuale per requisiti e prove. Utilizzo entityKinds per restringere la scoperta e l'insieme scope solo quando un confine è esplicitamente richiesto. Le query strutturate appartengono a list_* strumenti e colpi decisivi per l'abbinamento inspect/get attrezzo.

`search_entities`

Esegue la ricerca lessicale e semantica ibrida esistente all'interno di una linea di base dell'ambito di governance autorizzata e restituisce riferimenti classificati anziché record completi. I riferimenti decisivi dovrebbero essere esaminati prima di ragionare o proporre un cambiamento.

`inspect_entity`

Carica lo stato corrente compatto e con integrità controllata per un'entità inclusa nella baseline dell'ambito di governance autorizzata e pubblicizza il contesto facoltativo senza caricarlo nel contesto del modello.

`expand_entity`

Carica un segmento delimitato pubblicizzato da inspect_entity: relazioni autorizzate, stato volatile o necessità di protezione. Altri domini rimangono dietro proiezioni sicure dedicate invece dell'accesso ai dati non elaborati.

`list_implementations`, `get_implementation`, e `list_implementation_coverage`

list_implementations elenca le implementazioni attive (misure) dell'area di lavoro con titolo, tipo, modalità di fornitura e pin di revisione, facoltativamente filtrati per kind o provisionMode. get_implementation carica esattamente un'implementazione e accetta il titolo esatto oltre all'ID Convex. list_implementation_coverage risponde "come viene implementato il requisito X?": elenca gli obiettivi dei requisiti di un framework vincolante (a cui fa riferimento ID, frameworkKey, o nome) con l'implementazione collegata e lo stato del collegamento (unimplemented, partial, implemented, unresolved), facoltativamente ristretto da un codice/title cerca o linkStatus.

`list_findings` e `get_finding`

list_findings elenca i risultati della valutazione attiva dell'area di lavoro con gravità, disposizione, categoria, pin di origine e problema di riparazione collegato, facoltativamente filtrato lato server in base a severity, disposition, o category. get_finding carica esattamente un risultato e accetta il testo leggibile dall'uomo findingKey oltre all'ID Convex.

`list_risks` e `get_risk`

list_risks elenca i rischi attivi dell'area di lavoro con titolo, categoria, inerenti/residual punteggi e livelli, strategia e stato, facoltativamente filtrati lato server category, status, strategy, o residualLevel. get_risk carica esattamente un rischio compresi i suoi campi di governance e accetta il leggibile dall'uomo riskKey o il titolo esatto oltre all'ID Convex.

`get_isms_status`, `list_obligations`, e `get_obligation`

get_isms_status restituisce lo stato ISMS di un ambito di governance come isms-status/v1: confine, quadri con distribuzione di applicabilità e implementazione, rischi, prove, valutazioni, risultati, garanzia e fasi derivate con lo strumento successivo per ciascuno. list_obligations pagine attraverso il registro degli obblighi dello spazio di lavoro; get_obligation carica esattamente un obbligo per ID Convex o titolo esatto.

Creazione dell'ISMS: `create_scope`, `attach_framework`, `save_risk`, `save_measure`, `set_applicability`, `save_obligation`, e `record_assessment`

Queste azioni creano e mantengono l'ISMS dopo l'approvazione esplicita e scrivono tramite gli stessi comandi di dominio dell'app Secani con l'utente come attore. Ciascuno si aspetta organizationSlug, workspaceSlug, un governanceScopeId per strumenti limitati all'ambito e scelto dal cliente requestId (UUID); ripetere una chiamata con lo stesso requestId riprende in modo idempotente. attach_framework allega un framework disponibile di frameworkKey o nome e ne segnala uno già allegato alreadyAttached. save_risk, save_measure, e save_obligation creare senza id e aggiorna con id (cambiano solo i campi indicati). save_measure collega fino a dieci codici requisito tramite implements. set_applicability decide fino a 25 requisiti in un'unica approvazione; not_applicable e conditional richiedere un rationale, che viene memorizzato crittografato. record_assessment avvia e completa un'esecuzione di valutazione manuale per un requisito e facoltativamente genera un risultato per not_satisfied. Rapporto sulle azioni in più passaggi PARTIAL_FAILURE con i passaggi applicati in caso di fallimento parziale.

`list_tasks` e `get_task`

list_tasks elenca le attività correnti dell'area di lavoro (elementi di lavoro) con titolo, stato del flusso di lavoro, priorità, e-mail dell'assegnatario e pin di revisione; tutti i filtri (workflowState, priority, assignee come email o "me", lifecycleStatus, updatedAfter) vengono eseguiti lato server. get_task carica esattamente un'attività con i pin di revisione correnti autorevoli per le scritture successive.

`create_inventory_object`

Crea esattamente un nuovo oggetto (ad esempio un'applicazione) nell'inventario dello spazio di lavoro specificato dopo l'approvazione esplicita. Il server utilizza lo stesso comando di dominio V3 della finestra di dialogo dell'inventario Secani, scrive un evento di controllo con un attore IA e non aggiunge mai automaticamente l'oggetto a un ambito di governance.

Ingresso:

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

Il server richiede l'approvazione del modulo MCP prima di scrivere. Rifiutare o annullare non cambia nulla. I client che non possono rispondere alle approvazioni dei moduli ricevono un errore e non viene scritto nulla. requestId è la chiave di idempotenza: ripetere la chiamata con lo stesso ID e contenuto restituisce l'oggetto esistente anziché un duplicato. L'ambito di governance viene utilizzato solo per l'autorizzazione (inventory.create su tale ambito); i connettori di sola lettura non possono eseguire l'azione.

`revise_inventory_object`

Crea una nuova revisione immutabile di un oggetto di inventario esistente dopo l'approvazione. La chiamata richiede l'ID oggetto più l'ID di revisione corrente e l'hash del contenuto restituito da inspect_entity. Può modificare o rimuovere il nome, la descrizione e gli attributi rilevanti per la revisione. Se lo stato attuale cambia tra ispezione e scrittura, ritorna Secani STALE_CURRENT invece di sovrascrivere un'altra modifica.

Flusso di lavoro delle prove

Per le dichiarazioni in formato libero relative a un dominio di informazioni, search_framework_requirements restituisce i candidati delimitati dal titolo, dall'istruzione, dalla guida e dalle loro parti OSCAL nidificate all'interno di un'associazione del framework selezionato. Il rango di scoperta non è una decisione di fiducia o di conformità. Carica ogni candidato utilizzato in una conclusione con inspect_framework_requirement; i suoi dettagli autorevoli includono testo del catalogo assemblato delimitato, parametri, proprietà, applicabilità e pin di destinazione e associazione correnti. Divulgare partial, truncated, o textTruncated risultati e lasciare la scelta a un essere umano quando più candidati sono plausibili.

La superficie Evidence mantiene distinti quattro stati del dominio:

list_evidence_artifacts e inspect_evidence_artifact individuare le prove esistenti e la loro attuale versione immutabile.
create_evidence_artifact crea un riferimento o un file HTTPS; add_evidence_version aggiorna il suo contenuto aggiungendo una versione senza sovrascrivere la cronologia.
record_evidence_fact qualifica una versione dell'elemento bloccato come un'istruzione supportata relativa alla revisione di un oggetto bloccato.
link_evidence_usage assegna questo fatto a un requisito quadro bloccato. Solo questo passaggio riuscito costituisce un'assegnazione del dominio.

list_framework_bindings, list_requirement_targets, search_framework_requirements, inspect_framework_requirement, e list_evidence_subjects fornire i pin correnti richiesti e il contesto del catalogo. Gli strumenti di lettura con ambito vincolante accettano il file frameworkKey (per esempio. iso27001) o il nome del framework come scopeFrameworkBindingId oltre al Convex ID, e inspect_framework_requirement accetta anche il codice requisito (es. A.8.5) come requirementTargetId; la risoluzione avviene lato server, i riferimenti ambigui falliscono AMBIGUOUS_REFERENCE e un elenco di candidati e le risposte riportano sempre l'ID canonico risolto. list_requirement_targets e list_evidence_artifacts inoltre supporto fields per restringere ciascuna riga agli attributi selezionati più i pin ID sempre inclusi e whoami offre una chiamata di identità leggera senza espansione dell'ambito tramite includeScopes=false. Per domande sulla struttura del catalogo, list_requirement_hierarchy restituisce esattamente un livello del gruppo di un'associazione e della gerarchia di controllo (gruppi di livello superiore senza parentElementId, i figli di un elemento con esso), e get_requirement_element legge esattamente un elemento con dichiarazione, guida, parametri e, per i controlli valutabili, i riferimenti target fissati. Tutte e quattro le scritture di prove richiedono l'approvazione, sono idempotenti da parte di requestId, e registrare la provenienza dell'IA. I file fino a 512 KiB utilizzano base64 canonico. Per file più grandi, l'azione restituisce un ticket di caricamento di due minuti dopo l'approvazione; il client invia i byte non modificati con lo stesso portatore OAuth. Secani verifica la dimensione esatta e SHA-256 prima di archiviare qualsiasi cosa.

`connection_check`

Utilizza questo strumento di sola lettura per verificare la connessione dopo l'autorizzazione OAuth.

Ingresso:

{
  "echo": "optional diagnostic text"
}

La risposta conferma l'utente Secani autenticato e l'identità del client MCP. È utile come prima chiamata dopo la connessione di un nuovo client.

`human_approval_number_test`

Utilizza questo strumento per testare un flusso di lavoro completo con partecipazione umana. Propone un numero intero e chiede all'utente di accettare, rifiutare o annullare la modifica.

Ingresso:

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

Dopo l'approvazione, Secani memorizza il valore nel campo di test della finestra di dialogo Impostazioni. Se il client non è in grado di visualizzare la richiesta del modulo MCP, il valore richiesto viene considerato approvato dal fallback di compatibilità del server. Lo strumento richiede ancora un utente Secani autenticato e un segreto di prova configurato.

Flusso di lavoro consigliato

Aggiungere https://mcp.secani.com/mcp al tuo cliente.
Completa l'autorizzazione OAuth con l'account WorkOS che dovrebbe accedere a Secani.
Chiamata whoami e selezionare un'area di lavoro visibile e un ambito di governance pronto per la baseline.
Utilizzo discover_capabilities per l'intento attuale.
Ispezionare lo schema quando il significato del campo non è chiaro; avviare l'individuazione non strutturata con search, quindi utilizzare la corrispondenza inspect/get attrezzo. search_entities rimane disponibile come endpoint di compatibilità con l'ambito di governance.
Utilizzo create_inventory_object per oggetti nuovi o, dopo un'ispezione in corso, revise_inventory_object per i cambiamenti.
Carico curate-evidence per il lavoro di prova, preservare ogni revisione e hash restituiti e mantenere distinti artefatto, fatto e utilizzo.
Utilizzo connection_check o human_approval_number_test solo per il suo specifico scopo diagnostico e approvare le modifiche solo per test intenzionali.

Risoluzione dei problemi

Il cliente riferisce `401 Unauthorized`

Il server richiede un token di connessione OAuth valido per le richieste MCP. Riapri il flusso di autorizzazione MCP del cliente e conferma che l'account ha completato l'accesso a WorkOS. Non sostituire l'URL MCP con l'URL dell'emittente OAuth.

Il rilevamento OAuth non riesce

Verificare che il client utilizzi l'endpoint di produzione e possa raggiungere:

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

La risposta dei metadati indirizza il client al server di autorizzazione corretto e dichiara la richiesta openid ambito.

La richiesta di approvazione non viene visualizzata

Il client potrebbe non supportare la richiesta di moduli MCP. Aggiorna il client se possibile. Secani dispone di un fallback di compatibilità per questo strumento di test, ma dovresti comunque rivedere il valore proposto prima di consentire alla chiamata di continuare.

L'endpoint si apre come una pagina Web

L'endpoint MCP è un trasporto da macchina a macchina, non un dashboard rivolto all'uomo. Utilizza un client MCP e il flusso OAuth anziché una normale sessione del browser. Le informazioni MCP leggibili dall'uomo sono disponibili all'indirizzo secani.com/docs/mcp.

Guida alla sicurezza

Verifica il nome host prima di autorizzare: mcp.secani.com è l'host ufficiale del MCP Secani.
Utilizza OAuth tramite il tuo client MCP; non salvare o incollare mai i token di connessione nei file di origine, nei prompt o nei tracker dei problemi.
Esaminare il nome del cliente, l'account richiesto e l'ambito prima di approvare l'accesso.
Tratta l'inventario, le prove e le azioni di scrittura diagnostica come strumenti mutanti e mantieni abilitate le approvazioni dei moduli.
Mantieni abilitata la conferma umana per i flussi di lavoro che possono apportare modifiche.
Connetti solo i client MCP e le estensioni di cui ti fidi. Un client autorizzato può inviare richieste come utente Secani connesso.

In questa pagina