05 — Diagnose a Site

Walkthrough

When something feels off with a WordPress site — a tool returns E_UPSTREAM errors, pages don’t show up, the wrong builder is being called — diagnose_site is the first stop. It runs six checks against the WP REST API in parallel and returns a structured report.

Y

You

Something’s not right with viper-template. Run diagnose_site and tell me what’s broken.

Claude

diagnose_site

Here’s the report for viper-template:

• ✅ WordPress REST — authenticated as Product Support. The app password is valid.
• ✅ Elementor — installed and active.
• ✅ functions.php snippet — applied. _elementor_data is exposed via REST, which means the Elementor template-duplicate workflow works.
• ✅ wp-mcp-adapter — installed. Proxy tool surface is available.
• ✅ msrbuilds/elementor-mcp — installed. The 74 widget-level tools (elementor-mcp-add-section, elementor-mcp-update-element, etc.) are discoverable.
• ❌ seo-navigator-code-page plugin — NOT installed.

The only issue is the code-page plugin. That’s only needed for create_page_from_code (the vibe-code workflow); everything else works.

Suggested action: Install the seo-navigator-code-page plugin from wp-plugins/seo-navigator-code-page/ in the worker repo. After that, the diagnose check will flip green and create_page_from_code will work.

What each check actually does

Check	How it’s verified
WordPress REST	GET /wp/v2/users/me with the configured app password. Catches expired/revoked passwords, REST disabled, WAF blocks
Elementor	Probes the discovery namespace /wp-json/elementor/v\d+. Catches plugins disabled or uninstalled
functions.php snippet	Reads one Elementor template via REST and checks that the _elementor_data meta field is exposed (the snippet register_rest_field is what exposes it). Without the snippet, the template-duplicate workflow throws cryptic empty-payload errors
wp-mcp-adapter	Probes the discovery routes for /mcp/mcp-adapter-default-server. Catches plugin installed but inactive
msrbuilds/elementor-mcp	Same idea — probes /mcp/elementor-mcp-server. Together with the adapter check, this tells you whether proxy tools will work
seo-navigator-code-page	Probes /wp-json/sn-cc/v1/status — the plugin’s own diagnostic endpoint. If the plugin is missing, this returns 404 and the check fails

When checks fail

The most common failures and what they mean:

• WordPress REST: 401 Unauthorized — app password is wrong, expired, or the site’s .htaccess is stripping the Authorization header. Fix: rotate the app password in wp-admin → Users → Profile, paste it into the worker admin /admin/sites → Set app pass.
• Elementor: not installed — the plugin is deactivated or the version is too old (< v3). Fix: activate / upgrade.
• functions.php snippet: applied=false — paste the snippet from setup docs into the active theme’s functions.php. Required only for Elementor template-duplicate.
• mcp_adapter / elementor_mcp: not installed — install the WP plugins if you want the proxy tool surface. Optional otherwise.
• code_page_plugin: not installed — only needed for create_page_from_code. Skip if you don’t use vibe-code pages.

Server-side log

The audit row records the diagnose call but not the result body (would be too noisy). Open the row to see status + duration:

A slow diagnose (>3 seconds) usually means one of the REST probes timed out — that’s almost always the WordPress site itself being slow, not the worker.

Goal

Show the diagnose_site tool’s full output and explain how to read each of the five probes. This is the tool support engineers will reach for when something else fails.

Prerequisites

• Connector working (scenario 01).
• A WordPress site that has at least three of the five probes in the OK state. A site with one failing probe is even better — it makes the demo more useful.

Setup state

• Claude Desktop on a fresh conversation.
• An admin dashboard tab open on the Sites page so the viewer can correlate mcp_backend and available_builders settings with the report.

Steps

1. Action: In the composer, type:

   Run a diagnose on acme-blog and explain each result.

   Press Enter. Expected: Claude calls diagnose_site with site_id="acme-blog". The card resolves and the response payload contains the five probes:

   • wp_rest
   • elementor
   • functions_snippet
   • mcp_adapter
   • code_page_plugin Recorder: capture the JSON expanded; pause two seconds so viewers can read it.

2. Action: Wait for Claude’s prose summary. Expected: Claude lists each probe with a green check or red cross and one sentence of explanation per row. Failing probes carry a remediation hint (e.g. “Install the seo-navigator-code-page plugin from wp-plugins/ in the repo.”). Recorder: scroll slowly through the summary block.

3. Action: If any probe is red, switch to the admin dashboard Sites page and click the failing site. Expected: The settings panel shows the relevant field (e.g. MCP backend dropdown, or Available builders checkboxes) that drives the probe. Recorder: highlight the field with a callout matching the probe name.

4. Action (optional, only if a probe is red and easy to fix): Toggle the setting that fixes the probe (or install the missing plugin in another tab), then re-run the diagnose:

   Diagnose acme-blog again.

   Expected: The previously red probe is now green. Claude confirms the fix. Recorder: do a side-by-side of the before/after JSON if you can fit it.

Verification

• Admin Audit log shows tools/call diagnose_site with ok status and the probe results in the payload.

Rollback / cleanup

• Revert any site setting changes you made for the demo, if they would mislead other tests.

Edge cases to capture in the recording

• Site totally unreachable: every probe returns unreachable. Show Claude advising to check the WP host is online before continuing.
• Elementor inactive but available_builders includes “elementor”: show how the report flags this mismatch.
• code_page_plugin not installed: show the remediation hint pointing at wp-plugins/seo-navigator-code-page/.