Многие плагины обещают «нейросеть в WordPress»: чат в админке, кнопка «сгенерировать пост», магический виджет. Это удобно для разовой правки. Но это не то же самое, что дать AI-агенту управляемый доступ к действиям сайта: создать черновик, прочитать статус, не трогая настройки и плагины.
Официальный путь в 2026 выглядит так: сайт описывает свои действия через Abilities API, а пакет MCP Adapter превращает эти действия в tools для агента в Cursor или Claude. Агент не «угадывает» REST-эндпоинты и не хранит пароль админа в промпте — он вызывает только то, что вы явно разрешили.
Зачем WordPress нужен MCP, а не «ещё один плагин с кнопкой ИИ»
MCP простыми словами: клиент, сервер и tools
Без MCP каждый сервис подключают «своим» способом. С MCP один и тот же клиент может говорить и с WordPress, и с другими MCP-серверами. Важно не путать семейства: MCP-сервер Brand Analytics открывает доступ к данным мониторинга СМИ — это не управление вашим WordPress. Community-плагины вроде «Easy MCP» тоже могут быть другим стеком. В этом гайде — только официальный пакет wordpress/mcp-adapter.
Старый репозиторий Automattic/wordpress-mcp помечен как устаревший: разработка ушла в официальный adapter. Если ставите связку с нуля — берите канон из WordPress.org / GitHub WordPress/mcp-adapter, а не устаревший плагин.
Чем Abilities API отличается от «просто REST»
WordPress REST API давно умеет создавать посты по HTTP. Но агенту неудобно и опасно «бродить» по всему API: слишком много эндпоинтов, легко ошибиться с правами, сложно объяснить модели «что можно».
С WordPress 6.9 Abilities API уже в ядре. MCP Adapter — отдельный пакет-мост: он отдаёт abilities наружу как MCP tools / resources / prompts. Минимум для адаптера: WordPress 6.9+, PHP 7.4+. Адаптер намеренно остаётся отдельным пакетом — это не баг и не «ждём 7.0».
Что поставить до первого запроса агента
Цель на старте — не «агент сам публикует», а безопасный контур: сайт отвечает, клиент видит tools, агент может вызвать read-only и создать черновик.
Официальный MCP Adapter: где взять и как активировать
- Убедитесь, что сайт на WordPress 6.9 или новее (на Beget и типичном shared-хостинге из РФ это обычный апгрейд через админку или панель хостинга).
- Установите официальный пакет wordpress/mcp-adapter одним из способов:
ZIP с релизов GitHub WordPress/mcp-adapter → Плагины → Загрузить;
или через WP-CLI:wp plugin install …/mcp-adapter.zip --activate;
или Composer:composer require wordpress/mcp-adapter. - Берите релиз не ниже v0.5.0 — в более ранних версиях были известные сбои с default abilities.
- После активации появляется default MCP server с id
mcp-adapter-default-server. - HTTP-точка входа:
https://ваш-сайт.ru/wp-json/mcp/mcp-adapter-default-server(нужен HTTPS).
Из коробки в ядре есть read-only abilities вроде core/get-site-info, core/get-user-info, core/get-environment-info. Для default-сервера их тоже нужно пометить как публичные для MCP — иначе клиент «подключится», а список действий будет пустым. Пустые tools после первого коннекта — ожидаемое поведение, а не обязательно баг.
Локально можно поднять STDIO через WP-CLI (wp mcp-adapter serve …). Для Cursor/Claude с удалённым сайтом обычно используют remote bridge (см. ниже) — он переводит STDIO клиента в HTTP к WordPress.
Права роли и Application Password без полного админа
Не подключайте агента под учёткой администратора с полным доступом.
- Создайте отдельного пользователя, например
mcp-agent. - Назначьте роль Author или Editor — ровно столько, сколько нужно для черновиков (и позже — для публикации, если решите).
- В профиле пользователя создайте Application Password (Пароль приложения). Скопируйте один раз и храните в менеджере секретов / env клиента, не в чате и не в репозитории.
Из России связка работает на обычном self-hosted WordPress (в том числе на Beget): нужны HTTPS, актуальный WP и возможность ставить плагин. Cursor и Claude — коммерческие клиенты; оплата/доступ из РФ иногда упирается в карты и регион — заранее проверьте, чем пользуетесь вы. Альтернатива для практики: локальный стенд + STDIO, затем перенос конфига на боевой сайт.
Как сигнал доходит до сайта — и где человек останавливает автопилот
Ниже — не hero, а карта безопасного пайплайна: abilities открываются адаптером, агент создаёт черновик, HITL держит гейт до публикации.
- Abilities API — именованные действия сайта с проверкой прав.
- MCP Adapter — мост: discover → get-info → execute.
- Draft + HITL — агент пишет черновик; человек жмёт Publish.
Дальше разберём, какие abilities открыть агенту — и какие сознательно не отдавать.
Как зарегистрировать abilities, которые агенту реально нужны
Default-сервер не раздаёт автоматически все abilities сайта. Для публичного доступа через default server в регистрации ability нужен флаг meta.mcp.public => true. Без флага действие есть внутри WordPress, но невидимо в discover.
Альтернатива для разработчика: свой MCP-сервер через mcp_adapter_init с явным списком abilities — тогда флаг public не обязателен. Для маркетолога и контент-команды чаще достаточно default + public на нужных действиях.
Черновик поста, чтение статуса, публикация — минимум на старте
Практичный минимум для контент-конвейера:
| Ability (смысл) | Зачем | Риск |
|---|---|---|
| Инфо о сайте / окружении | Проверить, что агент «видит» правильный сайт | Низкий |
| Создать черновик поста | Черновик из брифа в Gutenberg | Средний |
| Прочитать статус/ID черновика | Контроль «что создалось» | Низкий |
| Публикация | Выводить пост в открытый доступ | Высокий — не на старте |
Готовых «create_post / publish» abilities «из коробки адаптера» ждать не стоит: core abilities — в основном диагностика. Запись контента — это кастомная ability (свой код в теме/mu-plugin) или отдельный AI-слой. Для контент-завода достаточно ability «создать черновик» с жёстким permission_callback.
При регистрации часто ломаются на мелочах:
- хук только
wp_abilities_api_init(не «любой init»); - обязательная category (
site/user/mcp-adapterи т.п.) — без валидной категории регистрация может молча вернуть null; - callbacks принимают
$input = null; - для default server —
meta.mcp.public.
Пример логики (упрощённо): ability create_draft_post создаёт пост со статусом draft, проверяет права текущего пользователя и не умеет менять статус на publish.
Least-privilege: что сознательно не отдаём агенту
Не открывайте агенту:
- установку/удаление плагинов и тем;
- управление пользователями и ролями;
- массовое удаление постов;
- смену паролей и настроек безопасности;
- публикацию без отдельного осознанного решения команды.
Правило редакции: сначала read-only + draft. Write на продакшен — только после тестов на staging. Destructive abilities с __return_true в permission — антипаттерн.
Подключение Cursor как MCP-клиента к сайту
Конфиг сервера и проверка, что tools видны
Типовой путь для удалённого сайта — npm-пакет @automattic/mcp-wordpress-remote (через npx). Bridge берёт STDIO от клиента и ходит в HTTP REST WordPress с Application Password.
В настройках MCP клиента (Cursor) задают примерно:
- команда запуска bridge (
npx … @automattic/mcp-wordpress-remote); - переменные:
WP_API_URL(URL сайта),WP_API_USERNAME(логин отдельного user),WP_API_PASSWORD(Application Password).
Официальный разбор установки и конфигов клиентов — в статье WordPress Developer Blog про MCP Adapter.
Признак успеха: в Cursor в списке MCP tools видны три инструмента адаптера: discover-abilities, get-ability-info, execute-ability. Дальше агент через discover находит ваши public abilities (например, create draft).
Шаг 1. Агент вызывает discover — видит список открытых abilities. Шаг 2. Get-info по одной ability — читает описание и схему входа. Шаг 3. Execute на безопасной ability (site-info или create draft) — получает ответ без ошибки auth.
Типовой сбой: агент видит сервер, но не видит abilities
Симптом: MCP «зелёный», а tools пустые или discover ничего не отдаёт.
Проверьте по порядку:
- Есть ли хоть одна ability с
meta.mcp.public? - Версия адаптера ≥ 0.5.0?
- Category при регистрации валидна?
- Хук —
wp_abilities_api_init? - Сайт по HTTPS, URL в
WP_API_URLбез опечатки? - Application Password не отозван и принадлежит тому же user?
Пустой список после «чистого» коннекта часто означает: ничего не помечено public. Это by design.
Claude Code и другие MCP-клиенты на том же Adapter
Чем конфиг отличается от Cursor
Тот же bridge и те же Application Passwords работают для Claude Desktop, Claude Code и VS Code. Меняется только файл/UI, куда вы вписываете команду и env. Логика abilities на стороне WordPress одна.
Частые отличия окружения:
- в Claude Desktop иногда ломается PATH к PHP/Node — bridge не стартует;
- для длинных STDIO-сессий упираются в
max_execution_timeна сервере; - разные клиенты по-разному показывают «3 meta-tools» — это нормально: abilities «внутри» discover/execute.
Когда один сайт — несколько клиентов
Можно подключить и Cursor, и Claude к одному default server. Тогда:
- заведите разных WP-users или хотя бы разные Application Passwords;
- не смешивайте секреты в одном чате;
- на продакшене лучше разделить «черновик-агент» и «диагностика».
WordPress.com MCP опирается на ту же идею Abilities + Adapter, но auth там другой (OAuth). Self-hosted гайд = Application Passwords, не копируйте one-click Connectors с .com как обязательный шаг для mcp-adapter.
Не путайте слой Settings → Connectors / AI Experiments с самим MCP Adapter: адаптер работает через abilities + пароль приложения + bridge, без обязательных ключей «AI provider» в настройках сайта.
Безопасный сценарий: черновик → проверка человеком → публикация
По открытым обзорам рынка доверие к агентам в production остаётся невысоким: даже там, где агентов уже используют, команды часто не готовы отдать им полный контроль. Для WordPress это прямой аргумент за человеческий гейт.
HITL-чек перед автопостингом: заголовок, статус, URL, роль
Чеклист приёмки черновика:
- Заголовок и H1 — без кликбейта и фактических ошибок.
- Статус — точно
draft, неpublishи неprivateпо ошибке. - URL/slug — нет конфликта с уже опубликованными страницами.
- Роль агента — какой user создал пост; не админ ли «случайно».
- Картинки и ссылки — рабочие, без чужих персональных данных.
- Тон и оффер — соответствует брендбуку, нет выдуманных цифр.
Только после галочки — человек жмёт «Опубликовать» в Gutenberg или отдельная ability publish под более жёсткой ролью (и отдельным паролем).
Где ломается автопубликация без ручного гейта
Типичные провалы без HITL:
- агент путает черновик с обновлением чужого поста;
- в бриф попали непроверенные факты — они улетают в индекс;
- слишком широкие права → агент «починил» не то;
- несколько клиентов пишут параллельно без очереди;
- отзыв Application Password забыли после теста — секрет продолжает жить в конфиге.
Unattended publish адаптер сам по себе не запрещает продуктово: это ваша редакция и security-политика. Стартуйте с ручного approve; к автомату переходите только когда процесс стабилен на staging.
Ошибки, из‑за которых агент «молчит» или пишет не туда
Auth, REST и Application Password
| Симптом | Частая причина | Что сделать |
|---|---|---|
| 401 / unauthorized | Неверный App Password, пробелы при копировании | Пересоздать пароль, обновить env |
| Коннект есть, tools пусто | Нет meta.mcp.public | Открыть нужные abilities |
| Discover пустой | Ability не зарегистрирована / молча упала category | Проверить category и хук |
| Работает на HTTP, падает снаружи | Нет HTTPS / mixed content | Только HTTPS на проде |
| «Как будто REST, но MCP 404» | Неверный путь endpoint | Проверить /wp-json/mcp/mcp-adapter-default-server |
| Старый плагин Automattic | Устаревший стек | Мигрировать на wordpress/mcp-adapter |
MCP-клиент действует как залогиненный пользователь WordPress. Относитесь к нему как к части поверхности атаки приложения: логируйте, ограничивайте, отзывайте секреты.
Неверная ability, лишние права, конфликт плагинов
- Execute «не той» ability — всегда сначала get-info.
- Роль Administrator «для удобства» — главный антипаттерн новичка.
- Конфликт security-плагинов, режущих Application Passwords или REST
/wp-json/mcp/…. - Кэш/CDN отдают старый ответ на MCP endpoint.
- На shared-хостинге из РФ проверьте, что REST не отключён «для безопасности» без исключений.
Как встроить связку в контент-конвейер, а не в разовую демо
Демо «агент создал пост» полезно один раз. Деньги и время экономятся, когда это очередь.
Агент + очередь черновиков + ручная приёмка
Рабочая схема редакции:
- Бриф (тема, ключи, CTA, запреты) → агент в Cursor.
- Агент через MCP вызывает ability «создать черновик».
- Черновик падает в wp-admin со статусом draft.
- Редактор правит в Gutenberg (факты, тон, SEO-мета).
- Публикация человеком.
- Дальше — ваши каналы: Telegram, рассылка, перелинковка.
Соседний слой автоматизации (Make.com, боты) может забирать уже опубликованный URL или уведомлять редактора о новом draft. Make не заменяет Abilities API: это другой этаж пайплайна. Для команды, которая собирает контент-завод и вайбкодинг-процессы, WordPress-MCP — кусок «агент пишет на сайт», а не замена всей воронки.
Соседний слой пайплайна — Make и сценарии автоматизации. Если нужна системная траектория «агент → черновик → каналы», смотрите обучение по автоматизации и вайбкодингу на kv-ai.ru.
Где MCP экономит время редакции для бизнеса
Экономия не в «кнопке сгенерировать», а в сокращении ручной возни:
- не копировать текст из чата в wp-admin;
- не путать окружения (staging vs prod), если abilities разведены;
- стандартизировать «что агент умеет» списком abilities;
- быстрее онбордить нового автора: права = роль + App Password + 3 tools.
Не обещайте себе нулевой контроль качества. MCP ускоряет доставку черновика; качество по-прежнему на HITL.
FAQ
Нужен ли отдельный MCP-сервер, если есть Adapter?
Для старта — нет. Default server mcp-adapter-default-server уже поднимается с плагином. Отдельный (custom) server имеет смысл, когда нужен явный список abilities без public-флагов или несколько изолированных контуров.
Можно ли публиковать сразу без черновика?
Технически ability publish можно написать. Редакционно — плохая идея на старте. Безопасный путь: draft → человек → publish. Автопубликацию включайте только после стабильных прогонов и узких прав.
Чем путь через MCP безопаснее «логин админа в промпт»?
Вы не кладёте пароль администратора в чат. Используете отдельного user, Application Password с отзывом, abilities с permission_callback и минимальный набор действий. Агент не получает «весь REST», а только то, что вы экспонировали.
Чек-лист запуска за один вечер
Установка → abilities → клиент → тестовый черновик → HITL → публикация
Шаг 1. Сайт. WordPress 6.9+, HTTPS, бэкап. Шаг 2. Плагин. Официальный MCP Adapter ≥ 0.5.0, активирован. Шаг 3. User. Отдельный Author/Editor + Application Password. Шаг 4. Abilities. Read-only + create draft с meta.mcp.public и валидной category. Шаг 5. Клиент. Cursor или Claude + @automattic/mcp-wordpress-remote и три env-переменные. Шаг 6. Тест. Discover → get-info → execute (site-info). Шаг 7. Черновик. Агент создаёт draft из брифа. Шаг 8. HITL. Человек проверяет чеклист и публикует вручную. Шаг 9. Гигиена. Отозвать тестовые пароли, не хранить секреты в git.
Признак успеха за вечер: в админке есть черновик от user mcp-agent, в клиенте видны 3 meta-tools, публикация прошла только после вашей кнопки.
Типичные ошибки новичка:
- Поставили community-плагин вместо официального adapter — другая модель безопасности и tools.
- Подключили админа «чтобы точно работало» — слишком широкий blast radius.
- Ждут список abilities как отдельные tools в Cursor — на default server они внутри discover/execute.
- Забыли
meta.mcp.public/ category — «тишина» после успешного коннекта. - Смешали Connectors UI и mcp-adapter — чинят не тот слой.
Что проверяли по источникам
- Канон: WordPress Developer Blog (Abilities → MCP Adapter), README и релизы GitHub WordPress/mcp-adapter.
- Практика setup/security: обзоры SmartWP и InstaWP (сверять спорные тезисы вроде «нужен WP 7.0» с официальным минимумом 6.9).
- Контраст семейств MCP и контекст HITL — по открытым RU-публикациям рынка агентов, без подмены темы гайда.
Self-hosted WordPress на HTTPS — обычный контур для MCP Adapter. Ниже — партнёрский хостинг, на котором удобно держать боевой сайт и staging.
