How to Connect WordPress to an AI Assistant with MCP
Connect an AI assistant to WordPress with Niwa MCP. Choose the correct endpoint and authentication, discover tools and verify a small approved task.
To connect WordPress to an AI assistant with MCP, install a supported server or connector on the site, give your client the correct endpoint and authentication, then verify tool discovery and a known reading task. With Niwa, use the endpoint and client examples in WordPress → Niwa AI → Niwa MCP.
The connection should end with evidence that your assistant read the intended website. Saving a configuration file or seeing the homepage in a browser is not enough. Niwa MCP provides the WordPress operations; your external client decides how to request them.
Choose one connection route before configuring anything
Start by identifying the connector already installed. Niwa’s endpoint normally has the form https://example.com/wp-json/niwa-ai/v1/mcp, with a Niwa bearer token. Copy the displayed URL rather than constructing one from memory, especially on subdirectory installations.
The official WordPress MCP Adapter is a different route. It exposes registered abilities and has its own endpoint and authentication configuration. Its Application Password examples cannot be substituted for a Niwa token. Likewise, a WooCommerce connector does not become Niwa simply because both speak MCP.
Record the connector name, website environment and client version. These three facts make later troubleshooting much easier. If you still need to evaluate the route, read the WordPress MCP server comparison before continuing.
Prepare the site and the client
For a remote Niwa connection, the site needs HTTPS and must be reachable from the machine running your assistant. Confirm that WordPress, Niwa and the relevant business plugin are active. Product operations require the appropriate WooCommerce environment.
Use a staging site for your first write. Prepare a known draft page and note its ID, status and opening paragraph. That gives you a test with a result you can recognize without exposing customer records.
Choose a client that supports the endpoint’s HTTP transport and authentication. A local client and a cloud connector may originate from different networks. A URL accessible on your laptop might still be unreachable from the cloud.
Generate a credential for the intended connection
Open Niwa AI → Niwa MCP as the site administrator. Copy the server URL and generate a token with a suitable expiry. Keep the token in private client configuration or the supported credential mechanism for your client.
Niwa MCP tokens grant administrator access. The optional WordPress-options scope is not a general read-only mode. Avoid putting live tokens in screenshots, shared documents or committed configuration files. A distinct test credential makes it easier to revoke this connection when testing ends.
The Niwa installation and access guide covers the site’s settings. Signing Niwa into an AI account is a separate connection from authorizing your external MCP client.
Add the endpoint using the client’s configuration
For Claude Code, register a remote HTTP server with the bearer header using the example Niwa displays. For Codex, add an mcp_servers entry to the applicable private config.toml, with the URL and supported bearer-token configuration.
Do not paste a JSON configuration from one client into another client’s TOML file. The endpoint and token represent the same server, but configuration syntax is client-specific. Refer to the current Claude Code MCP documentation or Codex MCP documentation for the client you actually run.
Restart or refresh that client as its setup requires. If credentials come from an environment variable, the running process must have that variable. Setting it in a different terminal does not update an already running application.
Establish discovery and a known read
Check the client’s MCP connection status and request the available tools. Inspect each relevant schema instead of inventing an operation name from the task description.
With Niwa, niwa_status describes whether the configured Niwa agent route is available. Direct tools can handle deterministic WordPress reads even when Niwa’s own model connection is absent; provider-dependent generation needs its relevant connection.
Ask the client to read your known draft page with get_page and its exact page_id. Check the returned content against WordPress. This establishes authentication, tool availability and access to the correct record.
Authorize a small change and check it independently
First ask for a proposed replacement without calling a write tool. Review the page ID, current content, new content and intended status. Then authorize that exact write on the staging draft.
The assistant should retrieve the same page after saving. Check that the text changed, the page remains draft and unrelated fields remain as intended. A direct write-tool call can execute the change; MCP does not guarantee an extra confirmation dialog between call and save.
If the request times out, inspect the page before repeating it. The write may have succeeded even when the client did not receive the response. For queued Niwa agent work, use the returned job handle rather than submitting another task.
Finish with a connection record
Keep a short private record of the site, connector version, client version, tested page ID, expected result and token expiry. Record how to disable the client connection and revoke its credential.
For an existing WordPress website, the standalone Niwa plugin is available without commissioning a new site. Contact Niwa about your connection with the client name and one task you want verified. Send error details with secrets removed if the connection stops before discovery or the first read.