Migracja istniejącego API WordPress do MCP: 4-tygodniowy plan działania

#Migracja istniejącego API WordPress do MCP: 4-tygodniowy plan działania

Czysty greenfield’owy build MCP jest prosty. Migracja z istniejącego, działającego REST API WordPressa, gdy obsługuje on dalej ruch produkcyjny, to trudniejszy kształt. Ten playbook to to, czego używam, by przejść z “mamy /wp-json/ i jednego konsumenta partnera” do “mamy /wp-json/, tego partnera i przyjazny LLM-om serwer MCP z przodu”, niczego nie psując.

Artykuł osadzony jest w filarze budowa serwera MCP.

#TL;DR

• Cztery tygodnie: audyt, scaffold, parallel-run, cutover.
• REST pozostaje żywy dla istniejących konsumentów; MCP to dodatek, nie zamiennik.
• Schematy Zod biorą się z audytu REST, nie z listy życzeń.
• Parallel-run z jednym wewnętrznym agentem zanim ruch zewnętrzny dotknie MCP.
• Logpush łapie każde wywołanie narzędzia; rozbieżności pomiędzy odpowiedziami MCP a REST wychodzą jako błędy schematu.

#Jak zrobić audyt endpointów REST API WordPressa

Audyt to arkusz kalkulacyjny. Jeden wiersz na endpoint, kolumny:

Dla typowego sklepu WooCommerce arkusz ma 20 do 60 wierszy. Większość mapuje się czysto na narzędzia MCP; garstka (interna admina, endpointy specyficzne dla wtyczek, odbiorcy webhooków) zostaje tylko-REST.

Wynik tygodnia 1 to dwa artefakty:

1. Proponowane inwentarz narzędzi: catalogue.list, product.detail, order.intent, order.status, inventory.check, plus cokolwiek specyficznego dla twojego buildu.
2. Pierwszy szkic schematów Zod dla wejść i wyjść każdego narzędzia, wywiedziony z faktycznych odpowiedzi REST uchwyconych podczas audytu.

Odpowiedzi REST łapię curl-em plus jq do inspekcji kształtu albo kolekcją Postmana, którą zespół dzieli. Chodzi o empiryczną prawdę, a nie to, co mówi README. Wtyczki WordPressa są niesławne z dodawania pól, których dokumentacja nigdy nie zauważy; audyt je łapie.

#Jak postawić serwer MCP na Cloudflare Workers

Wynikiem tygodnia 2 jest działający serwer MCP, wdrożony na środowisko Cloudflare Workers nieprodukcyjne, z inwentarzem narzędzi z tygodnia 1 zaimplementowanym jako cienkie adaptery nad istniejącymi endpointami REST.

Szkielet serwera:

import { createMcpHandler, hostHeaderValidationResponse, McpServer } from "@modelcontextprotocol/server";
import { catalogueListInput, catalogueListOutput, handleCatalogueList } from "./tools/catalogue-list.js";
import { productDetailInput, productDetailOutput, handleProductDetail } from "./tools/product-detail.js";
// ... jeden import na narzędzie

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    // odrzuć żądania z obcym nagłówkiem Host (ochrona przed DNS rebinding)
    const rejected = hostHeaderValidationResponse(request, [env.MCP_HOSTNAME]);
    if (rejected) return rejected;

    const handler = createMcpHandler(() => {
      const server = new McpServer({ name: "wppoland-mcp", version: "0.1.0" });

      server.registerTool(
        "catalogue.list",
        {
          description: "List WooCommerce products with filters",
          inputSchema: catalogueListInput,
          outputSchema: catalogueListOutput,
          annotations: { readOnlyHint: true },
        },
        (input) => handleCatalogueList(input, env),
      );

      server.registerTool(
        "product.detail",
        {
          description: "Return one product by SKU",
          inputSchema: productDetailInput,
          outputSchema: productDetailOutput,
          annotations: { readOnlyHint: true },
        },
        (input) => handleProductDetail(input, env),
      );

      // ... jedno wywołanie registerTool() na narzędzie

      return server;
    });

    return handler.fetch(request);
  },
};

Szkielet korzysta z wersji 2 oficjalnego SDK TypeScript (@modelcontextprotocol/server), która implementuje rewizję specyfikacji 2026-07-28. createMcpHandler zwraca obiekt z metodą fetch, czyli dokładnie taki kształt, jakiego moduł Cloudflare Workers oczekuje jako eksportu domyślnego, a fabryka tworzy nowy McpServer przy każdym żądaniu (przewodnik SDK po środowiskach web-standard). Ten sam przewodnik zaznacza, że handler sam nie sprawdza nagłówków Host ani Origin, dlatego strażnik stoi przed nim. Projekty na @modelcontextprotocol/sdk 1.x dostają poprawki błędów i bezpieczeństwa jeszcze przez co najmniej sześć miesięcy od wydania v2 z 27 lipca 2026 (README SDK), więc migracja zaczynana dziś powinna celować w v2.

Każdy handler to cienki adapter. Bierze zwalidowane wejście, buduje query string, fetchuje z /wp-json/, mapuje odpowiedź na kształt wyjścia zgodny ze schema.org, woła parse na wyjściu, zwraca. Logika biznesowa zostaje w WordPressie; handler to mechaniczne tłumaczenie.

Tydzień 2 obejmuje też scaffolding auth z przewodnika po wzorcach uwierzytelniania MCP. Na parallel-run w tygodniu 3 używam jednego testowego tokena ze wszystkimi scope’ami; produkcyjne scope’y zaostrzam w tygodniu 4.

wrangler.toml środowiska preview wskazuje na staging’ową instalację WordPressa lub kopię produkcji. Serwer MCP osiągalny jest pod URL-em *.mcp-staging.wppoland.workers.dev dostępnym tylko zespołowi.

#Jak testować serwer MCP równolegle z REST API

W tygodniu 3 wychodzą bugi. Wzorzec:

Zbuduj harness porównawczy. Mały skrypt TypeScript przyjmujący nazwę narzędzia i wejście, wołający serwer MCP, potem wołający równoważny endpoint REST wprost i diff’ujący dwie odpowiedzi. Diff jest logowany razem z nazwą narzędzia, wejściem i ścieżką w stylu JSON pointer do każdej rozbieżności.

async function compareToolToRest(toolName: string, input: unknown) {
  const mcpResponse = await callMcp(toolName, input);
  const restResponse = await callEquivalentRest(toolName, input);
  const diff = jsonDiff(restResponse, mcpResponse);
  if (diff.length > 0) {
    await logMismatch({ toolName, input, diff });
  }
}

Każde narzędzie przeciw reprezentatywnemu zestawowi wejść. Dla catalogue.list: pusta query, query zwracające setki produktów, query z filtrem kategorii, query z zakresem cenowym, query bez wyników. Dla product.detail: znana SKU, nieznana SKU, SKU z wariantami, SKU z polami custom. Pokrywaj edge case’y z audytu.

Wskaż jednego wewnętrznego agenta na serwer MCP. Claude Desktop z serwerem MCP skonfigurowanym jako zdalne źródło narzędzi to konfiguracja, której używam. Ktoś z zespołu spędza 30 minut dziennie przez tydzień, interagując z własnym sklepem przez agenta i zapisując zaskoczenia w wspólnym dokumencie.

Te same polecenia testowe na trzech klientach. Luca Rossi w eseju How to design a good MCP server z października 2026, napisanym razem z zespołem Manufact, zwraca uwagę, że ten sam serwer potrafi dawać zupełnie inne wyniki w ChatGPT, w Claude i w długim ogonie innych klientów. Dlatego krótki stały zestaw poleceń testowych (tzw. golden prompts) na kilku prawdziwych klientach powinien należeć do zwykłych testów produktu. Lista kontrolna z eseju dodaje jedną osobę odpowiedzialną za stan serwera MCP, która sprawdza go ponownie po każdym dużym wydaniu MCP, Claude albo ChatGPT. W tym planie oznacza to, że sesje z agentem w 3. tygodniu przechodzisz w Claude Desktop i w dwóch innych klientach, których faktycznie używają twoi odbiorcy, a skrypt porównawczy uruchamiasz po każdej rewizji protokołu, tak samo jak po aktualizacji WordPressa.

Zaostrzaj schematy na podstawie tego, co wraca. Każda awaria walidacji Zod w logu to bug schematu lub bug mapowania. Popraw, redeployuj Workera preview, ponów harness.

Wynikiem tygodnia 3 jest harness przechodzący z zerowymi diffami i inwentarz narzędzi, który przeżył pięć dni po 30 minut realnej interakcji z agentem dziennie. Jeśli któregoś brakuje, tydzień 4 nie startuje.

#Jak wdrożyć serwer MCP na produkcję i go monitorować

Cutover jest niedramatyczny, jeśli tygodnie 1-3 poszły dobrze.

Wdroż produkcyjne Workers. wrangler deploy --env production. Produkcyjny serwer MCP wskazuje na produkcyjny origin WordPressa, z produkcyjnymi scope’ami na tokenach wydawanych przez admin WordPressa.

Wydaj tokeny pierwszemu realnemu runtime’owi agenta. Zwykle jeden z: wewnętrzny agent dla pracowników, integracja partnera prosząca o powierzchnię MCP, publiczny asystent na sklepie. Zacznij od najmniejszego, najmniej ryzykownego konsumenta.

Spnij Cloudflare Logpush z długoterminowym store’em. Pola logu opisane w artykule budowa serwera MCP dla WooCommerce to właściwe defaulty: nazwa narzędzia, hash wejścia, opóźnienie, wynik walidacji, scope tokena. Store to to, czego twój zespół już używa (BigQuery, ClickHouse, S3 + Athena).

Zbuduj dashboard obserwacji. Trzy zapytania na dzień jeden:

1. Wywołania narzędzi na minutę, w rozbiciu po nazwie narzędzia. Wykrywa burstowe obciążenie.
2. Stopa awarii walidacji per narzędzie, rozbicie po kodzie (input_invalid, output_invalid). Wykrywa regresje.
3. Opóźnienie p50/p95/p99 per narzędzie. Wykrywa wolny WordPress wyżej w łańcuchu.

Trzymaj REST przy życiu, nietknięty. Istniejący sklep, istniejące integracje partnerów, istniejący odbiorcy webhooków używają dalej /wp-json/ dokładnie jak wcześniej. MCP to dodatek, nie zamiennik. Najważniejsza reguła migracji.

#Najczęstsze błędy przy migracji REST API do MCP

Sześć rzeczy, które widziałem padające na realnych migracjach:

Pole odpowiedzi REST, którego audyt nie złapał. Wtyczka dodaje meta_data: [...] do odpowiedzi produktów. Schemat wyjścia MCP go nie zna. Parse Zod pada na realnych danych. Naprawa: powtórz audyt na ruchu produkcyjnym, rozszerz schemat lub wprost odrzuć pole .transform().

Niezgodność permalinków staging-produkcja. Narzędzie MCP product.detail zwraca pole WooCommerce permalink. Permalinki staging to https://staging.example.com/...; produkcyjne https://example.com/.... Dane testowe przechodzą; produkcja pada na walidatorze URL. Naprawa: skonfiguruj Workera staging z krokiem przepisywania permalinków lustrzanego do zachowania produkcji.

Obsługa wariantów WooCommerce. Audyt uchwycił kształt odpowiedzi prostego produktu. Odpowiedzi wariantów są inne (SKU wariantów żyją pod /wp-json/wc/v3/products/<id>/variations). Naprawa: traktuj warianty jako osobne fetch w product.detail, mapuj na schema.org hasVariant.

Token auth wycieka do logów. Handler loguje pełen nagłówek Authorization do debug’u. Token ląduje w store’ze logów. Naprawa: redaguj nagłówek w warstwie logu; zrotuj każdy token wydany przed wdrożeniem redakcji. W polskim kontekście istotne dla zgodności z RODO art. 32.

Aktualizacja wtyczki psuje odpowiedź REST. WooCommerce 9.x przemianuje pole, handler MCP wciąż oczekuje starej nazwy, parse Zod pada. Naprawa: pinuj wersję WooCommerce w stagingu, uruchamiaj harness porównawczy przy każdym upgrade’u WordPressa, traktuj harness jako część bramy upgrade’u.

Agent zapętla się na zniekształconym wywołaniu narzędzia. Wadliwy agent retry’uje order.intent 100 razy na minutę, gdy wejście pada walidację. Bez rate limita origin WordPress widzi 100 wywołań fan-out. Naprawa: rate limit per principal jak w przewodniku po wzorcach uwierzytelniania MCP, plus zwracaj retry_after_seconds w envelope błędu.

#Ile trwa migracja API WordPressa do MCP

Cztery tygodnie to default. Dwie korekty:

Mniejsza powierzchnia, dwa tygodnie. Trzy narzędzia, jeden konsument, brak złożoności auth. Skompresuj audyt i scaffold do tygodnia 1, parallel-run i cutover do tygodnia 2. Ten sam wzorzec, krótszy kalendarz.

Większa powierzchnia, sześć tygodni. Tuzin narzędzi, kilka trybów auth, wrażliwe akcje mutujące. Dodaj tydzień pomiędzy scaffold a parallel-run na security review. Dodaj tydzień pomiędzy parallel-run a cutover na soft launch z jednym użytkownikiem zautoryzowanym OAuth, zanim szerszy rollout.

Cztery fazy zostają w tej samej kolejności niezależnie od budżetu czasowego.

#Czy WordPress zmienia się po wdrożeniu MCP

Warto powiedzieć wprost. Po migracji:

• UI admina WordPressa jest niezmieniona.
• Block Editor jest niezmieniony.
• System uwierzytelniania użytkowników jest niezmieniony.
• Istniejące endpointy REST są niezmienione i obsługują dalej swoich konsumentów.
• Logika wywoływania webhooków jest niezmieniona.
• Warstwa danych (wp_posts, wp_postmeta, tabele WooCommerce) jest niezmieniona.

Co dochodzi: serwer MCP na Cloudflare Workers, UI wydawania tokenów po stronie admina WordPressa (mała wtyczka lub funkcja motywu), konfiguracja Cloudflare Logpush. Wszystko inne jest niezmienione.

To właśnie czyni migrację niskoryzykową. Jeśli serwer MCP ma zły dzień, wyłączasz Workera. Powierzchnia agenta gaśnie. Sklep dalej działa, integracje partnerów dalej działają, zamówienia dalej spływają.

#Jak zmapować czasowniki REST na adnotacje narzędzi MCP

Arkusz audytu ma już kolumnę o mutowaniu stanu. W MCP ta kolumna zamienia się w adnotacje narzędzia. Schemat specyfikacji 2026-07-28 definiuje w ToolAnnotations cztery logiczne podpowiedzi: readOnlyHint (domyślnie false), destructiveHint (domyślnie true), idempotentHint (domyślnie false) i openWorldHint (domyślnie true). Podpowiedzi o destrukcyjności i idempotentności mają znaczenie tylko wtedy, gdy readOnlyHint ma wartość false (schemat MCP).

Mapowanie wynikające wprost z kolumn audytu:

Właśnie wartości domyślne są powodem, żeby adnotacje ustawiać. Narzędzie zarejestrowane bez nich klient traktuje jako potencjalnie destrukcyjne i nieidempotentne, więc katalog tylko do odczytu bez readOnlyHint wygląda dla klienta groźniej, niż jest. Przewodnik SDK opisuje praktyczny skutek: host może automatycznie zatwierdzać narzędzie tylko do odczytu i prosić o potwierdzenie przed destrukcyjnym (przewodnik SDK o narzędziach). Specyfikacja dodaje, że klient ma traktować adnotacje jako niezaufane, jeśli serwer nie jest zaufany, więc adnotacje nigdy nie zastępują sprawdzenia uprawnień po stronie WordPressa.

Zasady nazewnictwa pochodzą z tej samej strony specyfikacji: nazwa narzędzia powinna mieć od 1 do 128 znaków, rozróżniać wielkość liter i składać się tylko z liter ASCII, cyfr, podkreślnika, łącznika i kropki (narzędzia MCP). catalogue.list i product.detail mieszczą się w tej regule; nazwa skopiowana z trasy REST razem z ukośnikami już nie.

#Jak zwracać agentowi błędy z REST API WordPressa

Błąd REST API WordPressa przychodzi jako JSON z polami code, message i data.status. Specyfikacja MCP rozdziela dwa rodzaje porażek. Błędy protokołu (nieznane narzędzie, źle zbudowane żądanie, błąd serwera) wracają jako standardowe błędy JSON-RPC. Błędy wykonania narzędzia (awaria API, błąd walidacji wejścia, błąd logiki biznesowej) wracają w wyniku narzędzia z isError: true, a klient powinien przekazać je modelowi, żeby ten mógł poprawić wywołanie i spróbować ponownie (narzędzia MCP, obsługa błędów).

Dla handlera opartego na REST oznacza to, że 404 dla nieznanego ID produktu albo 400 dla złego parametru to błąd wykonania narzędzia. Zwróć isError: true z blokiem tekstu, który mówi modelowi, co zmienić, na przykład że żaden produkt nie ma takiego SKU, a poprawne SKU zwraca catalogue.list. Błędem JSON-RPC staje się tylko awaria samej warstwy MCP. Zamiana każdego 4xx z WordPressa na błąd JSON-RPC ukrywa przed modelem przyczynę i agent ponawia na ślepo, czyli wpada w pętlę opisaną wyżej na liście błędów.

Ta sama strona ustala dwie reguły dla udanych wyników. Gdy narzędzie deklaruje outputSchema, serwer musi zwracać ustrukturyzowane wyniki zgodne z tym schematem. Narzędzie zwracające structuredContent powinno dodatkowo zwrócić zserializowany JSON w bloku tekstu, dla zgodności wstecznej. SDK TypeScript w wersji 2 waliduje structuredContent względem outputSchema, zanim wynik opuści serwer (przewodnik SDK o narzędziach), czyli robi to samo sprawdzenie, na którym opiera się harness z tygodnia 3.

#Jakie poświadczenie serwer MCP wysyła do WordPressa

W tej architekturze spotykają się dwa poświadczenia, a specyfikacja trzyma je osobno. Autoryzacja w MCP jest opcjonalna. Gdy serwer na transporcie HTTP ją obsługuje, działa jako serwer zasobów OAuth 2.1: musi sprawdzić, czy token dostępu został wydany właśnie dla niego jako odbiorcy (RFC 8707), musi odpowiadać HTTP 401 na nieważne lub wygasłe tokeny i nie wolno mu przyjmować ani przekazywać dalej żadnych innych tokenów (autoryzacja MCP). Serwery na transporcie stdio powinny ten przepływ pominąć i brać poświadczenia ze środowiska.

Dla Workera stojącego przed /wp-json/ wyklucza to przekazywanie tokena agenta do WordPressa. Token agenta kończy drogę na Workerze. Worker woła WordPressa własnym poświadczeniem, zwykle hasłem aplikacji (Application Password) osobnego użytkownika WordPressa, który ma tylko uprawnienia potrzebne inwentarzowi narzędzi. Hasła aplikacji są w WordPressie od wersji 5.6 i wysyła się je przez HTTP Basic po HTTPS (podręcznik REST API, uwierzytelnianie). Trzymaj to hasło jako sekret Workera ustawiony przez wrangler secret put, a nie jako zwykłą zmienną w wrangler.toml (sekrety w Cloudflare Workers).

Ten podział ma praktyczną zaletę w tygodniu 4. Rotacja poświadczenia WordPressa nie dotyka tokenów agentów, a unieważnienie tokena agenta nie dotyka strony WordPressa. O tym, jakie uprawnienia dostaje osobny użytkownik, decyduje kolumna wrażliwości danych z audytu: inwentarz ograniczony do katalogu nie potrzebuje żadnych uprawnień do zamówień.

#Kiedy lepszą drogą jest WordPress MCP Adapter

Ten plan stawia MCP na brzegu sieci, w Workerze. WordPress ma też oficjalną drogę, która umieszcza MCP wewnątrz WordPressa. MCP Adapter, część inicjatywy AI Building Blocks for WordPress, wystawia jako narzędzia, zasoby i prompty MCP zdolności (abilities) zarejestrowane przez WordPress Abilities API. Na wordpress.org wtyczka ma wersję 0.7.1, wymaga WordPressa 6.9 i PHP 7.4, a ostatnio była aktualizowana 16 października 2026 (strona wtyczki).

Co dokumentacja adaptera mówi o rzeczach, które wpływają na wybór:

• Zdolności są domyślnie prywatne. Do MCP trafia tylko ta, która ma meta.public (albo meta.mcp.public) ustawione na true. W WordPressie 6.9 i 7.0 ta flaga steruje tylko MCP, a dostęp przez REST nadal wymaga meta.show_in_rest; rdzeń stosuje meta.public do REST od wersji 7.1.
• Domyślny serwer wystawia trzy metanarzędzia (mcp-adapter/discover-abilities, mcp-adapter/get-ability-info, mcp-adapter/execute-ability) i odpowiada po HTTP pod /wp-json/mcp/mcp-adapter-default-server.
• wp mcp-adapter serve --user=<id> serwuje serwer przez stdio za pomocą WP-CLI.
• Bez własnego callbacku uprawnień transportu serwer wpuszcza zalogowanych użytkowników (is_user_logged_in()).
• Adnotacje zapisane w formacie Abilities API (readonly, destructive, idempotent) są zamieniane na readOnlyHint, destructiveHint i idempotentHint.

Adapter pasuje, gdy narzędzia to logika WordPressa, która już żyje w PHP, a klienci agentowi mogą łączyć się bezpośrednio z witryną. Droga przez Workera pasuje, gdy powierzchnia MCP potrzebuje własnego wydawania tokenów, limitów na brzegu i Logpush albo ma odpowiadać także wtedy, gdy origin WordPressa zwalnia. Audyt z tygodnia 1 służy obu drogom: każdy wiersz mapowany na narzędzie staje się albo handlerem w Workerze, albo zarejestrowaną zdolnością.

Aktualizacja, 24 października 2026: w październikowym benchmarku Building with WordPress Andy’ego Peatlinga Opus 5.5 w Claude Code i GPT-6.1-Sol w Codex nie wykonały żadnego z 42 zadań właścicieli stron, gdy adapter był jedynym wejściem, a z hasłem aplikacji do REST API wykonały 33 z 42. Trzy zdolności samego WordPressa tylko odczytują informacje o stronie, użytkowniku i serwerze, a jedyne zapisy przyszły ze zdolności produktowych WooCommerce. W zgłoszeniu #402 Peatling planuje eksperymentalne zdolności rdzenia w czterech etapach, które mają tę lukę zamknąć. 21 października zespół AI WordPressa odnotował zgodę na to, by MCP stało się częścią domyślnego WordPressa, z wersją 7.3 jako możliwym celem i bez zobowiązania co do wydania (podsumowanie tygodnia). Dopóki zdolności zapisu nie ma, droga przez adapter oznacza pisanie ich samemu, a endpointy REST z audytu w pierwszym tygodniu działają już dziś.

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. Rejestrowanie zdolności wewnątrz WordPressa przenosi to samo pytanie na twój kod: każda zdolność potrzebuje callbacku uprawnień, który sprawdza konkretne uprawnienie (capability), a nie tylko to, czy użytkownik jest zalogowany.

#Na jaką wersję specyfikacji MCP celować

Aktualna rewizja specyfikacji to 2026-07-28 i dwie jej reguły dotyczą tego planu. Po pierwsze, MCP nie ma sesji na poziomie protokołu, więc serwer nie może opierać się na stanie połączenia, żeby powiązać jedno wywołanie narzędzia z kolejnym. Dla stanu w rodzaju koszyka specyfikacja zaleca zwracanie jawnego uchwytu z narzędzia tworzącego, przyjmowanie tego uchwytu w kolejnych wywołaniach, sprawdzanie uprawnień wywołującego względem uchwytu przy każdym wywołaniu i podanie czasu życia uchwytu w opisie narzędzia (narzędzia MCP, narzędzia ze stanem). Dla order.intent takim uchwytem jest ID intencji.

Po drugie, każde żądanie niesie wersję protokołu i możliwości klienta w polach _meta w treści wiadomości, a transport Streamable HTTP powiela je w nagłówkach HTTP, żeby pośrednicy mogli kierować ruch bez parsowania treści (transporty MCP). Po stronie adaptera wp mcp-adapter list --protocol=2026-07-28 liczy komponenty dostępne w tej rewizji; adapter przyjmuje tam 2025-11-25 i 2026-07-28.

#Powiązane tematy

Ten artykuł omawia kształt migracji. Przebieg implementacji opisuje budowa serwera MCP dla WooCommerce. Strategię uwierzytelniania pokazują wzorce uwierzytelniania MCP. Projekt typowanych narzędzi opisuje pisanie typowanych narzędzi katalogu z Zod dla MCP. Decyzję na poziomie protokołu opisuje MCP vs REST. Strona usługi to budowa serwera MCP.

Wycena indywidualna, bo zakres migracji zależy od liczby endpointów w audycie, złożoności auth i liczby konsumentów.

Po stronie wdrożenia ten temat trzymam pod migrację na Next.js lub Astro.