Secani MCP

Połącz klientów AI z uwierzytelnionym serwerem protokołu Model Context Protocol firmy Secani.

Secani MCP umożliwia zatwierdzonemu klientowi AI współpracę z Secani za pośrednictwem Modelowy protokół kontekstowy. Serwer zaprojektowano pod kątem uwierzytelnionych przepływów pracy związanych ze zgodnością z wyraźną zgodą człowieka na zmiany.

Co zapewnia Secani MCP

Secani MCP to zdalny serwer MCP dla użytkowników Secani. Wykorzystuje uwierzytelnianie na okaziciela Streamable HTTP i OAuth 2.0 w systemie WorkOS.

Punktem końcowym produkcji jest:

https://mcp.secani.com/mcp

Serwer udostępnia małą, progresywną powierzchnię narzędziową:

whoami odkrywa widoczne organizacje, obszary robocze, zakresy zarządzania i efektywny dostęp.
discover_capabilities znajduje możliwości odpowiadające zamierzeniom lub umiejętnościom; load_skill ładuje odpowiednie wskazówki dotyczące przepływu pracy.
inspect_schema, search_entities, inspect_entity, i expand_entity tworzą uniwersalną płaszczyznę odczytu. Pierwszy adapter obsługuje obiekty obszaru roboczego w wersji 3.
create_inventory_object i revise_inventory_object tworzyć obiekty magazynowe lub nowe niezmienne wersje.
Narzędzia dowodowe wyszukują, sprawdzają, tworzą, weryfikują, kwalifikują i przypisują dowody. Pliki o rozmiarze do 512 KiB można przesyłać bezpośrednio; większe pliki do 10 MiB wymagają krótkotrwałego przesyłania powiązanego z hashem.
connection_check i human_approval_number_test pozostają dostępne jako izolowane narzędzia diagnostyczne.

Szczegóły połączenia

Ustawienie	Wartość
Transport	Przesyłany strumieniowo protokół HTTP
Adres URL serwera MCP	`https://mcp.secani.com/mcp`
Metadane zasobów chronionych	`https://mcp.secani.com/.well-known/oauth-protected-resource/mcp`
Uwierzytelnianie	Token okaziciela OAuth 2.0
Wymagany zakres	`openid`
Transport nośnika	`Authorization` chodnikowiec

Punkt końcowy metadanych chronionych zasobów informuje klienta MCP, którego serwera autoryzacji WorkOS ma użyć. Skonfiguruj adres URL serwera w swoim kliencie, a następnie po wyświetleniu monitu zakończ w kliencie przepływ OAuth.

Podłącz klienta MCP

Ogólna zdalna konfiguracja MCP

W przypadku klientów akceptujących definicję zdalnego serwera MCP dodaj:

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

Dokładny plik konfiguracyjny i interfejs OAuth zależą od Twojego klienta. Użyj nazwy Secani lub secani, upewnij się, że adres URL jest dokładny https://mcp.secani.com/mcp, i zatwierdź żądanie logowania do WorkOS.

Claude'a Koda

Dodaj Secani jako zdalny serwer HTTP MCP:

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

Uruchom Claude Code i otwórz proces zarządzania MCP, aby autoryzować połączenie. Logowanie do przeglądarki jest częścią protokołu OAuth; nie wklejaj tokena okaziciela do konfiguracji projektu.

Kodeks CLI

Dodaj serwer z adresem URL HTTP:

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

Gdy Codex wykryje obsługę OAuth, postępuj zgodnie z procesem autoryzacji przeglądarki i wróć do CLI.

Kursor

Dodaj serwer do konfiguracji MCP:

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

Uruchom serwer z panelu MCP Kursora. Kursor powinien poprosić Cię o uwierzytelnienie, zanim dostępne będą chronione narzędzia.

Niestandardowe złącze ChatGPT

Jeśli Twój obszar roboczy ChatGPT obsługuje niestandardowe zdalne złącza MCP:

Włącz tryb programisty w ustawieniach łącznika.
Utwórz niestandardowy łącznik o nazwie Secani.
Ustaw adres URL serwera MCP na https://mcp.secani.com/mcp.
Wybierz uwierzytelnianie OAuth.
Ukończ proces autoryzacji WorkOS.

Dostępność i nazwy menu zależą od Twojego planu ChatGPT i konfiguracji obszaru roboczego.

Dostępne narzędzia

`whoami`

Zadzwoń do tego jako pierwszy, aby odkryć widoczne obszary robocze, maksymalnie 50 autoryzowanych zakresów zarządzania na obszar roboczy, gotowość bazową i efektywny stan tylko do odczytu lub zapisu łącznika.

`discover_capabilities`

Opcjonalnie opisz bieżący zamiar za pomocą intent lub wybierz zarejestrowaną umiejętność. Odpowiedź zawiera tylko odpowiednie możliwości dostępne w bieżącym trybie łącznika, niedostępne narzędzia umiejętności i liczbę kompaktowych zestawów narzędzi. Convex nadal wymusza autoryzację przy każdym kolejnym połączeniu.

`load_skill`

Ładuje wersjonowane wskazówki dotyczące przepływu pracy Secani, takie jak explore-workspace-context, change-inventory-object, lub curate-evidence, w tym ukierunkowane linki referencyjne. Umiejętność organizuje narzędzia publiczne, ale nie przyznaje żadnych dodatkowych uprawnień i nie udostępnia żadnych dodatkowych narzędzi. Secani używa tych samych umiejętności i nazw narzędzi.

`inspect_schema`

Ładuje klasy obiektów i metadane pól zorientowane na agenta dla jednego autoryzowanego zakresu zarządzania. Odpowiedź obejmuje wskazówki dotyczące zmienności, pobierania i wrażliwości z istniejącej umowy Kontekstu Agenta V3.

`search`

Przeszukuje obiekty obszaru roboczego, zadania, wymagania platformy i artefakty dowodów w jednym wywołaniu i zwraca kompaktowe odniesienia pogrupowane według rodzaju jednostki z wyraźnymi sygnałami dla poszczególnych sekcji (ok, unauthorized, unavailable, skipped). scope: "auto" wybiera natywną granicę dla każdego rodzaju encji: obszar roboczy dla zapasów i zadań, bieżący zakres zarządzania dla wymagań i dowodów. Używać entityKinds aby zawęzić zakres poszukiwań i ustawić scope tylko wtedy, gdy granica jest wyraźnie wymagana. Zapytania strukturalne należą do list_* narzędzia i zdecydowane trafienia w dopasowaniu inspect/get narzędzie.

`search_entities`

Uruchamia istniejące hybrydowe wyszukiwanie leksykalne i semantyczne w obrębie jednej autoryzowanej linii bazowej zakresu ładu i zwraca uporządkowane odniesienia zamiast pełnych rekordów. Decydujące odniesienia należy sprawdzić przed przedstawieniem uzasadnienia lub propozycją zmiany.

`inspect_entity`

Ładuje kompaktowy, sprawdzony pod kątem integralności bieżący stan dla jednej jednostki zawartej w linii bazowej autoryzowanego zakresu ładu i anonsuje opcjonalny kontekst bez ładowania go do kontekstu modelu.

`expand_entity`

Ładuje jeden ograniczony segment reklamowany przez inspect_entity: autoryzowane relacje, stan niestabilny lub potrzeba ochrony. Inne domeny pozostają w tyle za dedykowanymi bezpiecznymi projekcjami zamiast dostępu do surowych rekordów.

`list_implementations`, `get_implementation`, i `list_implementation_coverage`

list_implementations wyświetla listę aktywnych implementacji (miar) obszaru roboczego wraz z tytułem, rodzajem, trybem udostępniania i pinami wersji, opcjonalnie filtrowane według kind lub provisionMode. get_implementation ładuje dokładnie jedną implementację i akceptuje dokładny tytuł oprócz identyfikatora Convex. list_implementation_coverage odpowiada „w jaki sposób zaimplementowano wymaganie X?”: zawiera listę celów wymagań powiązania struktury (do których odwołuje się identyfikator, frameworkKey, lub nazwa) z powiązaną implementacją i statusem połączenia (unimplemented, partial, implemented, unresolved), opcjonalnie zawężone kodem/title wyszukaj lub linkStatus.

`list_findings` i `get_finding`

list_findings wyświetla listę wyników aktywnej oceny obszaru roboczego wraz z ważnością, dyspozycją, kategorią, kodami źródłowymi i powiązanym problemem naprawczym, opcjonalnie filtrowane po stronie serwera według severity, disposition, lub category. get_finding ładuje dokładnie jeden wynik i akceptuje tekst czytelny dla człowieka findingKey oprócz identyfikatora Convex.

`list_risks` i `get_risk`

list_risks wyświetla listę aktywnych zagrożeń w obszarze roboczym wraz z tytułem, kategorią i nieodłącznym/residual wyniki i poziomy, strategia i status, opcjonalnie filtrowane po stronie serwera według category, status, strategy, lub residualLevel. get_risk ładuje dokładnie jedno ryzyko, w tym jego pola zarządzania i akceptuje ryzyko czytelne dla człowieka riskKey lub dokładny tytuł oprócz identyfikatora Convex.

`get_isms_status`, `list_obligations`, i `get_obligation`

get_isms_status zwraca stan ISMS zakresu zarządzania jako isms-status/v1: granice, ramy z zastosowaniem i rozkładem wdrożeń, ryzyko, dowody, oceny, ustalenia, pewność i etapy pochodne z kolejnym narzędziem dla każdego. list_obligations strony rejestru obowiązków obszaru roboczego; get_obligation ładuje dokładnie jedno zobowiązanie według identyfikatora Convex lub dokładnego tytułu.

Wersja ISMS: `create_scope`, `attach_framework`, `save_risk`, `save_measure`, `set_applicability`, `save_obligation`, i `record_assessment`

Te akcje budują i utrzymują SZBI po wyraźnym zatwierdzeniu i zapisują te same polecenia domeny, co aplikacja Secani, z użytkownikiem jako aktorem. Każdy oczekuje organizationSlug, workspaceSlug, A governanceScopeId dla narzędzi o określonym zakresie i wybranych przez klienta requestId (UUID); powtarzanie połączenia z tym samym requestId wznawia idempotentnie. attach_framework dołącza dostępne ramy według frameworkKey lub nazwę i zgłasza już dołączony plik alreadyAttached. save_risk, save_measure, i save_obligation tworzyć bez id i zaktualizuj za pomocą id (zmieniają się tylko podane pola). save_measure łączy do dziesięciu kodów wymagań poprzez implements. set_applicability decyduje o aż 25 wymaganiach w jednym zatwierdzeniu; not_applicable i conditional wymagają rationale, który jest przechowywany w postaci zaszyfrowanej. record_assessment rozpoczyna i kończy ręczną ocenę jednego wymagania i opcjonalnie zgłasza wynik dla not_satisfied. Raport działań wieloetapowych PARTIAL_FAILURE z zastosowanymi krokami w przypadku częściowej awarii.

`list_tasks` i `get_task`

list_tasks wyświetla listę bieżących zadań obszaru roboczego (elementów pracy) z tytułem, stanem przepływu pracy, priorytetem, adresem e-mail przypisanej osoby i pinami wersji; wszystkie filtry (workflowState, priority, assignee jako e-mail lub "me", lifecycleStatus, updatedAfter) uruchom po stronie serwera. get_task ładuje dokładnie jedno zadanie z autorytatywnymi pinami bieżącej wersji do kolejnych zapisów.

`create_inventory_object`

Tworzy dokładnie jeden nowy obiekt (np. aplikację) w inwentarzu danego obszaru roboczego po wyraźnej zgodzie. Serwer używa tego samego polecenia domeny V3, co okno dialogowe inwentarza Secani, zapisuje zdarzenie audytu z aktorem AI i nigdy nie dodaje automatycznie obiektu do zakresu zarządzania.

Wejście:

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

Przed zapisaniem serwer prosi o zatwierdzenie formularza MCP. Odrzucenie lub anulowanie niczego nie zmienia. Klienci, którzy nie mogą odpowiedzieć na zatwierdzenia formularzy, otrzymują błąd i nic nie jest zapisywane. requestId jest kluczem idempotencji: powtórzenie wywołania z tym samym identyfikatorem i treścią zwraca istniejący obiekt zamiast duplikatu. Zakres zarządzania służy wyłącznie do autoryzacji (inventory.create w tym zakresie); łączniki tylko do odczytu nie mogą uruchomić akcji.

`revise_inventory_object`

Tworzy nową, niezmienną wersję istniejącego obiektu magazynowego po zatwierdzeniu. Wywołanie wymaga identyfikatora obiektu oraz bieżącego identyfikatora wersji i skrótu zawartości zwróconego przez inspect_entity. Może zmienić lub usunąć nazwę, opis i atrybuty istotne dla wersji. Jeśli obecny stan zmieni się pomiędzy sprawdzeniem a zapisem, Secani powraca STALE_CURRENT zamiast nadpisywać kolejną zmianę.

Obieg dowodów

W przypadku swobodnych stwierdzeń dotyczących dziedziny informacji, search_framework_requirements zwraca ograniczone kandydaci z tytułu, instrukcji, wskazówek i ich zagnieżdżonych części OSCAL w jednym wybranym powiązaniu struktury. Ranga odkrycia nie jest pewnością ani decyzją o zgodności. Załaduj każdego kandydata użytego w zakończeniu za pomocą inspect_framework_requirement; jego wiarygodne szczegóły obejmują ograniczony, złożony tekst katalogu, parametry, właściwości, zastosowanie oraz aktualne wiązanie i piny docelowe. Ujawniać partial, truncated, lub textTruncated wyników i pozostawić wybór człowiekowi, gdy prawdopodobnych jest kilka kandydatów.

Powierzchnia Dowód wyróżnia cztery stany domeny:

list_evidence_artifacts i inspect_evidence_artifact zlokalizować istniejące dowody i ich aktualną, niezmienną wersję.
create_evidence_artifact tworzy odniesienie lub plik HTTPS; add_evidence_version aktualizuje swoją zawartość poprzez dodanie wersji bez nadpisywania historii.
record_evidence_fact kwalifikuje jedną przypiętą wersję artefaktu jako obsługiwaną instrukcję dotyczącą wersji przypiętego obiektu.
link_evidence_usage przypisuje ten fakt do przypiętego wymogu ramowego. Tylko ten pomyślnie wykonany krok stanowi przypisanie domeny.

list_framework_bindings, list_requirement_targets, search_framework_requirements, inspect_framework_requirement, i list_evidence_subjects podaj wymagane aktualne piny i kontekst katalogu. Narzędzia do odczytu o zasięgu powiązania akceptują frameworkKey (np. iso27001) lub nazwę struktury jako scopeFrameworkBindingId oprócz identyfikatora Convex i inspect_framework_requirement akceptuje również kod wymagania (np. A.8.5) jako requirementTargetId; rozwiązanie odbywa się po stronie serwera, niejednoznaczne odniesienia zawodzą AMBIGUOUS_REFERENCE oraz listę kandydatów, a odpowiedzi zawsze zawierają ustalony identyfikator kanoniczny. list_requirement_targets i list_evidence_artifacts dodatkowo wspierać fields aby zawęzić każdy wiersz do wybranych atrybutów oraz zawsze dołączonych pinów identyfikacyjnych, oraz whoami oferuje lekkie połączenie identyfikacyjne bez rozszerzania zakresu poprzez includeScopes=false. W przypadku pytań dotyczących struktury katalogu, list_requirement_hierarchy zwraca dokładnie jeden poziom hierarchii grup i kontroli powiązania (grupy najwyższego poziomu bez parentElementId, z nim dzieci elementu) i get_requirement_element odczytuje dokładnie jeden element ze stwierdzeniem, wytycznymi, parametrami i – w przypadku kontroli możliwych do oceny – przypiętymi odniesieniami do celu. Wszystkie cztery zapisy dowodów wymagają zatwierdzenia i są idempotentne requestId, i zapisz pochodzenie AI. Pliki do 512 KiB używają kanonicznego base64. W przypadku większych plików akcja zwraca po zatwierdzeniu dwuminutowy bilet przesyłania; klient wysyła niezmienione bajty z tym samym nośnikiem OAuth. Secani weryfikuje dokładny rozmiar i SHA-256 przed zapisaniem czegokolwiek.

`connection_check`

Użyj tego narzędzia tylko do odczytu, aby zweryfikować połączenie po autoryzacji OAuth.

Wejście:

{
  "echo": "optional diagnostic text"
}

Odpowiedź potwierdza tożsamość uwierzytelnionego użytkownika Secani i klienta MCP. Przydaje się jako pierwsze połączenie po podłączeniu nowego klienta.

`human_approval_number_test`

Użyj tego narzędzia, aby przetestować kompletny przepływ pracy oparty na działaniu człowieka w pętli. Proponuje liczbę całkowitą i prosi użytkownika o zaakceptowanie, odrzucenie lub anulowanie zmiany.

Wejście:

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

Po zatwierdzeniu Secani zapisuje wartość w polu testowym okna dialogowego Ustawienia. Jeśli klient nie może wyświetlić żądania formularza MCP, żądana wartość jest traktowana jako zatwierdzona przez rezerwową kompatybilność serwera. Narzędzie nadal wymaga uwierzytelnionego użytkownika Secani i skonfigurowanego klucza testowego.

Zalecany przepływ pracy

Dodać https://mcp.secani.com/mcp swojemu klientowi.
Wykonaj autoryzację OAuth na koncie WorkOS, które powinno uzyskać dostęp do Secani.
Dzwonić whoami i wybierz widoczny obszar roboczy i zakres zarządzania gotowy do planu bazowego.
Używać discover_capabilities dla obecnego zamiaru.
Sprawdź schemat, gdy znaczenie pola jest niejasne; rozpocznij odkrywanie niestrukturalne za pomocą search, następnie użyj dopasowania inspect/get narzędzie. search_entities pozostaje dostępny jako punkt końcowy zgodności zakresu ładu.
Używać create_inventory_object dla obiektów nowych lub po bieżącym przeglądzie, revise_inventory_object na zmiany.
Obciążenie curate-evidence w przypadku prac dowodowych należy zachować każdą zwróconą wersję i skrót oraz zachować odrębność artefaktów, faktów i zastosowań.
Używać connection_check lub human_approval_number_test wyłącznie w konkretnym celu diagnostycznym, a zmiany zatwierdzać wyłącznie w celach zamierzonych badań.

Rozwiązywanie problemów

Klient zgłasza `401 Unauthorized`

Serwer wymaga prawidłowego tokena okaziciela OAuth dla żądań MCP. Otwórz ponownie proces autoryzacji MCP klienta i potwierdź, że konto zakończyło logowanie się do WorkOS. Nie zastępuj adresu URL MCP adresem URL wystawcy protokołu OAuth.

Wykrywanie OAuth nie powiodło się

Sprawdź, czy klient korzysta z produkcyjnego punktu końcowego i może uzyskać dostęp do:

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

Odpowiedź metadanych wskazuje klientowi właściwy serwer autoryzacji i deklaruje wymagane openid zakres.

Monit o zatwierdzenie nie pojawia się

Klient może nie obsługiwać wywoływania formularzy MCP. Jeśli to możliwe, zaktualizuj klienta. Secani ma rezerwę zgodności dla tego narzędzia testowego, ale mimo to powinieneś sprawdzić proponowaną wartość przed zezwoleniem na kontynuację połączenia.

Punkt końcowy otwiera się jako strona internetowa

Punkt końcowy MCP to transport między maszynami, a nie pulpit nawigacyjny skierowany do człowieka. Użyj klienta MCP i przepływu OAuth zamiast zwykłej sesji przeglądarki. Informacje MCP czytelne dla człowieka są dostępne pod adresem secani.com/docs/mcp.

Wskazówki dotyczące bezpieczeństwa

Przed autoryzacją sprawdź nazwę hosta: mcp.secani.com jest oficjalnym gospodarzem Secani MCP.
Użyj protokołu OAuth za pośrednictwem klienta MCP; nigdy nie zatwierdzaj ani nie wklejaj tokenów nośnika do plików źródłowych, monitów ani elementów śledzących problemy.
Przed zatwierdzeniem dostępu przejrzyj nazwę klienta, żądane konto i zakres.
Traktuj akcje dotyczące zapasów, dowodów i zapisu diagnostycznego jako narzędzia mutujące i włączaj zatwierdzanie formularzy.
Włącz potwierdzenie przez człowieka dla przepływów pracy, które mogą wprowadzać zmiany.
Podłączaj tylko zaufanych klientów MCP i rozszerzenia. Autoryzowany klient może wysyłać żądania jako podłączony użytkownik Secani.

Na tej stronie