Look at how your client adds an MCP server. If its configuration accepts a server URL and custom headers, connect directly. If it accepts a command to run, use the bridge. Both end at the same endpoint with the same credential, so the plugin does not care which you choose.
Route 1: URL plus header
Endpoint: https://your-site.com/wp-json/wp-visibility/mcp
Header: Authorization: Basic followed by the base64 of username:application-password
WordPress accepts Application Passwords as HTTP Basic auth over HTTPS (REST API handbook, checked September 27, 2026).
The endpoint answers JSON-RPC over HTTP POST, one message per request, with no sessions and no server-sent events. A client that insists on an SSE stream cannot use it directly; if that client can run a command, use the bridge. This describes the plugin’s built-in endpoint; when the official MCP Adapter plugin is active, it serves the same route with its own transport.
In the common JSON shape clients use for HTTP servers, the entry looks like this. Check your client’s documentation for its exact field names.
{
"mcpServers": {
"wpvisibility": {
"url": "https://your-site.com/wp-json/wp-visibility/mcp",
"headers": {
"Authorization": "Basic c2VvLWFnZW50Onh4eHgg..."
}
}
}
}
Route 2: the bridge
@automattic/mcp-wordpress-remote is a small program that runs on your computer, holds the credential, and relays between the client and the site. Its README lists Node.js 22 or newer as a requirement (checked September 27, 2026). The plugin prints a starting block:
wp visibility mcp-config --user=seo-agent
The printed block sets WP_API_URL to your site’s home address. Replace it with the full endpoint (the last line of the command’s output prints that address), so the entry reads:
{
"mcpServers": {
"your-site-com": {
"command": "npx",
"args": ["-y", "@automattic/mcp-wordpress-remote@latest"],
"env": {
"WP_API_URL": "https://your-site.com/wp-json/wp-visibility/mcp",
"WP_API_USERNAME": "seo-agent",
"WP_API_PASSWORD": "<application password>"
}
}
}
}
WP_API_URL must be the full endpoint address. The bridge treats a bare site address as the older, deprecated wordpress-mcp plugin and looks for a route this plugin does not provide (README, checked September 27, 2026).
Which clients take which route
- Claude Code: route 1, one command.
- Claude Desktop: route 2, one config block.
- Cursor, VS Code with Copilot and Zed: each documents both a URL with headers and a command. Prefer route 1. For another editor, look for a headers field in its MCP settings.
- ChatGPT: neither, as of September 27, 2026. Why.
- A client that only offers OAuth: not supported by the plugin’s endpoint.
Sources, checked September 27, 2026: Claude Code MCP docs (the --header flag), Claude custom connectors (remote connectors take OAuth credentials; local servers go in claude_desktop_config.json), Cursor, VS Code, Zed, and ChatGPT developer mode (OAuth, no authentication or a mix of the two, over SSE or streaming HTTP).
Before the first request
The Assistant connection module must be on (WP Visibility → Settings → Modules). Turn on Autopilot and keep Assistant changes on Hold for my review so the assistant’s SEO, redirect and settings changes wait in the queue. Draft writes, imports and IndexNow submissions are not held. Then ask for a read, then for one change, and confirm the proposal appears in WP Visibility → Review queue before you ask for anything in bulk.
Several sites
Each site gets its own entry and its own Application Password. Name each password after the client that uses it: the activity log records that name with every action, and revoking one site’s password leaves the others working.