/wp-json/pom-ai-mcp/v1/status: MCP status endpoint
A public, unauthenticated summary of the server's configuration. It is the fastest way to confirm the server is alive and to see what a client will find.
https://example.com/wp-json/pom-ai-mcp/v1/status
GET only. Open it in a browser.
What it reports
| Field | Meaning |
|---|---|
active |
The server is running |
mcp_endpoint |
The canonical MCP URL clients should use |
oauth_enabled |
Whether OAuth authentication is accepted |
api_key_enabled |
Whether API key authentication is accepted |
api_key_active |
Whether an API key currently exists |
pom_theme |
Whether the POM theme was detected, with the active stylesheet, template and version |
woocommerce_detected |
Whether WooCommerce is active |
permalinks_enabled |
Whether pretty permalinks are configured |
pom_ai_version |
The installed POM AI version |
capabilities |
Which write gates are open, plus resources, prompts and authoring context |
protocol_versions |
The MCP protocol versions supported |
The field that matters most
capabilities tells you which of the four write gates are open:
content_writes, option_writes, pom_theme_writes, woocommerce_writes
All four should read false unless you deliberately opened one for a task. This endpoint is the quickest audit of that — quicker than opening the settings screen, and checkable from outside.
If a gate you thought you closed reads true, close it. See Enabling writes.
The field that explains a broken connection
permalinks_enabled reading false means the discovery and OAuth endpoints are returning 404 while this endpoint keeps answering — the combination that makes a failed connection hardest to attribute.
Fix it under Settings → Permalinks by choosing any structure other than plain. The MCP settings panel also shows a warning while this is the case.
It is public on purpose
No authentication is required, which is deliberate: a client needs to know whether a server exists and which protocol versions it speaks before it can authenticate.
Nothing sensitive is exposed. It reports whether an API key exists, never the key; whether OAuth is enabled, never a token; which products are installed, never their data.
If you would rather not publish even that, disable the POM AI MCP tool when it is not in use — the endpoint disappears with it.
Using it to diagnose
| What you see | Means |
|---|---|
| JSON | The server is running and the REST API is reachable |
| A 404 | The MCP tool is disabled, or the REST API is blocked |
| HTML | Something upstream intercepted the request — a security plugin, WAF or maintenance page |
woocommerce_detected: false on a shop |
You are on the wrong site, or WooCommerce is inactive |
pom_theme.detected: false |
The POM theme is not the active theme here |
| Missing protocol version | The client and server disagree on protocol support |
The HTML case is worth dwelling on: it means requests are not reaching WordPress intact, which will break the whole MCP flow regardless of credentials.
Caching
The response carries Cache-Control: no-store. If a CDN caches it anyway, you will see stale gate states and stale product detection — which is exactly the information you consult it for. Exclude the MCP paths from caching. See MCP requirements.
In a health check
Because it is public, stable and cheap, it works as a monitoring probe. Reasonable assertions:
- the response is JSON;
activeis true;- the four write gates match your intended configuration;
pom_ai_versionmatches what you deployed.
The gate assertion is the valuable one. It catches a gate left open after a task, which is the most likely configuration drift on a site using MCP.
Related
- Find the MCP server URL
- Check the server status for the richer, authenticated diagnostics
- The MCP endpoint