Interfejs MCP

W skrócie

MitoOps udostępnia standardowy zdalny serwer MCP (Model Context Protocol) pod adresem /api/mcp, przez który zgodna aplikacja AI sama pobiera dane. Stoi na tych samych możliwościach co REST: nie jest to drugi interfejs z własnymi zapytaniami, lecz inny sposób zadania tego samego pytania.

MCP nie jest cechą modelu, lecz aplikacji, w której model działa (klienta). Podłączy się każda aplikacja, która obsługuje zdalne MCP przez HTTP z OAuth lub z kluczem dostępu. Claude.ai to produkcyjnie sprawdzony klient: jego dokładna procedura jest poniżej; dla innej aplikacji obowiązuje ogólna procedura w kolejnej części. Klientów, których nie przetestowaliśmy, nie ogłaszamy jako sprawdzonych.

Uwierzytelnić się można na dwa sposoby:

• kluczem dostępu wydanym w aplikacji: dla własnego programu lub serwera, który wywołuje serwer;
• przez OAuth, gdy łączy się aplikacja AI, która to potrafi: wtedy loguje się użytkownik i na ekranie zgody wybiera, co aplikacja może odczytywać.

W obu przypadkach token jest przesyłany w nagłówku Authorization: Bearer i w obu obowiązuje ten sam zakres uprawnień: czego klucz lub zgoda nie obejmuje, tego narzędzie nie zwróci.

Jak podłączyć Claude.ai: sprawdzone połączenie krok po kroku

Claude.ai nie łączy się z poszczególnymi e-shopami, lecz z MitoOps, czyli z warstwą, która już łączy dane wszystkich e-shopów. Nie potrzeba żadnego klucza, Client ID ani tajnego klucza. Claude.ai wszystko ustala sam z adresu interfejsu.

1. W Claude.ai otworzyć Settings (Ustawienia) → Customize → Connectors (w planie zespołowym najpierw Organization settings → Connectors jako administrator).
2. Nacisnąć Add custom connector (Dodaj własny konektor).
3. W polu Name wpisać MitoOps.
4. W polu URL wkleić adres interfejsu MCP z ekranu Ustawienia → API & MCP, w postaci https://<adres aplikacji>/api/mcp, na przykład https://app.mitoops.com/api/mcp.
5. Advanced settings pozostawić puste: Claude.ai użyje własnych hostowanych metadanych klienta (OAuth). Nacisnąć Add.
6. Przy konektorze nacisnąć Connect (Połącz).
7. Otworzy się logowanie do MitoOps (także z drugim czynnikiem, jeśli jest włączony). Należy się zalogować.
8. Pojawi się ekran zgody: która aplikacja, który klient, co może odczytywać i których e-shopów to dotyczy. Uprawnienia są pogrupowane według obszarów aplikacji (sprzedaż, magazyn, wysyłka, marketing, program partnerski, automatyzacje). Odczyt jest wstępnie zaznaczony, dane wrażliwe i przygotowanie szkiców nie; zmiany o bezpośrednim skutku (na przykład usuwanie kuponów lub zatwierdzenie wysyłki) są pojedynczo w zwiniętej sekcji Uprawnienia zaawansowane. Przy każdej grupie jest lista tego, co dokładnie obejmuje.
9. Sprawdzić zakresy. Wrażliwe (na przykład Zestawienia, Ceny zakupu i marże, Dane osobowe klientów, Dostawcy i zakupy, Automatyzacje: szkice, Dostępności: propozycje zmian i Reklamacje: propozycje zmian ustawień) nie są zaznaczone. Jeśli Claude ma widzieć marżę, dane osobowe, proponować szkice i zmiany automatyzacji albo zmiany dostępności czy ustawień reklamacji, należy zaznaczyć je świadomie. Szablony i ustawienia reklamacji odczytuje zakres Reklamacje: ustawienia i szablony. Wybrać e-shopy.
10. Nacisnąć Zezwól. Claude.ai wraca na swoją stronę, a konektor jest podłączony.
11. W rozmowie nacisnąć + → Connectors i włączyć konektor MitoOps.

Konektor podłączony przed 2.09.2026

Jeśli konektor został podłączony wcześniej, Claude.ai ma w pamięci podręcznej starsze metadane i na ekranie zgody oferował tylko cztery podstawowe zakresy. Konektor należy odłączyć (Disconnect) i podłączyć ponownie (Connect): zaoferowane zostaną wszystkie zakresy, w tym wrażliwe i nowe (wysyłka, analityka, zapasy).

To, co zostanie zaznaczone na ekranie zgody, obowiązuje, i nigdy nie więcej, niż może sam użytkownik. Kto nie ma w aplikacji prawa do cen zakupu, nie może go przekazać dalej. Token, który otrzymuje Claude.ai, niesie tylko dozwolone zakresy.

Inny klient MCP lub aplikacja AI przez OAuth

Aplikacji podaje się ten sam adres /api/mcp i nic więcej, żadnego klucza. Dalej odbywa się to samo:

1. Aplikacja pyta nas, dokąd skierować logowanie (metadane chronionego zasobu według RFC 9728).
2. Otwiera się logowanie do MitoOps.
3. Pojawia się ekran zgody, na którym wybiera się zakresy i e-shopy.
4. Po zezwoleniu połączenie jest gotowe, a aplikacja widzi narzędzia.

Aplikacja, która sama wybiera zakresy, musi podać je w żądaniu: ekran zgody zaoferuje tylko to, o co aplikacja poprosiła (i do czego użytkownik ma prawo). Interfejs ogłasza wszystkie zakresy, w tym wrażliwe, zarówno w wyzwaniu WWW-Authenticate, jak i w scopes_supported. Wrażliwe mimo to nigdy nie są przyznawane same: na ekranie zgody są oznaczone i niezaznaczone, a token jest wydawany zawężony do tego, na co zezwolono (scope w odpowiedzi tokenu).

Jak połączyć się kluczem dostępu

Asystent lub program potrzebuje adresu /api/mcp w domenie aplikacji i klucza dostępu z MCP wśród interfejsów. Dokładny adres wypisuje ekran Ustawienia → API & MCP w bloku „Gdzie to podłączyć”. Klucz wydany tylko dla REST nie działa w MCP i odwrotnie.

Narzędzia

Lista narzędzi zależy od zakresów klucza lub zgody: asystent zobaczy dokładnie to, na co mu zezwolono, i nic więcej. Narzędzie spoza zakresu dla niego nie istnieje.

Narzędzie MCP	Zakres	REST	Co zwraca
account_connection	stores:read	GET /account/connection	Diagnostyka tego połączenia: aplikacja, kto i kiedy udzielił dostępu, przyznane i brakujące uprawnienia według obszarów, e-sklepy i tryb zapisu przez AI.
account_entitlements	account:read	GET /account/entitlements	Taryfa klienta, funkcje i limity z aktualnym wykorzystaniem.
affiliate_articles_create	affiliate:write	—	zapis: Założenie własnego artykułu pomocy we wszystkich językach naraz (tytuł i treść w podanym języku); HTML zostaje oczyszczony.
affiliate_articles_get	affiliate:read	GET /affiliate/articles/:key	Jeden artykuł pomocy z treścią (HTML) we wszystkich językach lub w jednym; zmienne niepodstawione.
affiliate_articles_list	affiliate:read	GET /affiliate/articles	Artykuły pomocy portalu partnerskiego: klucz, domyślny/własny, włączenie, kolejność, stan według języków (tytuł, adres, wypełnione, zgodne z domyślnym).
affiliate_articles_set_state	affiliate:write	—	zapis: Włączenie lub wyłączenie artykułu pomocy dla wszystkich języków naraz; domyślny nie jest usuwany, tylko wyłączany.
affiliate_articles_update	affiliate:write	—	zapis: Edycja artykułu pomocy w jednym języku (tytuł, adres, treść; HTML zostaje oczyszczony) lub przywrócenie domyślnej treści; zwraca nieznane zmienne.
affiliate_campaigns_create	affiliate:write	—	zapis: Założenie kampanii w e-shopie: nazwa, wynagrodzenie (nie wymyślać), ważność przypisania, dostępność, zatwierdzanie konwersji.
affiliate_campaigns_get	affiliate:read	GET /affiliate/campaigns/:campaignId	Jedna kampania programu partnerskiego.
affiliate_campaigns_list	affiliate:read	GET /affiliate/campaigns	Kampanie programu partnerskiego e-shopu z wynagrodzeniem, dostępnością i liczbami.
affiliate_campaigns_update	affiliate:write	—	zapis: Edycja kampanii: nazwa, wynagrodzenie, ważność, dostępność, zatwierdzanie, włączenie/wyłączenie, opis dla partnerów według języków.
affiliate_code_requests_decide	affiliate:write	—	zapis: Obsługa wniosku partnera o własny kod: zatwierdzenie od razu zakłada kod w e-shopach kampanii z rabatem dla klienta (wymaga także coupons:write), retry powtarza zakładanie, odrzucenie wymaga powodu; partner otrzymuje e-mail.
affiliate_code_requests_list	affiliate:read	GET /affiliate/code-requests	Wnioski partnerów o własny kod rabatowy ze stanem i powodem; oczekujące najpierw.
affiliate_conversions_decide	affiliate:approve	—	zapis: Decyzja o jednej prowizji według id: approve (nowa → zatwierdzona), reject (nowa → odrzucona, powód obowiązkowy), cancel (zatwierdzona → anulowana, powód obowiązkowy); wypłacona nie jest cofana, ta sama decyzja drugi raz niczego nie zmienia; partner otrzymuje e-mail.
affiliate_conversions_get	affiliate:read	GET /affiliate/conversions/:conversionId	Szczegóły jednej konwersji: kwoty, prowizja, stan prowizji z powodem, status zamówienia w e-shopie, korekta, wypłata.
affiliate_conversions_list	affiliate:read	GET /affiliate/conversions	Konwersje programu partnerskiego e-shopu: podstawa prowizji i całe zamówienie z VAT, prowizja, stan prowizji z powodem, status zamówienia w e-shopie, powiązanie z wypłatą.
affiliate_discount_codes_ensure	coupons:write	—	zapis: Aby partner miał w e-shopie kod rabatowy: kupon zostaje założony przez kanoniczne kupony (lub użyty istniejący) i przypisany partnerowi; notatka w e-shopie powstaje automatycznie.
affiliate_discount_codes_list	affiliate:read	GET /affiliate/discount-codes	Kody rabatowe partnerów w e-shopie z liczbą użyć i obrotem.
affiliate_documents_draft_create	affiliate:write	—	zapis: Propozycja nowej treści dokumentu prawnego jako projekt; obowiązującej treści nie zmienia, publikuje ją człowiek w aplikacji z różnicami i audytem.
affiliate_documents_get	affiliate:read	GET /affiliate/documents/:key/content	Jeden dokument prawny programu z treścią według języków (zapisany tekst, treść publiczna, wersja, odciski, źródło, metadane PDF) i otwartymi projektami.
affiliate_documents_list	affiliate:read	GET /affiliate/documents	Dokumenty programu (warunki, umowy): polityka potwierdzania, podpisana kopia, załącznik e-maila, wersje według języków, gotowość i liczby potwierdzeń.
affiliate_documents_update	affiliate:write	—	zapis: Polityka dokumentu programu (kogo dotyczy, kiedy jest potwierdzany, podpisana kopia, załącznik e-maila, włączenie); treść przesyła się w aplikacji.
affiliate_email_templates_list	affiliate:read	GET /affiliate/email-templates	Szablony e-maili do partnerów według języków (temat, włączenie, ze zdarzeniem także treść) i automatyczne załączniki e-maila Konto zatwierdzone.
affiliate_email_templates_update	affiliate:write	—	zapis: Edycja szablonu e-maila do partnerów w jednym języku (temat, treść) lub włączenie/wyłączenie zdarzenia.
affiliate_links_generate	affiliate:read	GET /affiliate/links/generate	Śledzony link partnerski do strony głównej, produktu lub kategorii e-shopu kampanii; po kliknięciu zachowuje przypisanie do partnera.
affiliate_partners_get	affiliate:read	GET /affiliate/partners/:partnerId	Jeden partner programu z kampaniami, które ma do dyspozycji.
affiliate_partners_list	affiliate:read	GET /affiliate/partners	Partnerzy programu ze stanem, wynikami i prowizjami; kontakt tylko z danymi osobowymi.
affiliate_partners_set_market	affiliate:write	—	zapis: Członkostwo partnera w e-shopie: udostępnić (active, zatwierdza też wniosek z portalu) lub odebrać (revoked); kampanie, kupony i dokumenty e-shopu dotyczą partnera tylko przy aktywnym członkostwie.
affiliate_partners_set_state	affiliate:write	—	zapis: Decyzja o koncie partnera (zatwierdzić, odrzucić, zawiesić, przywrócić do oczekujących); zatwierdzenie wysyła e-mail z umową.
affiliate_payouts_list	affiliate:read	GET /affiliate/payouts	Wypłaty prowizji partnerom ze stanem; bez danych bankowych i rozliczeniowych.
affiliate_portal_get	affiliate:read	GET /affiliate/portal	Publiczny portal partnera: adresy według e-shopów, otwartość rejestracji z powodem, własne domeny, osoba kontaktowa, wygląd i stan tekstów według języków.
affiliate_portal_pages_update	affiliate:write	—	zapis: Własne teksty publicznego portalu w jednym języku (strony logowania/rejestracji/przeglądu, informacja, opis programu); HTML zostaje oczyszczony.
affiliate_settings	affiliate:read	GET /affiliate/settings	Ustawienia programu partnerskiego: prowizje, kliknięcia, minimum wypłaty, polecenia.
affiliate_settings_update	affiliate:write	—	zapis: Ustawienia programu poza pieniędzmi: nazwa, rejestracja, automatyczne zatwierdzanie, osoba kontaktowa, kolory, link do zasad.
affiliate_signatures_get	affiliate:read	GET /affiliate/signatures/:signatureId	Jeden podpis elektroniczny z podpisaną treścią i migawką wartości; niezmienny rekord, PDF składa się w aplikacji.
affiliate_signatures_list	affiliate:read	GET /affiliate/signatures	Dokumenty partnerów podpisane elektronicznie (kto, dokument, wersja, język, e-shop, czas, sposób, weryfikacja, odciski, stan) oraz partnerzy, którym brakuje podpisu; tylko odczyt, podpis powstaje wyłącznie w portalu.
affiliate_statistics	affiliate:read	GET /affiliate/statistics	Statystyka programu partnerskiego: przebieg według dni, źródła przypisania, ranking partnerów.
affiliate_summary	affiliate:read	GET /affiliate/summary	Przegląd programu partnerskiego e-shopu za okres: kliknięcia, konwersje, prowizje, partnerzy.
affiliate_variables_list	affiliate:read	GET /affiliate/variables	Rejestr zmiennych treści i e-maili programu partnerskiego: nazwy kanoniczne, aliasy, typ, miejsca użycia, przykład; opcjonalna kontrola tekstu pod kątem nieznanych zmiennych.
analytics_advertising	reports:read	GET /analytics/advertising	Reklama: wydatki, budżet, ROAS, udział wydatków w obrocie, CPA, średnia wartość zamówienia i MER z porównaniem; Google Ads i Meta Ads, kliknięcia z GA4, 6 miesięcy.
analytics_channels	analytics:read	GET /analytics/channels	Rozkład wizyt, zamówień i obrotu według kanałów marketingowych.
analytics_comparison	reports:read	GET /analytics/comparison	Obrót z porównaniem: obrót, zamówienia, AOV, wizyty, CR i AI/LLM wobec poprzedniego okresu lub roku.
analytics_monthly	reports:read	GET /analytics/monthly	Obrót, zamówienia i wizyty według miesięcy (maksymalnie 24), na przykład rok do roku.
analytics_order_coverage	analytics:read	GET /analytics/order-coverage	Pokrycie zamówień i obrotu pomiarem w analityce.
analytics_order_heatmap	reports:read	GET /analytics/order-heatmap	Kiedy przychodzą zamówienia: dzień tygodnia × godzina, najsilniejszy dzień i godzina.
analytics_overview	analytics:read	GET /analytics/overview	Wizyty, zamówienia, obrót, współczynnik konwersji i udział AI/LLM za okres.
analytics_revenue_sources	reports:read	GET /analytics/revenue-sources	Skąd pochodzi obrót: kanały, sumy AI/LLM, MitoOps i Affiliate, pozyskanie według GA4.
analytics_seo	analytics:read	GET /analytics/seo	Search Console: kliknięcia, wyświetlenia, CTR i pozycja według zapytań lub stron.
automations_catalog	automations:read	GET /automations/catalog	Katalog automatyzacji: wyzwalacze, warunki, operatory, akcje, szablony; catalogVersion dla propozycji.
automations_create_draft	automations:write	—	zapis: Tworzy WYŁĄCZONY szkic automatyzacji. Nie włącza go ani nie uruchamia.
automations_get	automations:read	GET /automations/:workflowId	Jedna automatyzacja z DSL i wynikiem walidacji.
automations_list	automations:read	GET /automations	Automatyzacje klienta ze stanem i zakresem e-shopów.
automations_options	automations:read	GET /automations/options	Słownik dla pola automatyzacji (statusy, metody dostawy, płatności, szablony, reklamacje…): value do DSL i nazwa.
automations_revision_create_draft	automations:write	—	zapis: Proponuje zmianę opublikowanej automatyzacji jako rewizję do zatwierdzenia przez człowieka. Działająca wersja się nie zmienia.
automations_revision_discard_draft	automations:write	—	zapis: Wycofuje otwartą rewizję opublikowanej automatyzacji.
automations_revision_update_draft	automations:write	—	zapis: Edytuje otwartą rewizję opublikowanej automatyzacji.
automations_runs	automations:read	GET /automations/:workflowId/runs	Historia przebiegów jednej automatyzacji.
automations_templates	automations:read	GET /automations/templates	Gotowe wzory automatyzacji z DSL.
automations_update_draft	automations:write	—	zapis: Edytuje nieopublikowany szkic automatyzacji z optymistyczną współbieżnością.
automations_validate_draft	automations:read	—	Sprawdza propozycję automatyzacji bez zapisu.
chatbot_conversations_get	chatbot-conversations:read	GET /chatbot/conversations/:sessionId	Zapis jednej rozmowy z chatbotem internetowym wraz ze źródłami odpowiedzi bota.
chatbot_conversations_list	chatbot-conversations:read	GET /chatbot/conversations	Rozmowy klientów z chatbotem internetowym od ostatnio aktywnej, z pierwszym pytaniem; kursor.
chatbot_outcomes	chatbot:read	GET /chatbot/outcomes	How web chatbot conversations ended: since when the outcome is measured, measured and unmeasured conversations, known and unknown outcome, resolved, unresolved, bot error and resolution rate with its denominator; N/A with a reason when the denominator is zero. Totals only.
chatbot_stats	chatbot:read	GET /chatbot/stats	Statystyka chatbota internetowego za okres: lejek dymka, otwarcia, rozmowy, wyniki, oceny.
chatbot_topics	chatbot:read	GET /chatbot/topics	O czym były rozmowy: udziały tematów, produkty, typ strony początkowej i kandydaci na lukę w wiedzy.
claims_config_change_draft	claims-settings:draft	—	zapis: Proponuje zmianę procesów, stanów, etykiet, szablonów, tekstów formularza i ustawień modułu reklamacji; zapisze ją dopiero człowiek po zatwierdzeniu w aplikacji.
claims_config_draft_get	claims-settings:read	GET /claims/config-drafts/:draftId	Stan propozycji zmiany ustawień reklamacji (czeka, zapisana, odrzucona).
claims_configuration	claims-settings:read	GET /claims/configuration	Ustawienia reklamacji: etykiety, pola, transport zwrotny, formularz w e-shopie, typy formularza.
claims_get	claims:read	GET /claims/:code	Jedno zgłoszenie z pozycjami i powiązaniami: zamówienie, korekta, przesyłka zwrotna, ruch magazynowy.
claims_list	claims:read	GET /claims	Reklamacje i zwroty jednego e-shopu od najnowszego.
claims_refund_options	claims-settings:read	GET /claims/refund-options	Refunds: variable symbol source, refund coupon validity, coupon in the form, when the form asks for an account number.
claims_refund_readiness	claims:read	GET /claims/:code/refund-readiness	Claim before a refund: what the customer requests, masked account, variable symbol, mode and whether the claim can be deleted.
claims_refund_settings	claims-settings:read	GET /claims/refund-settings	Zwroty reklamacji: tryb, konta bankowe z przydatnością do poleceń przelewu (zamaskowane), konto domyślne i ręczne.
claims_routes	claims-settings:read	GET /claims/routes	Transport zwrotny reklamacji: trasy, adresy, profile przewoźników z ID i obsługą zwrotów, typy zgłoszeń.
claims_routes_change_draft	claims-routes:draft	—	zapis: Proponuje trasę zwrotu (także dla całej UE lub świata) i adres odbiorcy; zapisze je człowiek po zatwierdzeniu (lub autonomiczny zapis, jeśli klient go włączył).
claims_settings	claims:read	GET /claims/settings	Procesy reklamacji z ID i nazwami (typy, kroki, statusy, terminy), etykiety; ustawienia modułu z zakresem claims-settings:read.
claims_statistics	claims:read	GET /claims/statistics	Statystyka reklamacji i zwrotów za okres: liczby, czasy obsługi, typy, oceny, powody.
claims_templates	claims-settings:read	GET /claims/templates	Szablony e-maili (temat, tekst, kiedy i czy są wysyłane automatycznie) oraz protokołów reklamacji.
content_articles_search	products:read	GET /content/articles	Artykuły bloga e-shopu z adresem na stronie i obrazkiem podglądu.
coupons_activation_link	coupons:read	GET /coupons/activation-link	Link, który zastosuje klientowi ISTNIEJĄCY kupon w koszyku. Kuponu nie tworzy.
coupons_activation_status	coupons:read	GET /coupons/activation-status	Czy kupon w e-shopie można użyć przez link aktywacyjny: lustro kuponu + stan kodu na stronie.
coupons_capabilities	coupons:read	GET /coupons/capabilities	Co o kuponach potrafi platforma danego e-shopu. Warto odczytać przed zakładaniem.
coupons_ensure	coupons:write	—	zapis: Aby kupon w wybranych e-shopach istniał. Przy innej wysokości rabatu NIE ZOSTANIE NADPISANY.
coupons_get	coupons:read	GET /coupons/:code	Jeden kupon z ewidencji MitoOps. Gdy go w niej nie ma, odpowiedź to „nie znaleziono”.
coupons_list	coupons:read	GET /coupons	Kupony rabatowe e-shopu z typem i wysokością rabatu, ważnością i wyprowadzonym stanem.
coupons_remove	coupons:delete	—	zapis: Wyraźne usunięcie kuponu: zależności, podgląd, potwierdzenie; z aktywną zależnością nie jest usuwany.
coupons_update	coupons:write	—	zapis: Wyraźna edycja istniejącego kuponu łącznie z ograniczeniami do produktów i kategorii; podgląd, potem potwierdzenie.
customers_get	customers:read	GET /customers/:customerKey	Jeden klient z katalogu: tożsamość, e-shopy, kwoty LIFETIME i opcjonalnie PERIOD, rozbicie według e-shopów.
customers_list	customers:read	GET /customers	Katalog klientów: tożsamość (z maskowaniem PII), e-shopy, język, liczby LIFETIME i obrót według walut; opcjonalny filtr aktywności zakupowej w okresie.
customers_performance	reports:read	GET /customers/performance	Klienci jako pseudonimy: liczba zamówień, obrót, pierwsze i ostatnie zamówienie, ponowny zakup, LTV.
credit_notes_search	invoices:read	GET /credit-notes	Wyszukiwanie w korektach.
documents_list	invoices:read	GET /documents	Dokumenty księgowe jednego rodzaju (faktury, faktury zaliczkowe, korekty) stronami z cyklem życia, stanem w źródle, filtrem ważności i dostępnością PDF.
documents_pdf_link	invoices:read	—	Krótkotrwały link (10 minut) do PDF faktury, faktury zaliczkowej lub korekty do otwarcia w przeglądarce.
invoices_get	invoices:read	GET /invoices/:invoiceCode	Jedna faktura z pozycjami, kwotami, korektami i fakturami zaliczkowymi do niej.
invoices_search	invoices:read	GET /invoices	Wyszukiwanie w fakturach.
inventory_movements	inventory:read	GET /inventory/movements	Historia ruchów magazynowych: kiedy, co, o ile, dlaczego i z jakiego źródła.
inventory_product_availability	inventory:read	GET /inventory/availability	Stan zapasu dla wielu pozycji naraz.
inventory_stock	inventory:read	GET /inventory/stock	Stan zapasu jednej pozycji wraz ze źródłem wartości.
orders_get	orders:read	GET /orders/:orderCode	Jedno zapisane zamówienie łącznie z pozycjami.
orders_list	orders:read	GET /orders	Zapisane zamówienia jednego e-shopu, od najnowszego.
availabilities_change_draft	availabilities:draft	—	zapis: PROPOZYCJA zmiany słownika dostępności (założyć, edytować, usunąć). Do e-shopu zapisuje ją dopiero człowiek, zatwierdzając w MitoOps.
availabilities_draft_get	products:read	GET /availabilities/drafts/:draftId	Stan propozycji zmiany słownika dostępności: czeka na zatwierdzenie, zapisana z wynikiem, odrzucona, wygasła.
availabilities_list	products:read	GET /availabilities	Słownik dostępności e-shopu: nazwa, opis, zaopatrzenie, dostawa, znaczenie dla Google, kolor, rola domyślna.
categories_content_change_draft	category-content:draft	—	zapis: PROPOZYCJA nowych tekstów kategorii (do 30 naraz); do sklepu zapisuje je dopiero człowiek, zatwierdzając w MitoOps.
categories_content_draft_get	category-content:read	GET /catalog/category-content-drafts/:draftId	Stan propozycji tekstów kategorii: czeka na zatwierdzenie, zapisana, odrzucona, wygasła.
categories_content_get	category-content:read	GET /categories/:guid/content	Teksty kategorii (górny i dolny opis, tytuł i opis SEO) z odciskiem i możliwością zapisu pola.
categories_list	products:read	GET /categories	Kategorie e-shopu z liczbą produktów.
products_content_change_draft	product-content:draft	—	zapis: PROPOZYCJA nowych tekstów produktów (do 30 naraz); do sklepu zapisuje je dopiero człowiek, zatwierdzając w MitoOps.
products_content_draft_get	product-content:read	GET /catalog/product-content-drafts/:draftId	Stan propozycji tekstów produktów: czeka na zatwierdzenie, zapisana z uwagami sklepu, odrzucona, wygasła.
products_content_get	product-content:read	GET /products/:code/content	Teksty produktu ze sklepu (opis, krótki opis, tytuł i opis SEO) z odciskiem i możliwością zapisu pola.
products_content_policy	product-content:read	GET /product-content/policy	Zasady treści sklepu bez odpytywania sklepu: co ten dostęp może czytać i proponować, które pola platforma zapisze, tryb zatwierdzania i zapis autonomiczny, limity i odciski.
products_get	products:read	GET /products/:code	Jeden produkt według kodu łącznie z klasyfikacją i ceną z karty.
products_search	products:read	GET /products	Wyszukiwanie produktów według nazwy, kodu, EAN lub PLU.
reports_financial_summary	reports:read	GET /reports/financial-summary	Podsumowanie finansowe okresu: obrót, VAT, zamówienia, AOV; z uprawnieniami także zakup, zysk brutto, koszty i wynik.
sales_order_performance	reports:read	GET /sales/order-performance	Obrót według zamówień w EUR z sumami za cały okres; z uprawnieniem także zakup, zysk brutto i marża na zamówienie.
sales_product_performance	reports:read	GET /sales/product-performance	Sprzedaż według produktów z dokumentów; z uprawnieniem także cena zakupu w czasie sprzedaży i marża.
search_console_query	search-console:read	GET /search-console/query	Search Console według dni, zapytań, stron, krajów i urządzeń, ze stronicowaniem i skrótem zawartości.
search_console_status	search-console:read	GET /search-console/status	Stan Search Console sklepu: połączenie, właściwość, uprawnienia, synchronizacja i zakres archiwum.
shipping_carriers	shipping:read	GET /shipping/carriers	Podłączeni przewoźnicy i ich profile, bez danych dostępowych.
shipping_shipment_detail	shipping:read	GET /shipping/shipments/:shipmentId	Jedna przesyłka ze wszystkimi zdarzeniami śledzenia.
shipping_shipments	shipping:read	GET /shipping/shipments	Przesyłki jednego e-shopu z przewoźnikiem, krajem oraz czasami przekazania i doręczenia.
shipping_stats	shipping:read	GET /shipping/stats	Statystyki doręczeń według przewoźników: liczby, skuteczność, mediana i p90 czasu doręczenia, kraje.
stores_integration_status	stores:read	GET /stores/integration-status	Stan kodu MitoOps na stronie według e-shopów: zainstalowany, wersja, moduły, gotowość kuponu z adresu.
stores_list	stores:read	GET /stores	Lista e-shopów klienta wraz z ich kodem.
suppliers_get	purchasing:read	GET /suppliers/:supplierId	Jeden dostawca z ofertami produktów i składnikami kosztów.
suppliers_list	purchasing:read	GET /suppliers	Dostawcy klienta z liczbą ofert i powiązanych produktów.
webhooks_deliveries	webhooks:read	GET /webhooks/endpoints/:endpointId/deliveries	Dziennik doręczeń jednego endpointu bez treści.
webhooks_endpoint	webhooks:read	GET /webhooks/endpoints/:endpointId	Jeden endpoint webhooka z liczbą oczekujących doręczeń.
webhooks_endpoints	webhooks:read	GET /webhooks/endpoints	Endpointy webhooków klienta bez tajnych kluczy i stan kolejki.
webhooks_events	webhooks:read	GET /webhooks/events	Katalog zdarzeń webhooków wychodzących, koperta i podpis.

Imię i nazwisko, e-mail, telefon i ulica klienta są w orders_list, orders_get, claims_list i claims_get tylko z zakresem personal-data:read; bez niego odpowiedź zawiera kraj i miasto. To samo dotyczy kontaktu dostawcy i partnera programu (affiliate_partners_*). Zakres nie ma własnego narzędzia.

W katalogu klientów (customers_list, customers_get) ten sam zakres decyduje o imieniu i nazwisku, firmie, e-mailu, telefonie i płci marketingowej; bez niego zostaje pseudonim, e-shopy, kraj, język, liczby i daty. Obrót i LTV wymagają dodatkowo reports:read. Płeć marketingowa to szacunek na podstawie imienia (genderSource: "name_inference"), a nie dana podana przez klienta; asystent powinien ją tak przedstawiać. Dane bankowe i podatkowe partnerów nigdy nie są wydawane.

Chatbot internetowy: tematy rozmów. chatbot_topics (ten sam zakres chatbot:read) odpowiada jednym wywołaniem na pytanie „o czym to było”: udział rozmów według tematów z zamkniętej taksonomii (transport, płatność, zwrot, wybór produktu, parametry, użytkowanie, pytania edukacyjne…), wskaźnik rozwiązania i liczba kandydatów na lukę w wiedzy według tematu, najczęstsze produkty (o które pytali klienci i które polecił bot), z jakiego typu strony zaczynają się rozmowy i przebieg według dni. Ocena jest deterministyczna: opiera się na źródłach odpowiedzi, polecanych produktach i słowniku słów kluczowych, więc dwa wywołania dla tego samego okresu dają tę samą liczbę. Zwraca tylko sumy: tekst klienta nie trafia do niej żadną drogą, nawet jako „najczęstsze pytanie”. Udział jest zawsze podawany z liczbą: przy małej liczbie rozmów procent jest niewiarygodny. chatbot_conversations_list ma filtry topic i knowledgeGapCandidate; zapis konkretnej rozmowy nadal wymaga wrażliwego zakresu i jest dostępny tylko w ramach retencji.

Chatbot internetowy. Statystyka (chatbot_stats, zakres chatbot:read) zwraca tylko sumy: ilu wizytom na stronie pokazał się dymek i ile z nich w niego kliknęło, otwarcia okna, liczbę rozmów i wiadomości, co bot załatwił, oceny klientów i lejek zapisu na newsletter. Rozmowy klientów (chatbot_conversations_list, chatbot_conversations_get) wymagają własnego wrażliwego zakresu chatbot-conversations:read, który na ekranie zgody zaznacza się świadomie: klient jest w ewidencji tylko losowym kluczem rozmowy (bez IP, cookie, imienia czy e-maila), a e-mail, telefon i IBAN, które wpisał w tekst, asystent otrzymuje tylko z personal-data:read; w przeciwnym razie zamiast nich widzi znacznik [e-mail], [telefón], [iban]. Rozmowy są wydawane tylko w ramach retencji e-shopu (ustawienie Historia w Centrum AI); e-shop z retencją zero nie wyda niczego. Wyświetlenia dymka do 21.09.2026 były liczone przy każdym wyskoczeniu wiadomości; od 22.09.2026 wyświetlenie to jedna wizyta na stronie, a measurementChanges w odpowiedzi mówi, czy wybrany okres łączy oba pomiary.

Każde narzędzie ma odpowiednik w REST opierający się na tej samej możliwości. Odpowiedzi różnią się kopertą, dane biznesowe są zgodne. Zasady okresu, stronicowania i znaczenie pól finansowych opisuje interfejs REST.

Narzędzia zbiorcze (shipping_stats, analytics_*, reports_financial_summary) zwracają gotowe liczby z aplikacji: asystent nie musi pobierać tysięcy rekordów i liczyć sam. Surowe listy (shipping_shipments, orders_list) pozostają do szczegółowego wglądu.

O co można pytać

Po podłączeniu Claude.ai odpowie na podstawie danych MitoOps na przykład na pytania:

• „Jaki był procentowy rozkład metod dostawy w sierpniu?”: shipping_stats
• „Jaka była mediana czasu doręczenia DHL i GLS?” i „Ile było niedoręczonych i zwróconych?”: shipping_stats
• „Do których krajów wysyłaliśmy przez DHL?”: shipping_stats (pole countries)
• „Jaki był obrót i współczynnik konwersji w sierpniu?”: analytics_overview lub reports_financial_summary
• „Ile zamówień i obrotu przyszło z ChatGPT?”: analytics_channels
• „Które zapytania miały najwyższe CTR?”: analytics_seo
• „Jaka jest marża produktu X za ostatni miesiąc?”: sales_product_performance (z purchase-prices:read)
• „O co klienci najczęściej pytali chatbota w tym miesiącu i o czym napisać artykuł na blog?”: chatbot_conversations_list i chatbot_conversations_get (z chatbot-conversations:read)
• „Ile rozmów miał chatbot i ile z nich załatwił bez pomocy technicznej?”: chatbot_stats
• „Jakie dostępności ma e-shop SK i które są domyślne?” (availabilities_list)
• „Dodaj w e-shopie SK dostępność Przedsprzedaż październik ze znaczeniem przedsprzedaż i dostawą do 14 dni” (availabilities_change_draft z availabilities:draft; powstanie propozycja, którą zapisuje się, zatwierdzając ją w aplikacji)
• „Zmień włączoną automatyzację 12 tak, aby wysyłała powiadomienie tylko przy dostawie Kurier” (automations_options dla metody dostawy, potem automations_revision_create_draft; działająca wersja się nie zmieni, dopóki rewizja nie zostanie opublikowana w edytorze)
• „Jakie e-maile reklamacje wysyłają automatycznie i co w nich jest po niemiecku?” (claims_templates z claims-settings:read)
• „Zmień nazwę statusu reklamacji Czeka na towar na Czekamy na przesyłkę” (claims_settings dla ID, potem claims_config_change_draft z claims-settings:draft; zapisuje się, zatwierdzając w aplikacji)

Odczyt i wąskie zapisy: automatyzacje, kupon, program partnerski, dostępności, reklamacje

Dane operacyjne (zamówienia, stan zapasów, produkty, dokumenty, przesyłki) są przez MCP tylko odczytywane. Każdy zapis wymaga własnego wrażliwego zakresu: szkic automatyzacji, kupon rabatowy, zarządzanie programem partnerskim, decyzja o prowizji, propozycja zmiany słownika dostępności, którą do e-shopu zapisuje dopiero człowiek, oraz propozycja zmiany ustawień reklamacji, którą również zapisuje dopiero człowiek.

Szkic automatyzacji: z zakresem automations:write jest to wyłączony szkic: asystent może według katalogu (automations_catalog) zaproponować regułę i zapisać ją jako szkic albo edytować szkic, którego nikt jeszcze nie opublikował. Szkic pojawia się w Automatyzacjach jak każda rozpoczęta propozycja; włączyć, opublikować lub uruchomić go może tylko człowiek w aplikacji. Opublikowanej automatyzacji asystent bezpośrednio nie zmieni.

Rewizja działającej automatyzacji. Także opublikowaną i włączoną automatyzację asystent z zakresem automations:write może zmienić, ale tylko propozycją: automations_revision_create_draft (wejście workflowId, expectedPublishedVersion z automations_get, catalogVersion, całe nowe dsl, note i clientRequestId) zapisuje rewizję obok działającej wersji. Działająca automatyzacja się nie zmienia i działa dalej. Na jedną automatyzację przypada najwyżej jedna otwarta rewizja; edytuje się ją przez automations_revision_update_draft z expectedRevisionVersion, a odrzuca przez automations_revision_discard_draft. Odpowiedź zawiera approvalUrl, link do edytora automatyzacji. Tam człowiek z prawem do edycji automatyzacji zobaczy rewizję w górnym panelu, wczyta ją do edytora (przycisk Wczytaj propozycję do edytora), sprawdzi i opublikuje zwykłym przyciskiem; automatyzacja pozostaje włączona. Albo ją odrzuci. Gdy w międzyczasie ktoś opublikował inną wersję, rewizja zostaje zamknięta (REVISION_STALE) i trzeba przygotować nową. Otwartą rewizję i historię zwraca automations_get (openRevision, revisions).

Słowniki pól i weryfikacja wartości. Pola, które w edytorze wybiera się z listy (status zamówienia, metoda dostawy, płatność, profil przewoźnika, szablon powiadomienia, typ, status, etykieta i szablony reklamacji, endpoint webhooka i inne), mają w katalogu źródło. automations_options z source i market zwraca ich wartości [{ value, name }] dokładnie w postaci, w jakiej zapisuje je edytor (ID statusu, GUID metody dostawy i płatności, ID statusu reklamacji); bez source wypisuje źródła i to, czy dla każdego e-shopu są inne (perShop). Walidacja (automations_validate_draft) oraz zapis szkicu czy rewizji odrzuci wartość, która w e-shopie nie istnieje (FIELD_UNKNOWN_OPTION), i tekst zastępczy typu DOPLNIT_… lub TODO (FIELD_PLACEHOLDER). Gdy listy nie da się sprawdzić (e-shop nie odpowiedział, lista jest obcięta), przychodzi tylko ostrzeżenie FIELD_OPTIONS_UNVERIFIED. orders_get i orders_list zawierają statusId, shippingGuid i paymentGuid, czyli te same wartości, z którymi pracują warunki automatyzacji.

Zakres automations:write jest wrażliwy: na ekranie zgody nie jest wstępnie zaznaczony, jest oferowany tylko człowiekowi z prawem do edycji automatyzacji, istniejące połączenia go nie otrzymają, a odświeżenie tokenu go nie rozszerzy. Zamówień, produktów, stanu zapasów, dokumentów, refundacji, zgłoszeń reklamacyjnych ani przesyłek nie da się przez MCP zmieniać; słownik dostępności e-shopu i ustawienia reklamacji zmienia się tylko propozycją, którą zatwierdza człowiek w aplikacji (poniżej). Endpointy webhooków są przez MCP tylko odczytywane. Danych dostępowych do przewoźników, e-shopu ani analityki nie da się przez MCP odczytać.

Kupon rabatowy: z zakresem coupons:write asystent zakłada kupon według podanych parametrów (coupons_ensure, także kupon partnera affiliate_discount_codes_ensure) i wyraźnie edytuje istniejący (coupons_update, podgląd i potwierdzenie); usuwanie ma własny zakres coupons:delete, a kupon z aktywną zależnością nie zostanie usunięty.

Zarządzanie programem partnerskim: z zakresem affiliate:write asystent decyduje o koncie partnera (affiliate_partners_set_state: zatwierdzić, odrzucić, zawiesić; partner otrzymuje e-mail z PDF umowy zgodnie z polityką dokumentów), obsługuje wniosek o własny kod (affiliate_code_requests_decide), edytuje ustawienia programu poza pieniędzmi (affiliate_settings_update: nazwa, rejestracja, osoba kontaktowa, kolory), teksty portalu w jednym języku (affiliate_portal_pages_update), artykuły pomocy (affiliate_articles_create, affiliate_articles_update, także z przywróceniem domyślnej treści, affiliate_articles_set_state; usuwania z zewnątrz nie ma), szablony e-maili (affiliate_email_templates_update), kampanie (affiliate_campaigns_create, affiliate_campaigns_update), politykę dokumentów (affiliate_documents_update) i członkostwo partnera w e-shopie (affiliate_partners_set_market: udostępnić lub odebrać). Treść dokumentów prawnych odczytuje (affiliate_documents_get: tekst według języków, wersja, odciski, projekty), a nową treść proponuje tylko jako projekt (affiliate_documents_draft_create; także privacyNotice w affiliate_portal_pages_update jest od tej wersji projektem); obowiązującą treść publikuje człowiek w aplikacji z różnicami i audytem. Rejestr zmiennych treści i e-maili (nazwy kanoniczne, aliasy, typ, miejsca użycia) wydaje affiliate_variables_list; affiliate_email_templates_list zwraca nazwy zmiennych, a nie indeksy. Wypłaty, podstawa prowizji ani przesłanie pliku dokumentu przez MCP nie istnieją: pozostają w aplikacji.

Decyzja o prowizji: z własnym wrażliwym zakresem affiliate:approve (prawo zatwierdzanie prowizji, a nie zarządzanie programem) asystent najpierw odczytuje oczekujące prowizje wraz ze statusem zamówienia w e-shopie (affiliate_conversions_list z state=new, szczegóły affiliate_conversions_get: podstawa prowizji revenue, całe zamówienie z VAT revenueTotal, orderState open/completed/cancelled, orderPaid, korekta), podsumowuje je i dopiero na wyraźne polecenie użytkownika decyduje o jednej konkretnej konwersji (affiliate_conversions_decide: approve, reject lub cancel, przy odrzuceniu i anulowaniu z obowiązkowym powodem, który partner otrzymuje e-mailem). Obowiązuje ten sam automat stanów co w aplikacji: wypłacona prowizja nie jest cofana, anulowana i odrzucona są końcowe, ta sama decyzja drugi raz niczego nie zmienia (changed: false). Zbiorczego zatwierdzania z zewnątrz nie ma: na sto konwersji przypada sto wywołań, każde z audytem. Od W-AFF10 każda konwersja niesie też approvalPolicy (sposób zatwierdzania kampanii, okres, dozwolone statusy zamówienia, zapłata) i approvalEligibility: czy godzinna automatyka zatwierdziłaby ją teraz i dlaczego nie (minimum_age_not_reached, order_state_not_allowed, order_not_paid, order_cancelled, fully_refunded, approval_manual…), to samo obliczenie co w aplikacji; lista ma filtry orderPaid, minCommission, orderState i stronicowanie offset + hasMore, więc „przejrzyj nowe konwersje z dwóch miesięcy, pokaż nieopłacone lub te powyżej 20 €” to jeden lub kilka odczytów. Warunki kampanii ustawia affiliate_campaigns_update (approval, approveAfterDays, requiredOrderStatusIds, paidRequired) z zakresem affiliate:write. Wypłaty partnerom są przez MCP tylko odczytywane (affiliate_payouts_list): wystawić partii, wygenerować dokumentu, wysłać go partnerowi ani złożyć polecenia w banku asystent nie potrafi; pozostaje to w aplikacji w rękach operatora.

Propozycja zmiany słownika dostępności. Z wrażliwym zakresem availabilities:draft asystent przygotowuje propozycję, jak w jednym e-shopie założyć, edytować lub usunąć dostępności (availabilities_change_draft, tylko MCP). Do e-shopu niczego nie zapisuje: sprawdza propozycję, zapisuje ją w MitoOps na 24 godziny i zwraca draftId, podgląd według pozycji (preview z polami przed i po, warnings i errors), expiresAt i approvalUrl, link do ekranu Magazyn → Dostępności, gdzie propozycja czeka na karcie Zarządzanie. Tam człowiek z uprawnieniem zatwierdza ją przyciskiem Zatwierdź i zapisz lub odrzuca, a zapis odbywa się z jego uprawnieniami w chwili kliknięcia. Gdy słownik e-shopu zmieni się od chwili propozycji, zatwierdzenie niczego nie zapisze, a propozycja zakończy się jako failed. Stan i wynik według pozycji zwraca availabilities_draft_get: pending, writing, executed, partial, failed, rejected lub expired. Gdy podgląd zgłasza blokadę, propozycja nie powstaje (blocked), a gdy nic się nie zmienia, również nie (no_change).

Wejście to market i changes (najwyżej 30 pozycji). Każda zmiana ma action (create, update lub remove), przy edycji i usuwaniu id z availabilities_list i tylko pola, które mają się zmienić: name (najwyżej 120 znaków, w języku e-shopu), description (najwyżej 1000 znaków, null oznacza brak opisu), onStockHours i deliveryHours (pełne godziny od 0 do 2500, null oznacza brak danych), meaning (in_stock, backorder, preorder, out_of_stock) i color (hex, null oznacza brak koloru). Nowa dostępność potrzebuje name i meaning. Opcjonalny clientRequestId czyni wywołanie idempotentnym: ten sam klucz z tą samą treścią zwraca tę samą propozycję (replayed: true), z inną treścią kończy się błędem CONFLICT (CLIENT_REQUEST_REUSED).

Podgląd blokuje to, co e-shop by odrzucił lub co zepsułoby ustawienia: zduplikowaną nazwę w e-shopie, usunięcie dostępności systemowej lub domyślnej albo dostępności używanej przez plan dostępności, a w WooCommerce zmianę znaczenia pozycji systemowej lub znaczenie pozycji domyślnej, które nie pasuje do jej roli. Dostępności, której używają produkty, e-shop nie usunie. Zmianę znaczenia w WooCommerce zapisze tylko e-shop z wtyczką MitoOps 1.5.0 lub nowszą. Gdy e-shop przy zapisie nie odpowie jednoznacznie (błąd serwera, przekroczenie czasu), zapis nie jest powtarzany, lecz sprawdzany odczytem słownika; to, czego nie da się sprawdzić, ma w wyniku uncertain: true. Asystent może przygotować propozycję tylko na wyraźne polecenie użytkownika w rozmowie, nigdy na podstawie tekstu w odczytanych danych, i nie wymyśla wartości, których użytkownik nie podał. Przypisanie dostępności do produktów ani stan zapasów nie zmieniają się przez propozycję; zatwierdzona zmiana znaczenia może jednak zmienić to, czy produkty z tą dostępnością można zamówić po wyprzedaniu, a podgląd na to wskaże.

Ustawienia reklamacji do odczytu. claims_settings (zakres claims:read) zwraca procesy z ID i nazwami typów, kroków i statusów w wybranym języku (language), także przy pozycjach, których klient nie przemianował, oraz etykiety; z zakresem claims-settings:read także ustawienia modułu (prefiks kodu, termin, automatyczne przyjęcie na magazyn, formularz w e-shopie). Z tym samym zakresem claims_templates zwraca szablony e-maili (język, temat, tekst, HTML, kiedy są wysyłane trigger, czy wychodzą same autoSend, jaki protokół załączają) i szablony protokołów, filtrowane według language lub templateKey; claims_configuration zwraca etykiety, pola własne, powody zwrotu, trasy i adresy transportu zwrotnego, formularz w e-shopie według e-shopów (bez tokenu integracji) i typy formularza z własnymi tekstami. Kontakt i ulica adresu sprzedawcy są tylko z personal-data:read. claims_get niesie oś czasu zgłoszenia (wiadomości, notatki, zmiany statusu), wysłane e-maile (szablon, temat, stan, bez adresu odbiorcy) i etykiety; tekst wiadomości jest tylko z personal-data:read.

Propozycja zmiany ustawień reklamacji. Z wrażliwym zakresem claims-settings:draft asystent przygotowuje propozycję (claims_config_change_draft, tylko MCP): założyć lub edytować typ, krok i status procesu (nazwy według języków, kolor, status domyślny i zamykający, termin), etykietę, tekst szablonu e-maila w jednym języku, jego automatyczne wysyłanie i tekst szablonu protokołu. Usuwania nie ma. Do ustawień niczego nie zapisuje: sprawdza propozycję tymi samymi zasadami co ekran (na przykład nieznana zmienna w szablonie ją zablokuje), zapisuje ją w MitoOps na 72 godziny i zwraca draftId, podgląd (preview, pole przed i po, errors), expiresAt i approvalUrl, link do Reklamacje → Ustawienia, gdzie propozycja czeka w panelu Propozycje zmian do zatwierdzenia. Człowiek z prawem do zarządzania ustawieniami ją zatwierdza (Zatwierdź i zapisz) lub odrzuca. Propozycja zapisuje się w całości albo wcale: gdy któraś wartość zmieniła się od przygotowania propozycji, nic nie zostanie zapisane, a propozycja zakończy się jako failed. Stan zwraca claims_config_draft_get (pending, executed, failed, rejected, expired); gdy podgląd zgłasza błąd, propozycja nie powstaje (blocked), a gdy nic się nie zmienia, również nie (no_change). ID i klucze asystent bierze z claims_settings i claims_templates; clientRequestId czyni wywołanie idempotentnym.

Narzędzia niosą adnotacje zgodne z rewizją protokołu (readOnlyHint, destructiveHint, idempotentHint); automations_create_draft jest idempotentny przez clientRequestId, automations_update_draft wymaga expectedVersion i przy zmianie katalogu zwraca CATALOG_CHANGED; automations_revision_create_draft jest idempotentny przez clientRequestId, a automations_revision_update_draft wymaga expectedRevisionVersion.

Uprawnienie można odebrać

Anulowanie uprawnienia w Ustawienia → API & MCP unieważnia wszystkie dostępy, które z niego powstały, natychmiast, a nie po wygaśnięciu. To samo dzieje się po odłączeniu konektora w Claude.ai.

Wersje protokołu

Serwer obsługuje rewizję 2026-07-28 oraz starsze (2025-11-25, 2025-06-18, 2025-03-26). Klient wybiera sam według tego, co wyśle; starsze biblioteki klienckie połączą się więc bez zmian.

Nowsza rewizja nie ma wstępnego handshake’u ani sesji: każde żądanie niesie własną wersję i obowiązkowe nagłówki MCP-Protocol-Version, Mcp-Method, a przy wywołaniu narzędzia Mcp-Name. Jeśli nagłówek rozchodzi się z treścią, odpowiedź to 400: kierowanie według nagłówków i wykonywanie według treści oznaczałoby dwa źródła prawdy o tym samym wywołaniu.

Powiązane

• Przegląd
• Interfejs REST
• Webhooki wychodzące
• Dostępności