WPPilot is a self-hosted WordPress MCP plugin. The Free version provides the MCP endpoints, OAuth and Application Password options, safety profiles, preview-before-write, a change ledger, and the core abilities needed for WordPress administration. Your site remains the server; there is no WPPilot relay or hosted chatbot in the request path.
Pro adds plugin modules and an approval queue, including integrations for areas such as page builders, WooCommerce, and SEO tools. Those additions do not change the basic debugging rule: establish reliable HTTPS reachability first, then authorize only what the connected user and safety profile should allow.
If curl returns a CDN challenge or HTML, fix the proxy, firewall, or cache. If curl returns JSON but OAuth loops, verify the discovery URLs, redirect URI, clock, and callback handling. If OAuth completes but no tools appear, inspect the MCP route and server registration. If tools appear but writes fail, review the safety profile and WordPress capabilities. Treat each as a separate layer instead of rotating credentials at random. The useful question is not “Why is the plugin silent?” It is “Which layer stopped the request?” Reachability, authentication, authorization, and tool execution are observable in that order. Once you keep them separate, “Couldn’t reach the MCP server” becomes a short checklist rather than a mystery.
Disclosure: I work on WPPilot, a self-hosted WordPress MCP plugin. The examples above describe its capabilities and general troubleshooting patterns; always verify the routes and client requirements for your own deployment.