Budowa serwera MCP dla WooCommerce: przewodnik praktyka

#Budowa serwera MCP dla WooCommerce: przewodnik praktyka

Model Context Protocol daje agentowi AI typowaną, introspektywną powierzchnię do działania na sklepie. WooCommerce już udostępnia REST API pod /wp-json/wc/v3/. Postawienie MCP przed nim zamienia tę powierzchnię w coś, co LLM potrafi wywołać bez zgadywania nazw parametrów. To jest architektura, którą wdrażam dla klientów chcących mieć katalog i intencję zamówienia osiągalne z poziomu Claude’a, ChatGPT lub własnego runtime’u agenta.

Artykuł osadzony jest w usłudze budowa serwera MCP i filarze Universal Commerce Protocol.

#TL;DR

• MCP siedzi przed REST WooCommerce jako typowana powierzchnia JSON-RPC.
• Trzy narzędzia pokrywają większość potrzeb agenta: catalogue.list, product.detail, order.intent.
• Schematy Zod definiują każde wejście i wyjście i działają przy każdym wywołaniu.
• Mapuj pola WooCommerce na schema.org Product i Offer, by odpowiedzi agenta były spójne między powierzchniami.
• Cloudflare Workers to mój domyślny cel wdrożenia dla serwerów MCP zdominowanych przez odczyty.

#Czym właściwie jest MCP

Anthropic ogłosił Model Context Protocol 25 listopada 2024 (anthropic.com/news/model-context-protocol). To otwarty protokół na bazie JSON-RPC 2.0, który pozwala klientowi (hostowi LLM jak Claude Desktop, IDE lub własnemu runtime’owi agenta) rozmawiać z serwerem (twoją implementacją MCP) po stdio lub przez Streamable HTTP. Ten transport HTTP zastąpił w wersji specyfikacji 2025-03-26 starsze HTTP z Server-Sent Events.

Trzy prymitywy:

• Tools. Wywoływalne funkcje z typowanym wejściem i wyjściem. Agent wybiera jedno i wywołuje je.
• Resources. Odczytywalne referencje do dokumentów lub rekordów, które agent może wciągnąć do kontekstu.
• Prompts. Szablony promptów dostarczane przez serwer, które host może wywołać.

Dla sklepu WooCommerce główne obciążenie ciągną tools. Przeglądanie katalogu to wywołanie narzędzia. Szczegóły produktu to wywołanie narzędzia. Zaproponowanie zamówienia to wywołanie narzędzia. Resources przydają się, gdy agent potrzebuje pełnego tekstu warunków zwrotów lub długiego opisu produktu; prompts przydają się, gdy chcesz dostarczyć gotowe interakcje (“zaproponuj trzy produkty dla tego profilu klienta”).

#Co zmienia specyfikacja MCP 2026-07-28 w serwerze dla WooCommerce

Obowiązująca rewizja specyfikacji nosi datę 28 lipca 2026 (lista zmian). Dla serwera, który stoi przed sklepem, liczą się cztery zmiany.

Protokół nie ma już sesji. Znika uzgadnianie initialize, a w transporcie Streamable HTTP także nagłówek Mcp-Session-Id. Każde żądanie niesie swoją wersję protokołu i możliwości klienta w _meta. Worker, który dla każdego żądania buduje nowy serwer, pasuje do tego modelu, bo między wywołaniami nie ma stanu połączenia do przechowania.

Stan podróżuje jako argument. Jeśli serwer potrzebuje stanu między wywołaniami, specyfikacja zaleca zwracać jawny identyfikator z narzędzia tworzącego i przyjmować go jako argument w kolejnych wywołaniach (narzędzia ze stanem). Jej własny przykład to koszyk z basket_id. Szkic, który zwraca order.intent, działa według tego wzorca: ID szkicu jest uchwytem. Ta sama sekcja każe przy każdym wywołaniu sprawdzać uprawnienia wywołującego względem uchwytu, podać czas życia w opisie narzędzia (tu 24 godziny) i zwracać błąd wykonania, gdy przychodzi uchwyt wygasły albo nieznany, żeby model utworzył nowy.

Serwer musi implementować server/discover, metodę, którą ogłasza obsługiwane wersje protokołu, swoje możliwości i tożsamość.

Listy można cache’ować. Wyniki tools/list mają teraz pola ttlMs i cacheScope, a serwer powinien zwracać narzędzia w deterministycznej kolejności. Pięć narzędzi, które zmieniają się tylko przy wdrożeniu, zniesie długie ttlMs.

Transport HTTP+SSE jest przestarzały od wersji 2025-03-26, a nowe serwery używają Streamable HTTP. Wersja 2 SDK TypeScript obsługuje obie generacje protokołu z tego samego punktu wejścia (wersje protokołu w dokumentacji SDK), więc klient, który wciąż zaczyna od initialize, nadal działa.

#Jakie narzędzia MCP potrzebuje sklep WooCommerce

Zanim napiszę linijkę kodu, spisuję intencje, które agent ma móc wyrazić wobec sklepu. Dla typowego sklepu WooCommerce lista jest krótka:

1. Przeglądanie katalogu z filtrami (catalogue.list).
2. Pełne szczegóły jednego produktu (product.detail).
3. Zaproponowanie zamówienia w imieniu klienta, zwracane jako szkic do potwierdzenia przez człowieka (order.intent).
4. Sprawdzenie statusu istniejącego zamówienia po numerze i adresie e-mail (order.status).
5. Zapytanie o stan magazynowy SKU (inventory.check).

Każda intencja mapuje się dokładnie na jedno narzędzie. Oprzyj się pokusie wystawienia wc.products.get, wc.products.list, wc.orders.create jako jeden-do-jednego wrappera REST. Agent nie zyskuje na czasownikach REST; zyskuje na czasownikach intencji.

#Jak zdefiniować narzędzia MCP w Zod

SDK TypeScript (pakiet @modelcontextprotocol/server w wersji 2; wersja 1 nazywała się @modelcontextprotocol/sdk) używa Zod (zod.dev) do schematów wejścia i wyjścia. Tak wygląda kontrakt dla catalogue.list:

import { z } from "zod";

export const catalogueListInput = z.object({
  query: z.string().min(2).max(200).optional(),
  category: z.string().optional(),
  in_stock: z.boolean().optional(),
  price_min: z.number().nonnegative().optional(),
  price_max: z.number().nonnegative().optional(),
  page: z.number().int().min(1).max(100).default(1),
  per_page: z.number().int().min(1).max(50).default(12),
});

export const catalogueListOutput = z.object({
  results: z.array(
    z.object({
      sku: z.string(),
      name: z.string(),
      url: z.string().url(),
      price: z.object({
        amount: z.number().nonnegative(),
        currency: z.string().length(3),
      }),
      availability: z.enum(["InStock", "OutOfStock", "BackOrder", "PreOrder"]),
      image: z.string().url().optional(),
    })
  ),
  total: z.number().int().nonnegative(),
  page: z.number().int(),
});

Dwie rzeczy są tu istotne. Po pierwsze, wyjście używa słownika schema.org (InStock, OutOfStock, BackOrder, PreOrder to wartości wprost z ItemAvailability). Po drugie, wejście odrzuca śmieci na granicy protokołu; handler nigdy nie zobaczy query: "" ani ujemnego price_min.

Każde narzędzie deklaruję tym samym wzorcem: schemat wejścia, schemat wyjścia, handler. Handler to cienki adapter nad /wp-json/wc/v3/. Zod uruchamia się dwa razy na wywołanie: raz na wejściu, raz na wyjściu. Sprawdzenie wyjścia łapie błędy handlera, które inaczej przeciekałyby do agenta jako zniekształcone dane.

#Jak rejestrować narzędzia MCP z adnotacjami i ustrukturyzowanym wyjściem

W wersji 2 SDK pakiet po stronie serwera to @modelcontextprotocol/server, a każde narzędzie rejestruje się przez registerTool, które przyjmuje nazwę, konfigurację i handler (narzędzia w dokumentacji SDK). Ze schematami z poprzedniej sekcji catalogue.list wygląda tak:

import { McpServer } from "@modelcontextprotocol/server";

export function createWooCommerceMcpServer(env: Env): McpServer {
  const server = new McpServer({ name: "woocommerce", version: "1.0.0" });

  server.registerTool(
    "catalogue.list",
    {
      title: "Browse the catalogue",
      description: "List store products with filters and pagination",
      inputSchema: catalogueListInput,
      outputSchema: catalogueListOutput,
      annotations: { readOnlyHint: true },
    },
    async (input) => {
      const output = await handleCatalogueList(input);
      return {
        content: [{ type: "text", text: JSON.stringify(output) }],
        structuredContent: output,
      };
    }
  );

  // product.detail, inventory.check, order.status, order.intent
  return server;
}

Gdy narzędzie deklaruje outputSchema, specyfikacja wymaga, żeby serwer zwracał structuredContent zgodne z tym schematem, a klient powinien je walidować (narzędzia w specyfikacji). SDK robi tę walidację, zanim wynik opuści serwer. Ze względu na starsze klienty specyfikacja zaleca zwracać dodatkowo zserializowany JSON w bloku tekstowym. To jest content w przykładzie.

Adnotacje opisują zachowanie narzędzia. readOnlyHint mówi, że narzędzie nie zmienia swojego otoczenia. destructiveHint (domyślnie true) i idempotentHint (domyślnie false) mają znaczenie tylko wtedy, gdy readOnlyHint jest false. openWorldHint (domyślnie true) mówi, czy narzędzie wchodzi w interakcję z otwartym światem zewnętrznych bytów. Cztery narzędzia odczytu mają readOnlyHint: true. order.intent ma readOnlyHint: false i destructiveHint: false, bo tworzy szkic i niczego nie usuwa. idempotentHint zostawiam na false, bo idempotency_key jest opcjonalny, a bez niego dwa identyczne wywołania tworzą dwa szkice. Według dokumentacji SDK host może automatycznie zatwierdzić narzędzie tylko do odczytu i pytać o potwierdzenie przed destrukcyjnym. Specyfikacja wymaga jednak, żeby klienty traktowały adnotacje jako niezaufane, chyba że pochodzą z zaufanego serwera, więc sprawdzanie zakresu tokenu zostaje po stronie serwera.

Nazwy z kropką, takie jak catalogue.list, mieszczą się w zaleceniu specyfikacji: od 1 do 128 znaków, tylko litery ASCII, cyfry, podkreślnik, myślnik i kropka. Błędy idą dwoma kanałami. Nieznane narzędzie albo źle zbudowane żądanie to błąd protokołu i wraca jako błąd JSON-RPC. Błąd API WooCommerce albo argument spoza zakresu to błąd wykonania i wraca w wyniku, z isError: true i tekstem, który model może wykorzystać do poprawki. product.detail z nieistniejącym SKU powinien zwrócić ten drugi rodzaj, z komunikatem, że takiego SKU nie ma, żeby model zmienił argument i spróbował ponownie.

#Jak połączyć serwer MCP z REST API WooCommerce

Handler catalogue.list czyta z /wp-json/wc/v3/products:

async function handleCatalogueList(input: z.infer<typeof catalogueListInput>) {
  const params = new URLSearchParams();
  if (input.query) params.set("search", input.query);
  if (input.category) params.set("category", input.category);
  if (input.in_stock) params.set("stock_status", "instock");
  if (input.price_min !== undefined) params.set("min_price", String(input.price_min));
  if (input.price_max !== undefined) params.set("max_price", String(input.price_max));
  params.set("page", String(input.page));
  params.set("per_page", String(input.per_page));

  const response = await fetch(
    `${WC_BASE}/wp-json/wc/v3/products?${params.toString()}`,
    { headers: { Authorization: `Basic ${WC_AUTH}` } }
  );

  const products = await response.json();
  const total = Number(response.headers.get("X-WP-Total") ?? 0);

  return catalogueListOutput.parse({
    results: products.map(mapWooProductToSchemaOrg),
    total,
    page: input.page,
  });
}

Helper mapWooProductToSchemaOrg przekłada nazwy pól WooCommerce (stock_status, regular_price, permalink) na kształt zgodny ze schema.org z deklaracji wyjścia. Mapowanie pól w jednym miejscu, wywoływane z jednego narzędzia, wywoływanego z jednego handlera. Drift między aktualizacjami WooCommerce a kontraktem agenta łapie wywołanie parse na wyjściu, nie produkcja.

W order.intent z handlera nigdy nie wywołuję endpointów piszących WooCommerce. Narzędzie zwraca szkic zamówienia, który host pokazuje użytkownikowi, użytkownik potwierdza, i dopiero wtedy osobna ścieżka uwierzytelniona woła POST /wp-json/wc/v3/orders. Pisanie na wiarę z LLM-a to zły default. W polskim sklepie wpisuje się to dodatkowo w obowiązek z art. 17 ustawy o prawach konsumenta i RODO art. 25 (privacy by design); szkic pozwala dopasować przyciski “kupuję i płacę” oraz zgody marketingowe przed wykonaniem operacji.

#Jak utworzyć klucze REST API WooCommerce dla serwera MCP

Serwer MCP rozmawia z WooCommerce parą kluczy REST API: Consumer Key i Consumer Secret. Według oficjalnej dokumentacji (uwierzytelnianie REST API) tworzy się je w zaawansowanych ustawieniach WooCommerce, na ekranie REST API (wp-admin/admin.php?page=wc-settings&tab=advanced&section=keys). Trzy cechy tych kluczy wpływają na projekt serwera.

Każdy klucz należy do użytkownika WordPressa, a żądania wysłane z nim podlegają rolom i uprawnieniom tego użytkownika. Jeśli użytkownik zostanie usunięty, klucz przestaje działać i nie przechodzi na innego użytkownika. Dlatego dla serwera MCP zakładam osobnego użytkownika technicznego, zamiast wieszać klucz na koncie osoby, która kiedyś odejdzie z firmy.

Poziom dostępu to odczyt, zapis albo odczyt i zapis. Narzędzia odczytu używają klucza tylko do odczytu. Klucz z prawem zapisu zna wyłącznie osobna trasa, która potwierdza zamówienie przez POST /wp-json/wc/v3/orders.

Przez HTTPS uwierzytelnianie odbywa się przez HTTP Basic: Consumer Key jest nazwą użytkownika, a Consumer Secret hasłem. To jest nagłówek Authorization: Basic w handlerze catalogue.list.

Paginację też opisuje dokumentacja (paginacja). Domyślnie API zwraca 10 elementów na stronę, per_page i page to zmieniają, a nagłówki X-WP-Total i X-WP-TotalPages niosą łączną liczbę zasobów i stron. Handler czyta X-WP-Total, żeby wypełnić total.

Dwa szczegóły endpointu produktów (lista produktów) wpływają na schemat. Parametr category filtruje po ID kategorii, a nie po slugu, więc agent potrzebuje ID albo serwer musi przetłumaczyć slug przed wywołaniem. A stock_status przyjmuje instock, outofstock i onbackorder. Dla trzeciej wartości schema.org ma BackOrder, dlatego enum wyjścia catalogue.list ją zawiera. Bez niej produkt, który można zamówić mimo braku na stanie (backorder), nie przeszedłby walidacji wyjścia.

Aktualizacja, 23 października 2026: WooCommerce ogłosił 21 października, że wersja 11.3 usuwa jego własny endpoint MCP, /wp-json/woocommerce/mcp, razem z nagłówkiem X-MCP-API-Key, którym uwierzytelniał się kluczem REST API. Serwer z tego poradnika z tego endpointu nie korzysta. Woła /wp-json/wc/v3/ z kluczami consumer, a ta ścieżka zostaje. Jeśli podłączyłeś też klienta MCP do wbudowanego endpointu, przenieś go przed aktualizacją: zainstaluj wtyczkę MCP Adapter, utwórz hasło aplikacji dla użytkownika, który ma tylko uprawnienia potrzebne klientowi, i wskaż klientowi /wp-json/mcp/mcp-adapter-default-server. Wzorzec zewnętrznego serwera przenosi się na sklep na Shopify albo na backend headless, bo zmieniają się tylko handlery, które odpytują sklep.

Aktualizacja, 24 października 2026: WooCommerce 11.3 dodaje też eksperymentalne API rozszerzalnych zdolności, extensible abilities (blog deweloperski WooCommerce, 22 października 2026). Rozszerzenia mogą dopinać własne pola, filtry zapytań i walidatory do zdolności produktów, zamówień i pozycji zamówienia, więc agent czyta i zmienia dane rozszerzenia przez zdolności, których już używa. Funkcja jest domyślnie wyłączona, włącza się ją w WooCommerce > Settings > Advanced > Features w sekcji eksperymentalnej, a WooCommerce prosi, żeby na razie nie używać jej na produkcji. Dla zewnętrznego serwera takiego jak ten nic się nie zmienia. Ma to znaczenie dopiero wtedy, gdy dane rozszerzeń, na przykład własne pola produktów, mają trafiać do agentów przez adapter.

#Mapowanie pól WooCommerce na schema.org

Dwa powody trzymania wyjść narzędzi w słowniku schema.org:

Agenci używają tych samych słów między źródłami. Gdy agent odpowiada “czy ten produkt jest dostępny?”, zszywa encję Product z twojego serwera MCP, Offer z availability i ewentualnie Review. Jeśli twój serwer MCP zwraca { "stock": "tak" }, a inne źródło availability: "https://schema.org/InStock", agent musi godzić dwa słowniki. Z dopasowaniem do schema.org po twojej stronie nie musi.

Dane strukturalne twojego sklepu i tak mówią po schema.org. Twoje /wp-content/themes/<theme>/single-product.php (lub headless’owy odpowiednik) emituje JSON-LD typu Product. Trzymanie wyjścia MCP w tym samym kształcie sprawia, że ta sama strona produktu serwuje te same dane crawlerowi Google’a, crawlerowi OpenAI po URL-u i agentowi wywołującemu twoje narzędzie MCP wprost.

Mapowanie typowego produktu WooCommerce wygląda tak:

Wariacje wymagają dodatkowej warstwy (tablica hasVariant typu Product), ale podstawowy kształt jest ten sam.

#Jak zapewnić idempotentność zamówień w serwerze MCP

Narzędzia odczytu (catalogue.list, product.detail, inventory.check, order.status) są naturalnie idempotentne. Trzy wywołania zwracają tę samą odpowiedź.

order.intent to pułapka. Agent może zawołać dwa razy, jeśli sieć między odpowiedzią a hostem zatrzepocze. Kontrakt, który wdrażam:

• order.intent przyjmuje opcjonalny idempotency_key (UUID dostarczany przez hosta).
• Handler trzyma klucz w Workers KV z TTL 24 godziny obok ID utworzonego szkicu zamówienia.
• Powtórne wywołanie z tym samym kluczem zwraca ten sam szkic, zamiast tworzyć nowy.

Wzorzec odpowiada idempotencji Stripe na POST /v1/charges. Jest dobrze rozumiany; agenci i ludzie korzystają jednakowo.

#Jak wdrożyć serwer MCP na Cloudflare Workers

Wersja 2 SDK TypeScript eksportuje createMcpHandler. Funkcja zwraca obiekt { fetch } w kształcie, którego Cloudflare Workers oczekuje jako domyślnego eksportu, i obsługuje transport Streamable HTTP (środowiska web-standard w dokumentacji SDK). Wejście Workera wygląda tak:

import {
  createMcpHandler,
  hostHeaderValidationResponse,
  originValidationResponse,
} from "@modelcontextprotocol/server";

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const rejected =
      hostHeaderValidationResponse(request, [env.MCP_HOSTNAME]) ??
      originValidationResponse(request, [env.SHOP_HOSTNAME]);
    if (rejected) return rejected;

    const authInfo = await verifyAgentToken(request, env);
    if (!authInfo) {
      return new Response("Unauthorized", { status: 401 });
    }

    const handler = createMcpHandler(() => createWooCommerceMcpServer(env));
    return handler.fetch(request, { authInfo });
  },
};

verifyAgentToken sprawdza scoped tokeny w Workers KV i zwraca dane tokenu, które handlery odczytują jako ctx.http.authInfo. Narzędzia tylko do odczytu przechodzą tokenem o niższych uprawnieniach; order.intent wymaga tokenu ze scope’em orders:write. Strategia auth to jeden z dwóch wzorców opisanych w przewodniku po wzorcach uwierzytelniania MCP.

wrangler.toml deklaruje URL origin’u WordPress, klucz konsumenta i sekret WooCommerce (jako sekrety Workera, nigdy w kodzie) i namespace KV dla idempotencji. Wdrożenie przez wrangler deploy. Worker pozostaje mały, bo to tylko routing JSON-RPC plus adaptery REST.

#Jak zabezpieczyć endpoint MCP przez OAuth i walidację Origin

Autoryzacja w MCP jest opcjonalna. Jeśli implementacja oparta na HTTP ją obsługuje, powinna trzymać się specyfikacji autoryzacji (autoryzacja). Serwer stdio z kolei nie powinien jej stosować i bierze poświadczenia ze środowiska. Te zasady dotyczą tego Workera.

Serwer MCP działa jako serwer zasobów OAuth 2.1 i musi publikować metadane chronionego zasobu według RFC 9728, żeby klient mógł ustalić, który serwer autoryzacji wydaje jego tokeny.

Musi sprawdzać, czy token został wydany właśnie dla niego jako odbiorcy (audience), zgodnie z RFC 8707. Nieważny albo wygasły token dostaje HTTP 401.

Nie może przyjmować ani przekazywać dalej żadnego innego tokenu. W sklepie oznacza to, że token agenta nigdy nie trafia do /wp-json/wc/v3/. Do WooCommerce idą wyłącznie klucze REST API zapisane jako sekrety Workera.

Transport dokłada jeszcze jeden obowiązek (Streamable HTTP). Serwer musi walidować nagłówek Origin przy wszystkich połączeniach, żeby zapobiec atakom DNS rebinding, i odpowiadać 403, gdy nagłówek jest obecny i nieprawidłowy. createMcpHandler sam tego nie sprawdza. Dokumentacja SDK każe postawić przed nim hostHeaderValidationResponse i originValidationResponse, i to właśnie robi Worker powyżej. Żądanie bez nagłówka Origin przechodzi tę kontrolę, więc główną barierą pozostaje token.

Przy logowaniu z następnej sekcji pomaga kolejna zmiana w transporcie. Każdy POST niesie nagłówki Mcp-Method i Mcp-Name, a przy tools/call Mcp-Name zawiera nazwę narzędzia. Proxy albo sam Worker może więc zapisać, które narzędzie wywołano, bez parsowania ciała JSON.

Aktualizacja, 24 października 2026: każda wtyczka, która wnosi MCP do WordPressa, dokłada własną powierzchnię ataku. Wordfence opublikował 15 i 16 października 2026 trzy takie wpisy: w AI Engine do wersji 3.8.3 brakowało sprawdzenia uprawnień, więc zalogowany współpracownik (contributor) mógł wykonać nieuprawnioną akcję (CVE-2026-110888); narzędzie MCP wsp_get_posts we wtyczce WSP MCP do wersji 2.9.5 pozwalało każdemu zalogowanemu subskrybentowi czytać tytuły, autorów i fragmenty szkiców oraz wpisów oczekujących i zaplanowanych (CVE-2026-109382); a xSpeed Cache do wersji 1.4.2, wtyczka cache z funkcjami MCP, dopuszczała zapisany cross-site scripting przez współpracowników (CVE-2026-109985). Żadna z trzech luk nie wymaga konta administratora. Worker z tego poradnika działa poza WordPressem i łączy się ze sklepem tylko kluczami REST API, więc rola w WordPressie nie daje dostępu do jego narzędzi. Chronią go opisane wyżej sprawdzenia tokenu i nagłówka Origin.

#Jak logować i monitorować wywołania narzędzi MCP

Każde wywołanie narzędzia loguję z:

• Nazwą narzędzia.
• Hashem SHA-256 wejścia (nie samym wejściem; ryzyko PII wg RODO art. 32).
• Opóźnieniem.
• Czy walidacja wyjścia przeszła czy nie.
• Scope’em tokenu agenta.

Logi idą przez Cloudflare Logpush do długoterminowego store’u. Dwa nawyki operacyjne, które to umożliwia:

Zaostrzanie schematów. Sześć tygodni po starcie przeglądam awarie walidacji. Każda awaria wyjścia to bug handlera lub niezmapowane pole WooCommerce. Każda awaria wejścia to albo agent z wadą, albo zbyt restrykcyjny schemat. Jedno i drugie ląduje w kolejnym wydaniu.

Atrybucja kosztów. Wywołania narzędzi to rachunkowe obciążenie origin’u WooCommerce. Log pokazuje, który token agenta generuje obciążenie i które narzędzie. Pojedynczy źle zachowujący się agent zapętlony na catalogue.list to jedno zapytanie do logu od identyfikacji.

#Inne przewodniki o MCP i WooCommerce

Ten artykuł pokazuje przebieg implementacji. Odporną na awarie architekturę synchronizacji ERP, kolejek Redis i transakcji bazodanowych opisuje mój przewodnik architektury integracji WooCommerce z ERP 2026. Głębsze ujęcie typowanych narzędzi znajdziesz w tekście o pisaniu typowanych narzędzi katalogu z Zod dla MCP. Wzorce uwierzytelniania opisują wzorce uwierzytelniania MCP: OAuth, tokeny i kiedy co. Decyzję na poziomie protokołu opisuje MCP vs REST: kiedy co wygrywa dla integracji agentów AI. Ścieżkę migracji z istniejącego API opisuje migracja istniejącego API WordPress do MCP: 4-tygodniowy playbook. Strona usługi to budowa serwera MCP, a proces redakcyjny (scope, read-only vs write) w studium przypadku workflow MCP. Szersza strategia leży w Universal Commerce Protocol.

Wycena indywidualna, bo zakres zależy od liczby potrzebnych narzędzi, złożoności rozszerzeń WooCommerce i runtime’ów agenta, które chcesz wspierać.