What the POM AI MCP server does

The Model Context Protocol is a standard way for an AI client to discover and use tools offered by a server. POM AI MCP is that server for one WordPress site.

The shape of it

An MCP client — an AI assistant with MCP support — connects to your site's MCP endpoint and asks what it can do. Your site answers with a list of tools, each with a name, a description and an input schema. The client can then call a tool with arguments, and your site runs it and returns the result.

Everything happens on your own site. There is no POM AI service in the middle: the tools read and write your WordPress database directly, and no credits are consumed.

What it exposes

Five groups of tools, each present only when the underlying product is:

Together that is more than one hundred tools, roughly half of them read-only. The full inventory is in chapters 11 to 21.

Beyond tools, the server also publishes resources the client can read and prompts — ready-made instructions that encode the correct order of operations for common jobs. See MCP resources and Prompt recipes.

What a session looks like

1. The client discovers the server and authenticates.
2. It calls initialize and learns the protocol version and server name.
3. It calls tools/list and receives the tools it is allowed to see.
4. It calls tools/call with a tool name and arguments.
5. Your site checks the request and either runs it or refuses.

The supported JSON-RPC methods are initialize, tools/list, tools/call, resources/list, resources/read, prompts/list and prompts/get.

What makes it "controlled"

Four independent gates decide whether a call succeeds:

1. The OAuth scopes on the token.
2. The WordPress capabilities of the user the call acts as.
3. The write gate for that group of tools, which is off by default.
4. The tool's input schema, which rejects malformed arguments.

All four must permit an operation. A client holding a broad token still cannot write if the write gate is closed, and cannot exceed what its WordPress user could do by hand.

This is the single most important idea in the chapter: appearing in tools/list is not permission to run.

Site-scoped, not network-scoped

The server belongs to one site. On multisite, each site has its own endpoint, its own API key, its own OAuth clients and tokens, and its own settings. A token issued for one site is bound to that site and does not work on another.

Who it acts as

Every operation runs as a WordPress user:

• with OAuth, the user who approved the authorization;
• with an API key, the service user configured in the settings, if any.

That user's capabilities are a hard ceiling. An assistant connected as an editor cannot do administrator things, regardless of scopes.

What this is good for

• Bulk edits that would be tedious by hand — retagging, restructuring, fixing metadata across many items.
• Building pages and templates through the authoring tools, with validation before saving.
• Answering questions about the site's own state.
• Repeatable maintenance that benefits from judgement rather than a script.

What it is not

• Not an AI generation service. Nothing here calls a model or spends credits; the client is the AI.
• Not a public API. Every call authenticates, and the server is not designed for untrusted callers.
• Not a replacement for a backup or a staging environment. Writes are real and immediate.

Continue with MCP requirements, or read MCP security model if you want the controls before the setup.