By Antoine Riesser, founder, Animam.ai · Updated May 18, 2026 · 12 min read

Good news for WordPress in 2026: the protocol layer for AI agents is solved. The Model Context Protocol (MCP), published by Anthropic in November 2024, is now a stable standard. There’s an official MCP plugin for WordPress, the OAuth 2.1 + PKCE plumbing is documented, the JSON-RPC handshake works, the discovery files are converging. If you’re a developer who wants Claude Desktop or Cursor to operate your WordPress site, you can wire it up today.

Less good news: the protocol is not a product. HTTP is a protocol; your e-commerce store is a product. MCP opens a port; the chatbot your visitor talks to is the product. The official WP MCP plugin gives you a beautifully implemented door — but most WordPress sites don’t have a building on the other side. This article is about that building.

The protocol layer: a solved problem

Credit where due. The MCP standard maturing for WordPress is a big deal. Practical consequences:

  • OAuth 2.1 + PKCE handshake — Claude Desktop / Cursor can authenticate against your WP site without you writing a single line of OAuth code.
  • JSON-RPC 2.0 lifecycle — initialize, tools/list, tools/call, cancellation, SSE streaming, all implemented to spec.
  • Capability scoping — tools respect current_user_can(), OAuth scopes filter the tool list per user role.
  • Discovery files — /.well-known/oauth-authorization-server, /.well-known/webmcp.json, the right metadata so agents auto-discover your endpoint.

If you’re a developer evaluating MCP for WordPress, install the official plugin, plug Claude Desktop, run tools/list, see the WP REST surface exposed as MCP tools. It works. Anthropic’s spec is good, the WP implementation is faithful, the agentic web has a door into WordPress.

But protocol ≠ product

Here’s the gap nobody warns you about. A site that “supports MCP” is reachable by 0.1% of its potential audience — the technical users who run Claude Desktop, claude.ai, or Cursor. Those people are valuable (they’re often devs evaluating your product), but they’re not the typical visitor.

The other 99.9% — your actual visitors — show up via a browser. They want to ask a question, book a meeting, get a quote, find a product. They’re not going to install Claude Desktop to talk to your site. They expect a chatbot widget on the page. That widget needs a UI, a personality, a streaming response, a form bridge, a calendar bridge, a payment bridge. Building it isn’t 4 hours of work — it’s 4 months. And it has nothing to do with MCP.

Same on the admin side. The official MCP plugin lets you (the WP admin) connect Claude Desktop and operate your site through it. Cool for power users. But your editors / content team / agency clients probably won’t. They’d use an AI assistant inside wp-admin — a chat window next to the post editor, that can audit SEO, fix ALT text, draft a post, schedule it. Same backend, different UX. Also not what the protocol provides.

The two UX surfaces that turn MCP into a product

Concretely, what’s missing between “I have an MCP endpoint” and “my site has an AI agent”?

The visitor chatbot (front-end)

A widget on every page. Streams responses token by token. Has a personality you configure. Reads your corpus (pages, posts, products) on the fly. Calls tools when relevant (book a meeting, submit a contact form, recommend a product). Handles the visitor’s full session — auth-optional, memory across messages, escalate-to-human. Renders gracefully on mobile, fail-open if rate-limited, respects your content policy. This is what your visitor sees. It’s the front of the building.

The admin AI assistant (back-end)

A chat panel inside wp-admin. Knows your site’s structure (posts, pages, custom fields, RankMath / Yoast meta). Can audit SEO, fix bulk ALT text, draft and schedule posts, search the content for refresh candidates, generate FAQ schema. Operates with the current admin’s capabilities, with a full audit trail. The agent your editor talks to to actually get work done. It’s the back office of the building.

Both surfaces use MCP-style tooling under the hood. Both benefit from the protocol standardization. Neither comes with the protocol plugin.

How Animam ships these two surfaces

The Animam plugin for WordPress is, in 2026, focused on exactly the gap above: the two UX surfaces that the protocol layer doesn’t provide.

  • Public visitor chatbot. Drop-in widget, no theme edit. Streams responses, configurable personality, BYOK if you want your own LLM provider. Reads your published WP content automatically (no manual sync — save_post hook updates the corpus). Bridges into WPForms (forms become tools), WooCommerce (catalog + orders), MailPoet (list subscriptions), Google Calendar (availability + booking). Content policy + age gate per tenant.
  • Admin AI assistant. Lives in wp-admin under “Animam Assistant.” 16 admin tools available: wp_seo_audit, wp_create_post, wp_set_seo_meta, wp_set_image_alt_bulk, wp_search_posts, wp_publish_post, wp_schedule_post, wp_rest_call (escape hatch), plus bridges to WPForms / WooCommerce / MailPoet that auto-detect installed plugins.
  • Same brain, two scopes. The public chatbot has a narrow, visitor-safe tool set. The admin assistant has the full 16-tool surface, gated by current_user_can(). Audit log on both. No data leak between scopes.

Animam also ships its own MCP server (/wp-json/animam/v1/mcp) — same OAuth 2.1 + PKCE flow, same tools exposed to MCP clients. So if you skip the official plugin and just install Animam, you still get the protocol layer. But the two products solve different problems: the official plugin gives Claude Desktop a door; Animam gives your visitors and your editors a chatbot they can actually use.

Stacking Animam on top of the official MCP plugin

The two can coexist. If you’ve already installed the official MCP plugin and want to add the agent UX on top, the picture looks like this:

  • Official plugin handles: the canonical MCP endpoint, OAuth dance for external MCP clients (Claude Desktop, Cursor, claude.ai connecting to your WP).
  • Animam handles: the visitor chatbot widget on every page, the admin AI assistant in wp-admin, the bridges to WPForms / WooCommerce / MailPoet, the corpus sync, the discovery files for non-MCP signals (llms.txt, llmfeed.json), the JSON-LD layer (FAQPage, Article, BreadcrumbList, Organization).
  • Shared: JSON-LD output (one canonical schema per page), llms.txt (Animam generates, official plugin doesn’t), agent.json (Animam ships it).

You can also pick either alone. Animam alone gives you everything (protocol + UX). Official plugin alone gives you the protocol. Both together is the most complete picture for WP sites that want to be both agentic-protocol-ready and user-facing-AI-product.

When the protocol alone is enough

Be honest with yourself about your audience. The protocol-only setup is fine when:

  • Your site is dev-tooling-shaped. Internal tools, docs portals, API references. Your audience is technical, they’ll happily install Claude Desktop, point it at your MCP endpoint, and operate from there.
  • You run an agency / consulting site where the AI work happens elsewhere. You want devs / partners to be able to drive your site programmatically, but the marketing pages don’t need a chatbot.
  • You’re early on the curve. Maybe you want to expose MCP first, see who shows up, layer the UX later.

When you need the full agent UX stack

Everyone else, basically:

  • B2C and B2B sites with non-technical visitors — they’re not installing MCP clients, they need a widget.
  • Content sites with editorial teams — the editor wants the AI assistant inside wp-admin, not “open Claude Desktop, type a prompt, hope it routes.”
  • Local businesses, services, healthcare, real estate — visitors arriving with a specific question, expecting an answer in 10 seconds, on the page.
  • Agencies running multi-tenant WordPress for clients — each client needs the bot UX preconfigured, the agency doesn’t have time to coach clients into MCP-client adoption.

For these, MCP-as-protocol is a foundation. MCP-as-product is the work that’s still in front of you. Animam exists for that work.

Frequently asked questions

Do I need to install both the official MCP plugin and Animam?

No. Animam alone covers both the protocol layer (its own MCP server endpoint, OAuth 2.1 + PKCE, 17 tools) and the UX surfaces (visitor chatbot + admin assistant). Stack them if you want the official protocol implementation as a separate canonical endpoint for MCP clients, or rely on Animam’s MCP server for both. Either is supported.

What happens if Claude Desktop connects to both MCP endpoints?

Each MCP endpoint is independent — Claude Desktop registers them as separate servers and lists their tools separately. The user picks which tools to use per task. There’s no conflict; the protocol is designed for multiple servers running side by side.

Is the visitor chatbot using MCP under the hood?

It uses the same tool-calling pattern (typed functions, JSON Schema inputs, capability scoping) but over Animam’s chat protocol, which is optimized for browser-to-server streaming and visitor sessions. The MCP endpoint is where external MCP clients connect; the chatbot widget uses a sister protocol designed for in-page conversation. Both share the tool registry.

Will the chatbot still work if I disable Animam’s MCP server?

Yes. The visitor chatbot and the admin assistant are independent of the MCP server endpoint. Disabling MCP only removes the door for external MCP clients (Claude Desktop, Cursor). The two UX surfaces continue to work — they don’t depend on the MCP wire format, just on the shared tool registry.

What’s the cost of Animam compared to just using the official MCP plugin?

Free plan: 50 conversations / month, 1 agent, full visitor chatbot + admin assistant, both MCP endpoints, bridges to WPForms / WooCommerce / MailPoet. Builder: €49/month, 5,000 pooled conversations, 5 bots. Pro: €79/month, 2,000 conversations + analytics. Agency: €199/month, white-label, 10,000 conversations. The official MCP plugin is free for the protocol layer. Combining both: protocol cost €0, UX cost from €0 to €199 depending on traffic.

Does Animam respect data sovereignty / GDPR?

Yes. The chatbot runs on Animam’s API (EU-hosted by default), with PII redaction in logs (Sentry scrubbed), audit trail in WordPress for every admin tool call, BYOK option to bring your own LLM provider (OpenAI, DeepSeek, Mistral, Groq, etc.), encryption at rest for stored tokens, configurable retention (data retention days per tenant). DPA template available.

What if my visitor doesn’t have JavaScript enabled?

The chatbot widget is JS-based, so no-JS visitors won’t see it. Your page content is unaffected (the widget doesn’t block rendering). For accessibility / no-JS fallbacks, the standard WP form is still on the page; the chatbot is additive.

Does the admin assistant work offline?

No — both surfaces require an internet connection to reach the Animam API (which handles the LLM call). The admin assistant is online-only. For offline AI in wp-admin you’d need a self-hosted LLM, which isn’t what Animam ships (BYOK supports cloud LLMs only as of v0.1.14).

Can I customize what tools the visitor chatbot exposes?

Yes, per tenant in the Animam dashboard. Disable tools you don’t want exposed publicly (e.g., disable payment in WC if you only want lead capture). Add custom tools via the WP filter animam_register_tool. The chatbot only uses the tools you’ve enabled for the visitor scope.

How does Animam handle MCP spec version changes?

Both Animam’s MCP server and the protocol negotiation happen during the initialize step. Current support: 2025-03-26 with backward compat to 2024-11-05. When the spec evolves, we ship a plugin update via the Plugin Update Checker — auto-update path in wp-admin. The visitor chatbot and admin assistant don’t depend on MCP wire format, so they’re unaffected by spec moves.

What’s the deal with the bridges (WPForms, WooCommerce, MailPoet)?

Animam detects which plugins are active and auto-registers tools that route through them. WPForms: each form becomes a tool (the chatbot can fill and submit the form, the entry lands in the WPForms entries dashboard). WooCommerce: catalog browse, product recommendation, add-to-cart. MailPoet: subscribe a visitor to a list. The point is the data lands where you already manage it — no duplicate “Animam submissions” surface to maintain.

Where do I learn more about MCP itself?

The official spec at modelcontextprotocol.io is the source of truth. For WordPress-specific context, this article and the AISEO pillar are our reference takes. The WordPress plugin directory lists the official MCP plugin if you want to install the protocol layer directly.

Sources and further reading

Try Animam — the agent UX layer for your WordPress in 5 minutes

Install Animam (Free plan: 50 conversations/mo). You get the visitor chatbot widget on every page and the admin assistant inside wp-admin — the two UX surfaces the protocol alone doesn’t provide. Stack it with the official MCP plugin if you want, or use Animam’s MCP server standalone. Five minutes to set up. Install the plugin →

Questions, edge cases, “we stack both plugins and here’s what we learned” stories — email [email protected]. This article is a living document and gets updated as the MCP-for-WordPress ecosystem matures.