WordPress · MCP Adapter · гайд

Как подключить ИИ-агентов
к WordPress через MCP Adapter

Пошагово: адаптер в WordPress, MCP в Cursor/Claude и публикация постов агентами без ручной админки

Чат с нейросетью умеет писать текст. Но сайт живёт в WordPress: черновики, категории, медиа, SEO-поля, права пользователей. Пока вы копируете абзацы вручную, агент остаётся «советником», а не частью контент-контура.

Коротко. Цель гайда — за один вечер связать Cursor или Claude с вашим WordPress через официальный MCP Adapter, чтобы агент публиковал и обновлял контент без ручного REST-костыля.

Зачем агенту доступ к WordPress, а не только к чату

ИИ-агенты в этой схеме — программы, которые не только генерируют текст, но и вызывают инструменты: прочитать список постов, создать черновик, проверить данные сайта. Работа с ИИ-агентами становится полезной для контент-команды именно тогда, когда агент может делать в CMS то же, что вы делаете в админке — по правилам и с ограниченными правами.

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

Чат без CMS

Текст есть, но копипаст в админку съедает время и ломает ритм команды.

MCP-канал

Агент вызывает abilities WordPress: list, draft, update — с правами пользователя.

Контент-завод

Бриф → черновик → ревью → публикация → дистрибуция в Make/соцсети.

MCP простыми словами: мост между моделью и инструментами

Маркер: простыми словами. MCP (Model Context Protocol) — общий язык, по которому ИИ-клиент узнаёт список доступных инструментов и вызывает их. MCP-сервер — сторона, которая эти инструменты отдаёт. Клиент (Cursor, Claude Desktop, Claude Code) — сторона, которая ими пользуется.

Без MCP агент «не знает», какие кнопки есть на вашем сайте. С MCP WordPress сам сообщает: вот список способностей, вот как их вызвать, вот какие права нужны. Вы подключаете MCP-сервер один раз — и дальше агент работает через стандартный протокол, а не через самописные скрипты.

Чем MCP отличается от «просто REST API»

REST API WordPress — это низкоуровневый доступ: вы сами пишете запросы, токены, обработку ошибок. Удобно разработчику. Неудобно маркетологу, который хочет сказать агенту: «создай черновик поста про MCP».

MCP поверх сайта даёт другое:

агент сам находит доступные действия (discover);
действия описаны схемами входа и выхода;
права проверяются как у обычного пользователя WordPress;
один и тот же клиент (Cursor) может ходить и на сайт, и в другие MCP-серверы.

Маркер: простыми словами. Discover → execute — двухшаговый режим: сначала агент спрашивает «какие abilities есть», потом вызывает нужную по имени. На default-сервере WordPress это не «все кнопки сразу в списке tools», а meta-tools для поиска и запуска.

Путать MCP с llms.txt и GEO не стоит. llms.txt помогает моделям читать и цитировать контент. MCP помогает агенту действовать на сайте. Make-waterfall публикует по жёсткому сценарию без диалога. Три разных слоя — три разные боли.

Что делает MCP Adapter на стороне WordPress

MCP Adapter — официальный пакет инициативы AI Building Blocks for WordPress. Он берёт abilities (способности сайта) из Abilities API и отдаёт их наружу в формате MCP: tools, resources, prompts.

Маркер: простыми словами. Abilities API — встроенный с WordPress 6.9 способ зарегистрировать функцию сайта: имя вроде namespace/ability-name, схема входных данных, проверка прав и код выполнения. Адаптер не изобретает «магию ИИ» — он делает abilities видимыми для MCP-клиентов.

Важные факты без мифов:

Abilities API уже в ядре с WordPress 6.9. Не ждите «только 7.0+» — так пишут часть сторонних гайдов, но первоисточники ядра фиксируют 6.9.
MCP Adapter — отдельный пакет/плагин (wordpress/mcp-adapter, актуальный релиз v0.5.0). В ядро пока не влит.
На default-сервере ability видна агенту только если у неё meta.mcp.public = true. Зарегистрировали без флага — в WordPress она есть, в Cursor её нет. Это самая частая причина «пустого списка».

Из коробки в 6.9 есть три core abilities: core/get-site-info, core/get-user-info, core/get-environment-info. Для default MCP-сервера их тоже нужно явно открыть флагом meta.mcp.public через фильтр.

HTTP-endpoint default-сервера: /wp-json/mcp/mcp-adapter-default-server. Агент ходит туда не «как гость», а как залогиненный пользователь WordPress.

Визуализация · не hero

Мост: агент → MCP Adapter → WordPress

Слева — клиент (Cursor/Claude). Две дорожки — локальный STDIO и удалённый HTTP — сходятся в Adapter. Справа abilities открывают карточку поста: сначала черновик, потом публикация.

STDIO: WP-CLI на своём сервере — удобно для разработки.
HTTP: remote-прокси + Application Password — для staging/прода.
Abilities: видит агент только с meta.mcp.public.

Дальше — что подготовить до установки: права, токены и отдельный пользователь под агента.

Редакционная схема, не скриншот админки: цикл показывает discover → execute → черновик → публикация.

Что подготовить до установки: сайт, права, токены

Перед установкой проверьте чеклист — иначе потеряете вечер на 401 и пустые tools.

Минимальные требования пакета (ориентир v0.5.0): PHP 7.4+, WordPress 6.9+. Для новых проектов не опирайтесь на старые схемы с отдельным abilities-api для 6.8 — репозиторий abilities-api уже архивирован.

Что должно быть на сайте:

HTTPS (для удалённого HTTP-подключения Application Password без HTTPS часто не работает);
доступ администратора на этап установки;
отдельный пользователь под агента (не ваш личный админ);
понимание: staging или прод (для первых тестов лучше staging).

Роли и Application Passwords / OAuth — без дыр в доступе

Маркер: простыми словами. Application Password — специальный пароль приложения в профиле пользователя WordPress. Его дают MCP-клиенту вместо обычного пароля входа. Его легко отозвать, не меняя основной пароль.

Как сделать безопасно:

Создайте пользователя, например mcp-agent.
Дайте роль Editor (или кастомную с минимальными caps), не Administrator.
В профиле пользователя: Users → Profile → Application Passwords → создайте пароль с понятным именем (cursor-mcp).
Сохраните логин + application password в менеджере секретов. В чат и в репозиторий не кладите.

OAuth и JWT пакет remote тоже поддерживает, но для старта чаще хватает Application Password и OAUTH_ENABLED=false у прокси. Если сомневаетесь — начните с App Password: проще отозвать.

Какие права агенту реально нужны для постов и медиа

Для сценария «черновик поста»:

создавать и редактировать записи (edit_posts);
при необходимости загружать медиа (upload_files);
не нужны: установка плагинов, смена темы, управление пользователями, правка кода.

Правило: на публичном HTTP сначала открывайте только read-only abilities (список постов, site info). Write-abilities (создание черновика) — после smoke-теста и на отдельном пользователе. Клиент MCP = поверхность атаки вашего приложения: так прямо сказано в официальном Developer Blog WordPress.

Установка и включение MCP Adapter в WordPress

Два рабочих пути:

Плагин из репозитория WordPress/mcp-adapter (удобно для большинства сайтов).
Composer-пакет wordpress/mcp-adapter в теме/плагине (удобно разработчикам).

После установки:

убедитесь, что плагин активен;
запомните имя default-сервера: mcp-adapter-default-server;
endpoint: https://ваш-домен.ru/wp-json/mcp/mcp-adapter-default-server.

Старые гайды про репозиторий Automattic/wordpress-mcp не используйте как канон: проект архивирован примерно в январе 2026, официальный путь — mcp-adapter.

Проверка, что адаптер отвечает и виден клиенту

Пока клиент не подключён, проверьте базу:

REST endpoint открывается по HTTPS (не 404).
Abilities API доступен (ядро 6.9+).
Хотя бы одна ability с meta.mcp.public зарегистрирована (для smoke-теста — откройте core/get-site-info).

Маркер: простыми словами. meta.mcp.public — флаг «отдать эту ability наружу через default MCP-сервер». Без него ability живёт внутри WordPress, но агент её не увидит. На custom MCP-сервере abilities можно перечислить явно в create_server() — тогда флаг не обязателен.

Если пишете свою ability, держите четыре правила из практики 2026:

Регистрация только на хуке wp_abilities_api_init (не на выдуманных хуках из упрощённых гайдов).
Поле category обязательно и должно быть заранее зарегистрировано (site / user / mcp-adapter в 6.9).
Callbacks принимают $input = null.
Для default-сервера — meta.mcp.public => true.

Миф «зарегистрировал ability — и она сразу у ИИ» — ложный. Без публичного флага на default-сервере Cursor покажет пустоту.

Как подключить MCP-сервер к Cursor

Выбор транспорта зависит от того, где крутится сайт.

Режим	Когда брать	Как работает
STDIO (локально)	Сайт на вашем компьютере / локальный Docker	WP-CLI: `wp mcp-adapter serve --server=mcp-adapter-default-server --user=...`
HTTP (удалённо)	Staging/прод на хостинге	Прокси `npx -y @automattic/mcp-wordpress-remote@latest` + Application Password

Маркер: простыми словами. STDIO — клиент запускает локальную команду и общается с ней «по трубе». HTTP — клиент ходит на удалённый endpoint сайта через прокси. Для команды контента на боевом WordPress почти всегда нужен HTTP.

Для контент-команды из России типичный путь: WordPress на Beget/другом хостинге + Cursor на рабочем ПК + HTTP-прокси. Cursor и Claude Desktop доступны, но оплату зарубежных подписок иногда приходится решать через доступные способы; сам MCP Adapter на вашем сайте работает независимо от страны.

Конфиг клиента: где прописать сервер и окружение

В Cursor: Tools & MCP → конфиг mcp.json (проектный .cursor/mcp.json или пользовательский — как принято у вашей версии).

Пример логики для HTTP (значения подставьте свои):

{
  "mcpServers": {
    "wordpress": {
      "command": "npx",
      "args": ["-y", "@automattic/mcp-wordpress-remote@latest"],
      "env": {
        "WP_API_URL": "https://ваш-домен.ru/wp-json/mcp/mcp-adapter-default-server",
        "WP_API_USERNAME": "mcp-agent",
        "WP_API_PASSWORD": "xxxx xxxx xxxx xxxx xxxx xxxx",
        "OAUTH_ENABLED": "false"
      }
    }
  }
}

Частые ловушки в WP_API_URL:

указали корень сайта вместо полного endpoint MCP;
забыли https://;
опечатка в имени сервера;
staging с basic-auth без учёта в прокси.

Для STDIO в конфиге указывают wp (или путь к phar) и аргументы mcp-adapter serve .... Практический нюанс: Claude Desktop часто не видит php в PATH — тогда command ставят абсолютный путь к PHP, а WP-CLI phar — первым аргументом.

Быстрый smoke-тест: агент читает/пишет тестовый черновик

Пошаговый how-to (повторите сами):

Сохраните конфиг MCP в Cursor и перезапустите клиент / переподключите сервер в списке MCP.
Откройте чат агента и попросите: «Через WordPress MCP сделай discover abilities и покажи, что доступно».
Попросите выполнить core/get-site-info (через get-ability-info → execute-ability, если клиент идёт layered-моделью).
Если есть ability списка постов (например кастомная my-plugin/get-posts) — запросите 3 последних черновика.
Только после успешного чтения попросите создать тестовый черновик с заголовком вроде MCP smoke-test и статусом draft. На прод не публикуйте сразу.

Признак успеха. В Cursor сервер WordPress зелёный/подключён; агент возвращает название сайта и URL из get-site-info; в админке WordPress появляется черновик от пользователя mcp-agent.

Типичные ошибки новичка:

Пустой список tools / abilities — нет meta.mcp.public или смотрите не тот сервер. Решение: откройте core abilities фильтром, перезапустите клиент.
401 / unauthorized — неверный Application Password, пользователь без прав, HTTP вместо HTTPS. Решение: пересоздайте App Password, проверьте роль Editor.
Агент «думает», что опубликовал, а поста нет — вызвал не ту ability или нет write-права. Решение: проверьте permission_callback и caps; сверьте автора записи в админке.

Связка с Claude и другими MCP-клиентами

Тот же HTTP-прокси работает не только в Cursor.

Claude Desktop — claude_desktop_config.json, ключ mcpServers.
Claude Code — .claude.json / .mcp.json.
VS Code — .vscode/mcp.json, объект называется servers, не mcpServers (частая путаница при копировании конфига).

Подключение MCP к Claude по смыслу то же: логин, пароль приложения, полный URL endpoint. Меняется только файл конфига.

Когда выгоднее Cursor, а когда отдельный клиент

Задача	Что взять
Правка сайта + код темы/плагина рядом	Cursor (агент видит репозиторий и MCP)
Быстрый диалог «создай черновик» без IDE	Claude Desktop
CLI-сценарии и скрипты	Claude Code / локальный STDIO
Команда без разработчика, только контент	HTTP + любой MCP-клиент; права Editor

Если вы только учитесь созданию ИИ-агента под контент, начните с Cursor + HTTP: один конфиг, один smoke-тест, понятный лог ошибок.

Сценарий: агент готовит пост и публикует на сайт

Соберём рабочий контур без хаоса.

Черновик → ревью → публикация: кто что делает

Человек даёт бриф: тема, ключи, тон, запреты, ссылки.
Агент через MCP читает похожие посты (list), чтобы не дублировать.
Агент создаёт черновик (create/draft ability) — не сразу publish.
Редактор смотрит превью в админке WordPress.
Публикация — либо человек кнопкой, либо агент по явной команде после ревью.

Так автопостинг WordPress не превращается в «агент выложил ерунду ночью». MCP даёт контроль: каждый вызов — с правами пользователя и с вашим диалогом.

Пример кастомной ability «список постов» из официального README: my-plugin/get-posts с параметрами вроде numberposts / post_status и флагом meta.mcp.public. Паттерн create-post + проверка через get-post — тот же: сначала write, потом read для верификации.

Медиа, категории, SEO-поля — что агент может испортить

Что агент часто ломает без жёсткого брифа:

вешает пост не в ту категорию;
заливает тяжёлые картинки без alt;
затирает SEO title/description плагина;
публикует вместо draft;
правит живую страницу вместо копии.

Защита:

в ability разрешайте только post_status=draft на старте;
категории передавайте явным ID из брифа;
медиа — отдельным шагом после текста;
SEO-поля — либо read-only, либо отдельная ability с узкой схемой;
на проде запретите destructive annotations, пока процесс не обкатан на staging.

Субагенты в контуре публикации: роли без хаоса

Один «универсальный» агент быстро смешивает исследование, стиль и публикацию. Субагенты (в смысле ИИ-оркестрации) делят ответственность.

Исследователь, редактор, публикатор — разделение ответственности

Роль	Что делает	Какой доступ к WP
Исследователь	Собирает факты, конкурентов, структуру	Read-only: list posts, site info
Редактор	Пишет и правит текст по брифу	Draft create/update
Публикатор	Меняет статус, категории, финальные поля	Узкие write-caps; лучше после ручного OK

Так работа с ИИ-агентами масштабируется: ошибка исследователя не публикует мусор, а публикатор не «думает заново» весь текст. В Cursor это может быть несколько чатов/правил с разными MCP-правами (разные WP-пользователи) — дороже в настройке, но безопаснее на проде.

Типичные ошибки подключения и как их отловить

Адаптер не отвечает / 401 / пустой список tools

Симптом	Вероятная причина	Что сделать
404 на endpoint	Плагин не активен / неверный URL	Проверьте путь `/wp-json/mcp/mcp-adapter-default-server`
401	Плохой App Password / нет HTTPS	Новый пароль, только HTTPS
Tools пустые	Нет `meta.mcp.public`	Откройте abilities фильтром
Клиент молчит	Неверный ключ конфига / VS Code `servers` vs `mcpServers`	Сверьте формат клиента
STDIO падает	PHP не в PATH	Абсолютный путь к PHP

Настройка MCP-сервера почти всегда сводится к трём проверкам: URL, auth, public-флаг.

Агент «видит» сайт, но не может создать запись

Значит discover работает, execute — нет:

permission_callback слишком строгий или наоборот __return_true на destructive (плохо для безопасности, но тогда проблема в caps);
у пользователя нет edit_posts;
ability создания не зарегистрирована / не public;
агент вызывает несуществующее имя ability.

Решение: в админке зайдите под mcp-agent и вручную создайте черновик. Если вручную нельзя — чините роль. Если вручную можно, а через MCP нельзя — чините ability и permission_callback.

Безопасность: что нельзя отдавать агенту на прод-сайте

Не отдавайте на боевом HTTP:

роль Administrator «для удобства»;
abilities установки плагинов, правки файлов, управления пользователями;
__return_true на destructive действиях;
один вечный App Password на всю команду без отзыва;
запись логов с паролями в git.

Песочница, staging и минимальные права

Порядок внедрения:

Staging-копия сайта.
Пользователь Editor + App Password.
Только read abilities → smoke-test.
Draft-only write → тест черновика.
Publish — осознанно, лучше человеком.
Прод — те же ограничения + мониторинг ошибок.

Application Password удобно отзывать при увольнении сотрудника или утечке конфига. Делайте это сразу, не «потом».

От одного поста к контент-заводу на WordPress

Когда smoke-тест стабилен, связывайте слои:

MCP Adapter — агент создаёт и правит черновики в WP.
Make / waterfall — разнос в Telegram, соцсети, уведомления редактору (фиксированный сценарий).
GEO / llms.txt — видимость контента для нейросетей и цитирование (не публикация).

Вайбкодинг здесь — не «писать код ради кода», а собирать контур: бриф → агент → черновик → ревью → публикация → дистрибуция. Как создать контент-завод на WordPress: начните с одного канала MCP, а не с десяти плагинов «ИИ пишет пост».

Календарь, переиспользование, контроль качества перед выкладкой

Практичный минимум контроля:

календарь тем в таблице (дата, ключ, статус draft/ready);
шаблон брифа для агента (тон, CTA, запреты);
чеклист перед publish: заголовок, alt у картинок, категория, canonical/внутренние ссылки;
архив удачных промптов и abilities в репозитории команды.

Так AI-контент-завод остаётся управляемым: агент ускоряет руками, человек держит качество.

FAQ

Что такое MCP Adapter и зачем он WordPress

Это официальный мост: abilities WordPress → инструменты MCP. Чтобы ИИ-агенты могли безопасно вызывать действия сайта (читать, создавать черновики и т.д.) через стандартный протокол, а не через разовые скрипты.

Можно ли подключить MCP без Cursor

Да. Подойдут Claude Desktop, Claude Code, VS Code и другие MCP-клиенты. Меняется файл конфига, не логика на стороне WordPress.

Чем MCP-публикация лучше плагина «ИИ пишет пост»

Плагин обычно генерирует текст внутри админки по шаблону. MCP даёт диалоговый контроль, права пользователя, discover инструментов и связку с вашей IDE/агентом. Плюс вы сами решаете, какие abilities открыть.

Нужен ли отдельный MCP-сервер или хватит адаптера в WP

Для старта хватит default-сервера адаптера. Custom MCP-сервер нужен, когда хотите явно перечислить abilities без meta.mcp.public или собрать отдельный набор tools под продукт.

Как проверить, что агент не сломает живые страницы

Staging, роль без лишних caps, draft-only abilities, ручное ревью перед publish, отзыв App Password при инциденте. Не давайте агенту Administrator на проде «на всякий случай».

Что проверяли по источникам

Официальный WordPress Developer Blog: введение MCP Adapter и Abilities → агенты — developer.wordpress.org.
Make WordPress Core: Abilities API в WordPress 6.9 — make.wordpress.org.
Репозиторий и релиз пакета wordpress/mcp-adapter (v0.5.0) — GitHub WordPress/mcp-adapter.
HTTP-прокси @automattic/mcp-wordpress-remote — npm-пакет Automattic.
Русскоязычная практика подключения агентов к WP через MCP — разборы вроде WP Craft (с оговоркой: порог «только 7.0+» не считаем обязательным).