WordPress MCP tools not showing in your AI client

Symptom: the client lists nothing from GoBuildWP

WordPress MCP tools not showing? Before enabling anything, name the expected tool, the intended operation and the authority it should have. Missing tools can arise from server registration/policy, route or edge behavior, or a stale client list; Diagnostics provides server-side clues rather than a conclusive client diagnosis. Open GoBuildWP > Diagnostics, choose your method under "How do you connect?" and press "Run diagnostics". When results appear, the "What do you see in your AI client?" list offers "The client connects but shows no GoBuildWP tools", which opens the guidance for this case. Then read these rows.

Cause, AI Abilities off: "AI Abilities are turned off, so no MCP endpoint exists and every client sees an empty or missing server." Go to GoBuildWP > Connect a client, tick "Turn on AI Abilities for this site" and press "Save Settings".

Cause, the domain changed: AI Abilities are locked to the hostname they were enabled on, so after a migration, a clone to staging or a switch between www and the bare domain, every ability goes dark and nothing the client receives mentions the domain. wp-admin does: "GoBuildWP AI Abilities were disabled because the site domain changed (enabled on …). Re-enable them from the Connect page if this is intentional." Re-enable on the new hostname only if this copy should really be reachable.

Cause, adapter not loaded: the MCP endpoint row says "WordPress answered, but the MCP route is not registered." With AI Abilities on, inspect the exact endpoint and negotiated route, release packaging, server registration, cache/CDN/WAF behavior and response body. Adapter packaging is one possibility on the legacy route; a generic route result does not conclusively identify it.

Cause, client side: if every row passes, check the client. The OAuth URL and the Application Password URL are different endpoints; make sure it uses the exact server URL from Connect a client, then restart it.

Symptom: every request comes back 401

Tools cannot appear if each request is rejected. The Connection Doctor section on the same Diagnostics screen ("Run Connection Doctor") sends a few requests from the site to itself and reports signals that may identify a cause: a CDN or firewall answering instead of WordPress, a web server that drops the Authorization header, an OAuth challenge a proxy strips, or a server clock that spoils sign-in. Review each finding against the actual request and edge configuration before changing controls; loopback diagnostics do not establish the remote client path.

For the Application Password method, the Application Passwords check names Wordfence when it is the cause: "Wordfence has switched Application Passwords off". Its fix is Wordfence > Firewall > All Firewall Options > Brute Force Protection, clear "Disable WordPress application passwords", and save. Connecting with OAuth or a GoBuildWP access token avoids Application Passwords altogether.

Symptom: most tools are there, one is not

Open GoBuildWP > Abilities. The blue box at the top states the "Active safety profile" and what it allows, and each ability carries one of three states.

Disabled: someone switched it off on this screen. Switched-off abilities vanish from discovery and cannot run. Press "Enable" on its row, or tick several and use "Bulk actions" > "Enable" > "Apply". A client calling it by name gets "The ability "…" is switched off in the GoBuildWP Abilities screen." or "Ability '…' exists but is switched off in GoBuildWP's AI Abilities settings."

Blocked by profile: the ability is enabled, but the site's safety profile forbids it. Read Only allows discovery and inspection only. Production Safe allows normal content, design, SEO, form and commerce work while blocking raw code, server files, WP-CLI and temporary administrator access. Current clients leave a blocked ability out of the tool list entirely; a call by name returns "Ability "…" is blocked by the … safety profile." Change the Safety profile under Connect a client only if that access is intended; choosing Developer Full Access asks for a second confirmation.

Enabled, yet refused: the limit may sit on the credential rather than the site. "…the access token behind this request is capped at the … safety profile" and "The access token "…" is not allowed to use "…"" both mean the token was created with a narrower ceiling or scope. Those messages mention a Configuration screen; tokens are listed and managed under GoBuildWP > Connect a client.

Symptom: a Pro integration never shows up

Pro eligibility follows the Freemius premium-code gate; inspect the activation/licensing state and integration-health result rather than treating one notice as a complete diagnostic. Licensed, Pro detects which supported plugins and themes are installed and loads abilities only for those, so an integration for a plugin that is inactive, or older than the version Pro supports, is absent by design.

Ask the agent to run the Integration Health ability (wppilot/integration-health). For every Pro integration it reports two separate facts: whether its category is active and whether its loader is eligible to run. A plugin present but below its version floor, or held by the licence gate, shows as active and not eligible rather than simply missing. An integration whose loading failed is listed under recorded_failures, and the overall status reads degraded until it loads cleanly again.

Symptom: the tool exists but the call stops

Some refusals look like absence to an agent but are working as designed. "Ability "…" is destructive or critical. Obtain explicit user approval, then retry with confirm=true inside the ability parameters." means the call needs your go-ahead. "Rate limit reached: this credential may run … write calls per minute." gives the wait in seconds; read-only abilities are not limited. Neither should be worked around with a raw database or file write: the plugin-aware ability exists so the change is validated and recorded.

Not a symptom: a short list on an older client

How GoBuildWP appears depends on which MCP revision your client speaks. A current client lists every ability it is allowed to call as its own tool, with the slashes and hyphens in the ability name turned into underscores, so wppilot/connection-doctor becomes wppilot_connection_doctor. An older client sees three GoBuildWP tools, discover-abilities, get-ability-info and execute-ability, and reaches every ability through them. On an older client a three-item list is normal: ask the agent to run discover-abilities before concluding anything is gone.

GoBuildWP does not send list-changed notifications. After you change anything in wp-admin, restart or reconnect the client so it fetches the list again; a client left running keeps showing what it saw at connection time.

Symptom: tools vanished right after an update

If the list was complete yesterday and shorter after updating, check the order and the versions before anything else. Each Pro build requires a minimum Free version; when Free is older than that, Pro loads nothing and wp-admin says "GoBuildWP Pro needs GoBuildWP … or newer." Every Pro ability disappears from the client at once, which looks like a connection fault but is not. Update Free, then Pro, then reconnect the client.

Updating a companion plugin can have the opposite effect on a single integration. Pro checks some builders and field plugins against a minimum version and, for at least one, a maximum; a plugin outside that range is skipped by design. The Integration Health ability reports it as active and not eligible, which is the cue to check the integration page for the supported range rather than to reinstall GoBuildWP.

Symptom: a local stdio client shows the wrong server

A client that launches WP-CLI on the same machine instead of connecting over HTTP can end up talking to a different MCP server on the same site. The MCP Adapter's own command, wp mcp-adapter serve, serves the first server registered, and when Elementor's MCP server is also installed that can be Elementor's rather than GoBuildWP's, so the tool list is someone else's.

Use wp wppilot mcp serve instead. It picks GoBuildWP's server by default, refuses to start without WP-CLI's global --user parameter, and applies the same safety profile, confirmation and rate-limit checks as the HTTP endpoint. If tools are still missing on stdio, the causes in the sections above apply unchanged, except that sign-in problems cannot be the reason: there is no credential, only the WordPress user you named.

Evidence worth capturing

The client's name and version, the tool or ability name it expected, the exact text of any refusal, and the state the Abilities screen shows for that ability. On Diagnostics, "Copy report for support" turns the last run into plain text you can paste; it carries versions and check results, but review and redact even generated reports before sending them.