The Hard Part of a WordPress MCP Server Is Not WordPress

WordPress has MCP now.

WordPress.com includes a built-in MCP server on paid plans, and the WordPress project has introduced an MCP Adapter that can expose registered Abilities over local or remote transports.

That removes a meaningful amount of plumbing. It does not remove the hard part.

For a marketing or IT leader, the real question is not whether Claude can connect to WordPress. It is whether the connection behaves like your organization: the right people, the right post types, the right fields, the right approval state, the right logs, and no production credentials scattered across laptops.

That is why we have come to think of a production WordPress MCP server as a policy and integration project, not a plugin install.

The old model: give the agent broad WordPress access

The shortest demo is easy to understand. Install an adapter, authenticate as an administrator, expose WordPress operations, and ask an agent to create or edit content.

The production version gets uncomfortable quickly.

A real WordPress site is not just posts and pages. It has custom post types, registered meta, Advanced Custom Fields, SEO plugins, media conventions, editorial states, and theme-specific assumptions. The public REST surface depends on how those pieces were registered. A custom post type needs show_in_rest enabled to use the standard controller. Custom meta needs its own REST registration and the post type must support custom fields. WordPress documents both constraints directly.

Then there is authority. “Can edit this post” is rarely the complete rule.

An RSVP workflow might allow an agent to:

• create a new event as a draft

• hide it from public listings

• enforce noindex,nofollow

• search the existing media library

• assign a returned image as the thumbnail

• set a small allowlist of SEO fields

• attach a form

• read the finished status back

It should not automatically allow the same agent to publish the event, upload arbitrary files, rewrite every protected meta key, or make a generic REST request.

Raw API reach is not an operating policy.

The new model: a small catalog of goal-shaped tools

We recently built a remote MCP prototype around an RSVP workflow for Rio.

The server exposed seven tools:

• create_rsvp_form

• create_rsvp_event_draft

• search_media_library

• set_event_featured_media

• set_event_seo

• link_form_to_event

• get_event_status

The names matter. They describe the job, not the underlying endpoint.

The WordPress boundary enforced the decisions that should never depend on prompt quality: the entertainment_events post type, draft-only creation, the RSVP title and slug convention, hidden listing behavior, and search-engine blocking. Media tools accepted only known images returned by search. SEO tools accepted friendly fields instead of raw protected meta keys.

The prototype kept WordPress and Jotform behind deterministic shims, so it did not mutate a live site. That was deliberate. We could test the conversation, tool shapes, authorization, duplicate handling, and policy before asking for production credentials.

Moving from that prototype to production is mostly adapter work:

The important design survives the swap. The agent still sees the same goal-shaped tools. Credentials, provider response shapes, and enforcement stay behind the server.

Why Cloudflare fits the remote boundary

A remote MCP server has two different authentication problems.

First, the human needs to prove they are allowed to use the server. Second, the server needs credentials for WordPress and any downstream providers.

Those credentials should not be the same thing.

Cloudflare Access Managed OAuth gives an MCP client a normal browser-login flow. Access applies identity policy, issues an opaque token to the client, and forwards a signed identity assertion to the protected origin. The Worker must validate that assertion.

That produced a useful acceptance test in the Rio prototype: one allowlisted teammate could connect and see the RSVP tools; another identity received an explicit denial. Neither person stored a WordPress application password or a Jotform API key locally.

Cloudflare Workers then provide the remote execution boundary:

• the MCP transport lives at one HTTPS endpoint

• Access decides which people may reach it

• the Worker validates identity and tool input

• secrets stay server-side

• logs can record the user, tool name, outcome, and timing without recording payload bodies

• stateful or asynchronous Cloudflare services can be added when a workflow earns them

This is not the only viable architecture. It is a coherent one. Identity, runtime, network policy, and deployment sit close together instead of being assembled from an MCP process on one host, an OAuth service on another, and credentials on the operator's machine.

WordPress plugins are where generic tools stop being generic

The plugin ecosystem is also why a single universal WordPress tool catalog has limits.

Consider SEO metadata. A user thinks in terms of “SEO title,” “meta description,” or “social image.” The site may store those values in protected plugin-specific meta keys. The adapter needs to register only the keys the workflow needs, enforce the WordPress capability check, and translate the friendly MCP input into that narrow shape.

The same issue appears with event plugins, custom fields, membership systems, donation platforms, and editorial workflows. A generic update_post tool either exposes too little to finish the job or too much to be comfortable.

The safer pattern is:

1. Start with one recurring job.

2. Map the exact WordPress and plugin fields it needs.

3. Make consequential states explicit.

4. Enforce invariants on the server.

5. Read the result back before reporting success.

The agent can still be flexible in conversation. The server should be boringly strict.

The useful workflow often extends beyond WordPress

MCP is the interface an agent uses. It does not require every downstream service to ship its own MCP server.

Jotform is a good example. Its REST API supports forms, submissions, and webhooks using an API key. A WordPress RSVP workflow can call Jotform through an ordinary server-side adapter, return a stable form object, and then attach that form to the WordPress event.

From the user's perspective, it is one job:

Create the RSVP form, create the hidden event draft, find a suitable image, apply the SEO fields, connect everything, and show me the final status.

Underneath, the MCP server coordinates two providers with different authentication and data models. The skill or prompt teaches the sequence and handles ambiguity. The server owns credentials, validation, and policy.

That division is useful well beyond forms. The same server can coordinate a DAM, CRM, analytics service, approval system, or internal API whether or not any of them advertise an MCP endpoint.

What production readiness actually includes

The code for a few tools is only part of the engagement.

A production WordPress MCP server needs:

• a written tool and permission map

• an identity policy and clean-profile login test

• narrow WordPress and provider credentials

• explicit draft, publish, delete, and update behavior

• plugin and custom-field mapping

• structured logs that avoid sensitive payloads

• repeatable tests for policy and provider response changes

• dependency and protocol maintenance

• an operator handoff for access, revocation, and incident response

That is also why maintenance matters. WordPress plugins change fields. Provider APIs change responses. MCP clients and SDKs move. Cloudflare's current Agents integration and the MCP specification will not remain frozen around the first deploy.

The goal is not to turn a small integration into a platform program. It is to keep a consequential interface small, legible, and maintained.

The implication for marketing and IT teams

If the only requirement is broad access to standard WordPress content, start with the first-party options. They may be enough.

If the requirement is a specific operating recipe across custom WordPress behavior and other services, design that workflow before choosing tools. Decide who can act, what must remain a draft, which fields are allowed, where credentials live, and what evidence proves the work completed.

Then expose the smallest MCP surface that can finish the job.

We now offer that first production setup as a fixed $10,000 WordPress MCP server engagement. The price is intentionally visible. This is for teams that need an identity-aware, policy-bound integration—not a quick experiment with a generic plugin.