WordPress MCP Client Configuration: Transport and Auth
WordPress MCP client configuration by client type: native OAuth, the mcp-remote bridge or hosted HTTPS, where each config lives, and how to verify it.
Every MCP client asks for the same three things in a different shape: where the server is, how to authenticate, and what the connection is called. The differences between clients are almost entirely about where that configuration lives, whether it is a file you edit, a settings screen, or a browser flow. The Connect screen generates the right shape for the client you pick, so the part worth your attention is the credential you attach to it rather than the syntax around it.
What you will do 6 steps
Choose a client
Select authentication
Generate the site-specific config
Install the config
Authorize
Verify discovery
Choose the work surface
Use a conversational client for research and editorial tasks, a terminal client for repository-aware implementation, or an AI IDE for code and site work in one place. GoBuildWP publishes individual setup pages for every current client in its public registry.
Google moved individual Gemini CLI users to Antigravity CLI in June 2026. New public guides should use Antigravity CLI or Antigravity IDE; legacy Gemini CLI remains an enterprise or paid API-key exception.
Choose authentication
OAuth 2.1 with PKCE gives supported clients a browser authorization path. Application Passwords are WordPress credentials that can be created, named, rotated, and revoked for a dedicated connection. Access tokens, created on the Connect screen, suit callers with no browser at all, such as an API connector, a script or a cron job. From GoBuildWP 1.15.0 a token can be given an expiry, limited to chosen abilities or categories, and capped at a safety profile below the site's; anything outside its scope is refused and hidden from it, and its changes carry its name in the change log. Client support and deployment shape determine which route is simplest.
Use public HTTPS for clients that must reach the site from the web. A cloud-hosted client cannot connect to localhost. Never publish a bearer token, application password, or generated bundle containing credentials.
- Dedicated identity
- Smallest useful WordPress role
- Read Only for first connection
- Credential stored outside source control
- A revocation plan
The local route: WP-CLI over stdio
A client that runs on the machine or in the container that runs WordPress can skip the network and the credential. wp wppilot mcp serve --user=<login> serves the same MCP server as /wp-json/mcp/wppilot, but over standard input and output: the client starts WP-CLI as a child process, and WP-CLI runs as the WordPress user --user names. The abilities, safety profile, confirmations and per-ability permission checks are the ones HTTP gets, and each process is one agent session on the Changes screen, so supported ledgered writes can be grouped for recovery. Unsupported or conflicting items can prevent a session undo; inspect its plan first.
The Connect screen shows it as a collapsed panel, Local connection over WP-CLI, below the three connection steps. It prints a claude mcp add gobuildwp-local -- wp --path=<site directory> wppilot mcp serve --user=<your login> command for Claude Code, a matching mcpServers block with command wp for Cursor's .cursor/mcp.json or any client that launches a command, and a one-line initialize request piped into the same command for a script or CI job. The path and login are filled in from the install you are looking at.
The limits follow from how it works. The client must run where wp and the WordPress files are, so it reaches neither a remote host nor a hosted client such as ChatGPT. The command refuses to start without --user, or while AI abilities are switched off, or when a site has disabled stdio through the mcp_adapter_enable_stdio_transport or wppilot_stdio_enabled filter. For WordPress in Docker, put docker exec -i and the container name before wp. One process serves the whole client session, so restart the client after switching abilities on or off.
- The client runs on the WordPress host or inside its container
- wp is on the client's PATH
- --user names a dedicated, least-privilege login
- --path points at the site's directory
- The client restarts after abilities change
MCP Tasks and background execution
MCP Tasks shipped in Free 1.15.0 on the modern transport. When enabled and tools are served, discovery advertises Tasks. Task-capable, job-backed abilities can run in the background; other abilities return an already completed or failed task. Authenticated clients can poll, retrieve results, list their tasks and request cancellation. Cancellation does not undo completed writes. The connected user's permissions, safety profile and confirmation checks still apply.
Tasks is enabled by default and can be disabled through the wppilot_mcp_tasks_enabled filter. On the modern transport, add task: {} to tools/call parameters, then use tasks/get, tasks/result, tasks/list and tasks/cancel. Tasks are scoped to the connected user. Job progress depends on the runner and WordPress cron; Tasks does not support input_required pauses. The legacy adapter does not provide this extension.
Prove the entire path
A connected indicator is only the start. Confirm that the client can initialize, discover tools, inspect a schema, execute a permitted read, and receive a structured response. Then verify that a forbidden action is actually refused.
If setup fails, record the client version, configuration location, transport, endpoint, HTTP status, and exact error. Diagnose one layer at a time rather than regenerating credentials repeatedly.
Native HTTP, local bridges and hosted connections
Only clients that need the bridge run OAuth through mcp-remote. In the current registry that is Roo Code.
The client runs the OAuth 2.1 flow itself against your site. An Application Password or access token is the alternative where the client lists it.
Hosted clients connect from their provider's servers and need publicly reachable HTTPS. Localhost and private networks are out of reach on this route. Use the authentication method listed for the specific client.
| Client | How it reaches the site | Configuration goes in |
|---|---|---|
| Claude Code | Native OAuth | A single terminal command |
| Claude Desktop | Native OAuth | mcpServers JSON, added through the app's own MCP settings |
| Codex desktop app | Native OAuth | Settings from the account menu, then add GoBuildWP as a remote MCP server |
| Codex CLI | Native OAuth | ~/.codex/config.toml |
| Cursor | Native OAuth | ~/.cursor/mcp.json |
| VS Code | Native OAuth | .vscode/mcp.json |
| Factory Droid | Native OAuth | ~/.factory/mcp.json |
| Kimi Code CLI | Native OAuth | ~/.kimi-code/mcp.json |
| Qwen Code | Native OAuth | ~/.qwen/settings.json |
| ZCode (GLM) | Native OAuth | The ZCode MCP server manager: HTTP for OAuth or a token, stdio for the Application Password bridge |
| GitHub Copilot | Native OAuth | ~/.copilot/mcp-config.json |
| Antigravity CLI | Native OAuth | ~/.gemini/config/mcp_config.json |
| Antigravity IDE | Native OAuth | ~/.gemini/config/mcp_config.json |
| Devin Desktop | Native OAuth | ~/.config/devin/mcp_config.json |
| Zed | Native OAuth | ~/.config/zed/settings.json |
| Cline | Native OAuth | Cline sidebar, MCP Servers, Configure MCP Servers |
| OpenClaw | Native OAuth | ~/.openclaw/openclaw.json |
| Kilo Code | Native OAuth | ~/.config/kilo/kilo.jsonc |
| Amazon Q | Native OAuth | ~/.kiro/settings/mcp.json |
| OpenCode | Native OAuth | opencode.json |
| Roo Code | OAuth via mcp-remote | .roo/mcp.json |
| Claude on the web | Hosted, public HTTPS | Customize, then Connectors, then Add custom connector |
| ChatGPT | Hosted, public HTTPS | ChatGPT Plugins, plus button, Create custom MCP server |
| Mistral Le Chat | Hosted, public HTTPS | Connectors, Add Connector, Custom MCP Connector |
| Manus | Hosted, public HTTPS | Settings, Connectors, Add connectors, Custom MCP, Direct configuration |
| Perplexity | Hosted, public HTTPS | Settings, then Connectors |
Reading the generated configuration before you paste it
Notices on Connect a client that change what you paste
Step 2 of Connect a client is a set of client tabs, and each tab produces the shape that client expects: a one-click install, a command to run in your terminal, a block for a configuration file with a choice of global or project scope, or a set of form fields for a web app. Above the snippet, Change server name (optional) renames the entry. Rename it after the site, not after GoBuildWP, if the client will ever hold more than one WordPress server, so the agent and you can tell them apart.
Three notices on that screen change what the snippet means, and each is easy to scroll past.
- These snippets are not ready to use yet: no Application Password or access token has been created, so the snippet contains a placeholder. Pasted as it is, the client appears to connect and then fails every call. Create the credential in Step 1 first; the snippets fill themselves in.
- None of these can reach this site, under Web apps: the site is on a local address, and web apps connect from their own servers, so they need a public HTTPS URL. Use OAuth or an access token with a client running on the same machine, or move the site somewhere reachable.
- Local HTTPS detected: the certificate is not publicly trusted, which is normal in local development, so the bridge configuration turns off TLS certificate verification for the whole npx process. Only use that on a network you trust, and never copy that configuration to a production site.
WordPress MCP client configuration for more than one site
Each WordPress site is a separate server entry with its own endpoint and its own credential. A client can hold several, and the entry name is the only thing that distinguishes them in the agent's tool list, so generate each entry on its own site's Connect a client screen and give each a site-specific name. Copying one site's entry and editing the URL leaves the first site's credential in the second entry, which fails or, worse, authenticates against the wrong site if the same user exists on both.
When the list of sites grows past a handful, the per-site entries become the work. That is the case GoBuildWP Cloud is for: each site connects to a Cloud account once, and every AI app uses one Cloud link. It is optional; a direct entry per site has no relay in between and keeps working without an account.
Questions this guide answers
I changed the safety profile and the agent still lists the old tools. Why?
Clients cache the tool list they were given when the session opened. Restart the client session before concluding the change did not apply; then compare discovery with the current site policy.
Should I use OAuth or an Application Password?
OAuth wherever the client supports it: the client never stores a WordPress password, tokens expire on their own, and a single client can be revoked without disturbing anything else. Use an Application Password when the client cannot run a browser flow, when the site is not reachable over public HTTPS, or when scripting from a non-interactive environment.
How do I prove the connection actually works?
Check all four layers in one pass: the endpoint resolves, the credential authenticates, discovery returns a tool list, and the WordPress user has the capability for what you asked. When something breaks later, you already know which of the four to look at.
Review noteRequirements and credential methods follow the shipped GoBuildWP source (WordPress 6.9+, PHP 8.0+). Client menus, account plans and third-party behaviour can change; use the installed version and live schema. Our evidence standard.