How to Test a WordPress MCP Connection
Test WordPress MCP from authentication and tool discovery to a known page read, a staging edit and saved-state verification. Keep each result distinct.
Test a WordPress MCP connection by checking authentication and protocol compatibility, discovering the available tools, reading a known record and completing one approved staging edit. Verify the saved record after the write. Each step proves something different; a reachable URL or an accepted agent job does not establish that the whole workflow works.
For Niwa MCP for WordPress, use the endpoint and client configuration displayed in WordPress → Niwa AI → Niwa MCP. Test the route your assistant will actually use.
Define the expected result before starting
Prepare a staging draft with a known page ID, status and short passage. Record its current values. Choose one reversible edit, such as replacing that passage with owner-approved text while preserving the other blocks and draft status.
Also record the site URL, Niwa version, client version and test time. Keep the credential out of the record. This baseline distinguishes a wrong-site connection from a correct connection that returned unexpected data.
A suitable acceptance record contains the expected page ID, before/after passage and final draft status. It should identify which operation was read-only and which operation was authorized to write.
Establish transport and authentication through the client
Start a fresh client session after configuring its endpoint and private credential. Inspect the client’s MCP status and sanitized errors. The site must be reachable from the environment running that client, which may differ from your browser’s network.
Niwa’s MCP endpoint accepts POST requests. Opening it in a browser sends GET and can return 405. That response is not an authentication test. A homepage returning 200 is also not a successful MCP connection.
Use a compatible client to handle the MCP transport contract. Current and supported older protocol revisions can have different lifecycle requirements. Do not combine headers from one revision with a request body intended for another.
Use a read-only protocol probe when diagnosing the HTTP layer
For a Niwa installation that supports the 2025-11-25 legacy revision, this illustrative shell request checks a small authenticated protocol operation:
curl --request POST "https://example.com/wp-json/niwa-ai/v1/mcp" --header "Authorization: Bearer ${NIWA_MCP_TOKEN}" --header "Content-Type: application/json" --header "Accept: application/json, text/event-stream" --header "MCP-Protocol-Version: 2025-11-25" --data '{"jsonrpc":"2.0","id":1,"method":"ping","params":{}}'
Replace the URL and supply the token privately in the shell environment. This example follows Niwa’s supported legacy request contract; it is not a template for every MCP server or the current stateless revision. Use the client’s normal protocol handling for the full test.
A successful ping establishes that this request was accepted. It does not load a product, authorize a page edit or prove that Niwa’s model-dependent agent can complete a task. Do not include verbose credential-bearing request headers in shared logs.
Discover tools and read the known page
Request tool discovery in the client. Confirm that the required reader exists and inspect its argument schema. With Niwa, call get_page using the exact page_id from the baseline.
Compare the returned page ID, content and status with WordPress. Check that the result is useful data rather than an error inside an otherwise successful HTTP response. The MCP tools specification distinguishes protocol errors from tool-execution errors.
If discovery succeeds but the page read fails, investigate the reader’s schema, target and returned error. Replacing a valid token will not necessarily resolve an incorrect page ID.
Run the approved staging edit once
Ask the assistant to prepare the proposed change without invoking a writer. Review the exact target, replacement and fields. Then authorize the single staging edit.
For a page-content replacement, preserve the complete existing block content around the changed passage. An update operation can replace the full body. Check the WordPress preview after saving, including the visible builder element when relevant.
Read the same record again. Compare the approved passage and final status. For a product test, retrieve the same product or variation ID and check the precise field instead.
Distinguish queued work from completion
Niwa’s whole-task route can return a job ID before the task finishes. Retrieve that job through niwa_agent_result, respecting the returned polling guidance, then inspect the affected WordPress record.
A configured agent reported by niwa_status is not proof of provider health. A completed job message should agree with saved state. If a timeout occurs, inspect the existing job or record before resubmitting a write.
Save a compact acceptance result
Record which checks passed, the stable record or job IDs, the final values and any unresolved failure. A test that reached discovery but never performed a read is incomplete for a page-management workflow.
The standalone Niwa plugin supports connecting an existing WordPress site. Ask Niwa to verify your intended MCP task with your client and a staging record. The Niwa setup guide covers endpoint and credential settings.
