WordPress MCP Adapter: как подключать AI-агентов к возможностям сайта

7 октября 2026 года WordPress Core AI Team объявила о публикации MCP Adapter 0.7.0 в официальном WordPress Plugin Directory. Это важнее обычного обновления отдельного AI-плагина: проект получил статус canonical plugin и фактически стал общей поддерживаемой командой WordPress точкой для построения MCP-интеграций поверх Abilities API. При этом называть MCP Adapter частью WordPress Core или стабильным API уровня 1.0 пока нельзя — команда прямо обозначает проект как experimental.

Смысл архитектуры не в том, что «AI теперь может управлять WordPress». MCP Adapter решает более узкую и технически правильную задачу: WordPress описывает доступные операции через Abilities API, а адаптер переводит намеренно открытые возможности в формат, понятный MCP-клиенту.

Это принципиальная разница. Модель или агент не получает произвольный доступ к PHP, базе данных, wp-admin или функциям плагинов. Разработчик сначала определяет конкретную Ability с известной схемой входных и выходных данных, callback выполнения и проверкой разрешений, а уже затем решает, должна ли эта возможность появиться в MCP. Abilities API присутствует в WordPress начиная с версии 6.9 и задуман как центральный реестр самодокументируемых возможностей сайта.

Именно поэтому MCP Adapter интересен не только разработчикам «AI-функций». Он формирует более строгий контракт между WordPress и внешними автоматизированными системами: системе не нужно знать внутреннее устройство десятка плагинов, если нужные действия представлены как ограниченные Abilities.

От WordPress Ability до действия AI-агента

Базовая цепочка выглядит так: функциональность сайта регистрируется как Ability → Ability при необходимости открывается для MCP → MCP Adapter представляет её через сервер → совместимый клиент обнаруживает доступную возможность → пользователь проходит серверный уровень доступа → перед выполнением WordPress проверяет права именно этой Ability → только после этого вызывается execute_callback.

У default server endpoint сейчас фиксированный:

/wp-json/mcp/mcp-adapter-default-server

Сам default server предоставляет три метаинструмента для работы с Abilities: обнаружение доступных способностей, получение полной информации о конкретной Ability и её выполнение. Поэтому default server использует layered discovery: вместо огромного прямого списка всех действий агент сначала видит универсальный механизм обнаружения, а затем запрашивает нужную ему возможность.

Здесь особенно важно разделять четыре понятия, которые в обсуждении AI-агентов часто ошибочно смешивают.

Discoverability отвечает только на вопрос, может ли MCP-клиент узнать о существовании возможности. Для default server WordPress abilities не открываются автоматически: используется opt-in через meta.public=true или более точное meta.mcp.public=true. Явное meta.mcp.public=false, наоборот, исключает Ability из MCP.

Authentication определяет, кто вообще обращается к MCP server. Для default server документация указывает аутентифицированного WordPress-пользователя с capability read; для custom server можно задать собственный transport permission callback.

Authorization решает, имеет ли этот пользователь право вызвать конкретную Ability. Это задача её permission_callback. Например, возможность прочитать публичный диагностический статус и возможность изменить настройки сайта не должны иметь одинаковую проверку capability.

Execution происходит только после прохождения предыдущих границ. Callback получает уже конкретные входные параметры и должен самостоятельно относиться к ним как к недоверенным данным: корректно описывать input_schema, ограничивать допустимые значения и выполнять прикладную валидацию там, где одной структурной схемы недостаточно.

Так MCP становится не новым способом обхода WordPress permissions, а дополнительным транспортом к заранее оформленным возможностям.

Default server и custom server решают разные задачи

Для большинства экспериментов логично начать с default server. Он создаётся автоматически и позволяет публично exposed Abilities находить через три встроенных метаинструмента. Это удобно, когда сайт постепенно наращивает каталог возможностей и клиенту нужен единый механизм discovery.

Custom server используется иначе. Через хук mcp_adapter_init разработчик может создать отдельный сервер и явно определить, какие tools, resources и prompts относятся именно к нему. В этом случае отдельные abilities могут регистрироваться как самостоятельные MCP tools с собственными схемами, видимыми непосредственно через MCP-механизм списка инструментов.

Custom server особенно уместен там, где нужно физически уменьшить интеграционную поверхность. Например, отдельный сервер для SEO-аудита может содержать только чтение диагностических показателей и запуск пересчёта отчёта, не показывая агенту инструменты редакции контента, управления пользователями или системными настройками.

Это уже близко к идее agent-friendly website: сайт не просто имеет API, а описывает ограниченный набор хорошо формализованных действий, которые внешняя автоматизация способна обнаружить, понять по схеме и выполнить с предсказуемыми правами.

Для разработчика здесь полезен тот же подход, что и при выборе задач WordPress-разработчика, которые нейросети реально ускоряют: автоматизировать лучше не всё подряд, а узкие операции с понятным входом, результатом и границей ответственности.

Практический сценарий: SEO-аудит без административного доступа ко всему сайту

Представим плагин внутреннего SEO-аудита. В нём есть две Abilities.

Первая — seo-audit/get-status. Она ничего не меняет и возвращает состояние последнего аудита: когда он был выполнен, завершён ли расчёт, сколько URL обработано и существует ли актуальный отчёт. Это read-only операция.

Вторая — seo-audit/rebuild-report. Она ставит новый пересчёт отчёта в очередь или запускает предусмотренный плагином процесс. Это уже state-changing операция: после вызова состояние системы меняется, могут появиться новая задача и новая версия отчёта.

Обе возможности можно сделать discoverable через MCP, но из этого не следует, что они должны иметь одинаковые разрешения.

Для get-status permission_callback может проверять capability, которой обладают сотрудники, имеющие право просматривать SEO-отчёты. Для rebuild-report имеет смысл требовать более узкое право — например, capability администратора конкретного SEO-модуля, а не просто факт авторизации пользователя.

Получается следующий сценарий.

Агент подключается к MCP server и обнаруживает доступные инструменты. Само обнаружение сообщает ему, что существует возможность получить состояние аудита и, если это намеренно разрешено, запросить пересборку.

Затем пользователь просит: «Проверь, актуален ли SEO-аудит». Клиент вызывает read-only Ability. Серверная граница подтверждает аутентифицированного пользователя, а permission_callback Ability решает, может ли именно этот пользователь читать состояние аудита. Если да — выполняется callback и агент получает структурированный результат.

Следующая команда пользователя: «Если отчёт старше недели, пересобери его». Теперь вызывается другая Ability. И здесь проверка выполняется заново. То, что пользователь имел право читать статус, не должно автоматически давать ему право запускать пересчёт.

Входные параметры state-changing Ability должны быть ограничены схемой. Если разрешены, например, только режимы full и incremental, произвольное строковое значение не должно превращаться во внутренний параметр процесса. Abilities API предусматривает input/output definitions через JSON Schema, а MCP Adapter 0.7.0 дополнительно ужесточил wire validation: данные протокола проектируются на поддерживаемую ревизию схемы, а поля, которые невозможно корректно представить, больше не должны молча «чиниться».

После state-changing вызова я бы отдельно записывал прикладное событие: WordPress user ID, имя Ability, нормализованные параметры, время, идентификатор созданного задания и итоговый статус. У MCP Adapter есть настраиваемая observability-инфраструктура с событиями запросов и собственными handlers, однако техническую observability не стоит автоматически считать полноценным бизнес-аудитом действий. Для критичных операций audit trail лучше проектировать явно.

MCP не отменяет модель безопасности WordPress

Главная опасность MCP-интеграции возникает не из-за самого протокола, а из-за слишком широкой Ability.

Если разработчик создаёт условный site/run-action, принимает произвольное имя действия и внутри позволяет выполнять десятки административных операций, то формально MCP поверхность будет маленькой — всего один tool. Реальная поверхность риска при этом огромна.

Правильнее делать наоборот: отдельные узкие abilities с небольшими JSON Schema, понятным описанием результата и собственной проверкой capability.

Документация MCP Adapter прямо описывает два уровня permission checking: transport permission ограничивает доступ ко всему серверу, а permission callback отдельной Ability определяет доступ к конкретному действию. Для custom server transport callback можно заменить своим правилом, например разрешить подключение только определённой роли или capability.

Для state-changing Ability этого недостаточно без дополнительной дисциплины:

• permission проверяется непосредственно перед действием, а не только во время discovery;
• входная схема максимально узкая и не принимает лишние поля «на будущее»;
• callback повторно проверяет контекстные ограничения, например право изменять конкретный объект;
• destructive и недеструктивные операции не объединяются в универсальную функцию;
• чувствительные данные не возвращаются только потому, что они доступны PHP-коду сайта;
• результат изменения должен быть проверяемым: ID задачи, статус, версия объекта или другое подтверждение фактического действия;
• существенные изменения записываются в пригодный для расследования audit trail.

То есть least privilege здесь применяется сразу к серверу, пользователю, Ability и данным.

Что изменилось с MCP 2026-07-28

Версия MCP Adapter 0.7.0 важна ещё и потому, что поддерживает ревизию протокола 2026-07-28.

Главное архитектурное изменение самой спецификации — stateless core. Новый MCP больше не требует прежней обязательной пары initialize / initialized и протокольной session ID для каждой связи. Каждый запрос может нести необходимые метаданные самостоятельно, а для предварительного получения возможностей появился server/discover. Это позволяет серверному MCP-слою лучше соответствовать обычной масштабируемой HTTP-инфраструктуре.

В HTTP также появились заголовки вроде Mcp-Method и Mcp-Name, благодаря которым gateway или другая инфраструктура может понимать тип запроса без разбора всего JSON body. Спецификация одновременно усилила требования вокруг authorization и ввела более формальную модель эволюции протокола.

Но «поддерживает новый MCP» не означает «работает только с клиентами последней версии».

MCP Adapter 0.7.0 обслуживает точные схемы 2026-07-28 и 2025-11-25. По release notes, клиенты, предлагающие 2025-06-18 либо 2024-11-05, также могут подключиться — им выдаётся представление через схему 2025-11-25.

Это полезная совместимость, но не повод пропускать тест после обновления. В 0.7.0 есть breaking changes для кода, расширяющего Adapter: удалены прежние generated DTO и отдельные validator classes, изменён контракт custom transports, а использование MCP Adapter как встраиваемой Composer-библиотеки объявлено deprecated в пользу установки самого плагина.

Поэтому production-проверка должна охватывать не только ответ endpoint, но и реальный набор клиентов, которым предстоит работать с сервером.

Почему MCP Adapter пока не WordPress Core

У canonical plugin есть важный статус: это не случайный сторонний эксперимент и не библиотека, которую каждый разработчик должен копировать в свой продукт. WordPress Core AI Team рассматривает Adapter как общую архитектурную основу и теперь распространяет её через Plugin Directory.

Но canonical plugin всё равно остаётся плагином.

В официальном анонсе команда объясняет это несовпадением жизненных циклов. WordPress Core распространяется в огромном масштабе, имеет собственный график релизов и сильные требования к обратной совместимости. MCP развивается заметно быстрее: буквально менее чем за три месяца до анонса Adapter вышла крупная breaking-ревизия протокола 2026-07-28. Перенос такой интеграции непосредственно в Core сейчас замедлил бы возможность синхронизироваться с MCP или, наоборот, заставил бы Core слишком быстро менять публичные контракты.

Canonical plugin становится промежуточной моделью: общий официальный пакет можно устанавливать как dependency, обновлять независимо от WordPress Core и одновременно тестировать архитектуру до стабильной версии.

Именно поэтому номер 0.7.0 здесь имеет значение. Это серьёзный milestone, но ещё не обещание API stability уровня 1.0.

Что должно быть проверено перед production

Я бы не считал MCP-интеграцию готовой только потому, что MCP-клиент увидел список tools.

Первый критерий — endpoint /wp-json/mcp/mcp-adapter-default-server либо endpoint выбранного custom server отвечает ожидаемым образом только в предусмотренном контексте. Сам факт существования REST-маршрута не должен означать возможность выполнить privileged action.

Второй — через default discovery видны только намеренно exposed abilities. Если Ability не предназначена для AI-интеграции, она должна остаться private. Для MCP-only exposure можно использовать отдельный meta.mcp.public=true, не расширяя публичность возможности без необходимости.

Третий — неавторизованный пользователь не выполняет привилегированную операцию. Проверять следует минимум два уровня: transport permission и permission_callback конкретной Ability.

Четвёртый — схема действительно ограничивает входные данные. Неверный тип, неизвестное значение enum, отсутствующее обязательное поле или структурно неправильный запрос должны завершаться контролируемой ошибкой, а не догадкой callback о намерении агента.

Пятый — любое действие, изменяющее состояние, оставляет проверяемый след. Для отчёта это может быть ID нового задания и запись audit log; для публикации — ID записи и предыдущий/новый статус; для настройки — название изменённого параметра без хранения секретного значения.

Шестой — после обновления MCP Adapter повторяется compatibility test всех используемых клиентов и custom integrations. Особенно это важно при переходе через релизы с изменением поддерживаемых schema revisions или transport contract.

И только седьмой критерий касается самого агента: он должен корректно выбирать нужную Ability и интерпретировать её результат. Агент находится в конце цепочки, а не является основным security boundary.

Что MCP Adapter меняет для WordPress-разработки

Самая интересная часть MCP Adapter — не возможность однажды написать «AI, обнови сайт». Для этого существовали REST API, WP-CLI и собственные интеграции задолго до MCP.

Изменение в другом: WordPress получает стандартизированный слой описания того, что конкретно умеет этот сайт, какие данные принимает каждая операция, что возвращает, кому разрешено её запускать и каким внешним клиентам её вообще следует показывать.

Abilities API создаёт контракт внутри WordPress. MCP Adapter переносит выбранную часть этого контракта во внешний агентный протокол.

Из этого может получиться гораздо более здоровая архитектура, чем прямое подключение AI к административному API с широкими правами. У агента появляется не универсальный «доступ к WordPress», а небольшой каталог специально подготовленных возможностей: прочитать состояние, получить диагностические данные, поставить безопасную задачу, запросить согласованное действие.

Но именно разработчик определяет ширину этого каталога и границы каждой операции.

На 8 октября 2026 года MCP Adapter уже достаточно оформлен, чтобы строить и проверять такие интеграции: есть canonical plugin, default server, custom servers, Abilities API, HTTP и STDIO transports, permission layers, schema validation и поддержка актуального MCP 2026-07-28. Одновременно проект ещё experimental и продолжает двигаться к stable v1.0.

Поэтому разумная production-стратегия сейчас — не отдавать агенту максимум возможностей, а сделать один небольшой и хорошо контролируемый вертикальный сценарий: Ability → exposure → authentication → authorization → validation → execution → audit. Если эта цепочка предсказуема для read-only операции, можно добавлять первую изменяющую состояние Ability. Если нет — проблема находится в архитектуре интеграции, а не в качестве промпта для AI.