IATO MCP

Changelog

1.4.10

• Fix: the JSON config snippets emitted by the plugin (setup wizard Method 3, dismissible «Ready to Connect» notice, Settings hero card) now use a unique-per-site inner mcpServers key derived from the WordPress site’s hostname (e.g. iato-garennebigby-dev, iato-dynomapper-com) instead of the hardcoded iato-wordpress. Agencies managing multiple WordPress installs from a single AI client (Claude Desktop, Claude Code, etc.) can now paste config snippets from many IATO MCP installs into the same client config file without one silently overwriting another (JSON object keys are unique, so two snippets sharing a key was a silent collision). Existing connections that were set up with the old iato-wordpress key continue to work — the inner key is a display name only, not part of any HTTP request — so no migration is needed.

1.4.9

• Docs: added the plugin demo video to the top of the Description section on the WordPress.org plugin page (auto-embedded by WordPress.org’s readme renderer when a YouTube URL is on its own line). No code changes; safe to skip if you’ve already updated to 1.4.8.

1.4.8

• New: dynamic page-builder-aware server instructions injected into the MCP initialize response. The plugin now detects which page-builder plugins are active on the WordPress site (Elementor, Divi, WPBakery, Beaver Builder, Gutenberg) and emits a context-specific instruction string telling the AI agent which write tools are correct for which builder, with a mandatory get_page_builder check-first rule before any content edit. Closes a class of silent-failure bug where update_post on an Elementor-built post would succeed at the database level but never reach the frontend (because Elementor stores content in _elementor_data, not post_content). Detected-but-unsupported builders (Divi, WPBakery, Beaver Builder for writes) are explicitly flagged so the agent tells the user to edit in the WP admin instead of attempting a write that won’t take effect. Uses the standard MCP instructions field added in spec rev 2025-03-26; older clients on 2024-11-05 cleanly ignore the unknown field.
• New: get_page_builder now detects Beaver Builder posts (via _fl_builder_enabled post meta) and returns beaver-builder. Previously these posts fell through to the gutenberg or classic branch, misleading the agent about how to handle them.

1.4.7

• Fix: Settings → IATO MCP no longer presents the IATO Platform and Crawl Management tool toggles as functional when no IATO API key is configured. Previously the checkboxes appeared enabled and saveable, but bridge tool registration is gated by a separate condition at iato-mcp.php:85 (the bridge tool files only require_once when the API key is non-empty), so the toggles were placebo — a user could check every box, save, and still get Unknown tool: get_iato_sitemap on every call with no UI signal explaining why. The toggle inputs in those two categories are now disabled when the API key is empty, the category card grays out (55% opacity), and an inline banner under the heading explains: «These tools require an IATO API key. Add it under ‘IATO Platform’ above to enable them — until then, these toggles have no effect.» When the user pastes an API key and saves, the categories become interactive again.

1.4.6

• Fix: rollback now appears as a checkbox on the Settings → IATO MCP page (under a new «Safety» category). v1.4.5 added rollback to the TOOL_NAMES constant — which fixed the sanitize-strip behavior — but the Settings UI rendering loop iterates a separate constant, TOOL_CATEGORIES, which also needed rollback added. Without the category entry, the checkbox was never rendered. Adding 'Safety' => ['rollback'] closes the gap.
• Polish: unified the inner mcpServers server key shown in the Settings page hero card config snippet from wordpress to iato-wordpress, matching the dismissible setup notice. Cosmetic only — the inner key is a user-facing display name they can rename — but eliminates an unnecessary inconsistency between the two snippets.

1.4.5

• Fix: rollback tool now appears in the Settings → IATO MCP per-tool toggle list, and the Settings save no longer silently strips it from iato_mcp_tools. When v1.4.0 added the rollback MCP tool, the developer forgot to add it to the TOOL_NAMES constant in class-settings.php. Consequence: no UI checkbox for it, and sanitize_tools() (which array_intersects saved values against TOOL_NAMES) was stripping it from existing installs every time a user clicked Save Settings. Once stripped, is_tool_enabled('rollback') returned false and the tool stopped registering. Adding rollback to TOOL_NAMES fixes both the UI and the strip behavior.
• Fix: idempotent migration restores rollback to iato_mcp_tools for any install where it had been stripped by the previous bug. Runs once on plugin upgrade, no-op for installs that didn’t lose it.
• Fix: capabilities.rollback in the initialize response now reflects actual tool registration instead of being hardcoded true. Previously, an install with rollback disabled (manually or via the strip bug above) would advertise rollback: true in capabilities, causing clients that feature-detect to attempt rollback calls that returned tool_not_found.

1.4.4

• Fix: clicking Approve on the OAuth consent screen no longer redirects users to /wp-admin instead of back to the OAuth client. The handler at class-oauth.php:181 was using wp_safe_redirect() for the post-approval callback, but wp_safe_redirect silently rewrites any URL whose host isn’t on WordPress’s allowed_redirect_hosts allowlist to admin_url() — which means every external OAuth callback (claude.ai, cursor.sh, etc.) was being silently rewritten to /wp-admin/, leaving the connector stuck on «Connect» because the client never received an authorization code. Switched to wp_redirect(), which is the correct primitive for OAuth callbacks (the protocol requires an external redirect by design).
• Fix: the not-logged-in branch of the authorize handler at class-oauth.php:132 was passing $_SERVER['REQUEST_URI'] through sanitize_text_field() before building the post-login redirect URL. sanitize_text_field strips %XX percent-encoded sequences as an HTML-entity defense, which mangled the inner redirect_uri parameter (every : and / removed) and broke the post-login bounce back to /oauth/authorize. Now uses wp_unslash only, which is correct for a server-set value used as a redirect target.
• Hardening: /oauth/authorize now refuses requests whose client_id isn’t registered via the dynamic client registration endpoint at /oauth/register. Previously the redirect_uri allowlist was opt-in (validated only when the client_id existed in the registered set) — after the wp_redirect change above lets external redirects through, that opt-in shape was an open-redirect surface. Spec-compliant clients (Claude, Cursor, etc.) already register before authorize, so this is a no-op for them.
• Fix: initialize now echoes the client’s requested protocolVersion when it’s one we recognize (2024-11-05, 2025-03-26, 2025-06-18) instead of always returning 2024-11-05. Falls back to 2025-06-18 for unknown requests. Forward-compat for clients on newer MCP revs.

1.4.3

• Fix: dismissible «MCP — Ready to Connect» admin notice restructured. The previous «1. Copy / 2. Open Claude Desktop / 3. (Optional) IATO key» framing implied a sequential three-step flow, but Step 1’s snippet and Step 2’s «Or use Add Custom Connector» sub-line were actually two mutually-exclusive connection methods, and Step 3 was unrelated optional setup. Notice now leads with the endpoint URL (with its own Copy button), then presents Option A (Connectors UI / OAuth, recommended) and Option B (Claude Desktop config file with the mcp-remote stdio snippet) as clearly-labeled alternatives separated by an «— or —» divider, with the IATO API key and «see the setup wizard for other clients» line moved to a non-numbered footer. Same content, structure no longer suggests dependence between the two paths.

1.4.2

• Fix: Authorization: Basic <Application Password> is now an accepted auth path on the MCP endpoint, alongside the existing plugin Bearer token. v1.4.1 documented Application Password support in the setup wizard but class-auth.php was hard-rejecting any non-Bearer header — users following wizard Methods 2 or 3 were getting 401s. This release makes the wizard’s promise actually work. Trust grant in this version is identical to the Bearer path (full admin once authenticated); per-user capability enforcement under Application Password is tracked separately as a v1.6 hardening item.
• Fix: dismissible setup notice now emits a Claude-Desktop-compatible stdio-bridge config (mcp-remote via npx, Bearer + iato_mcp_key in an env entry) instead of the direct-HTTP {url, headers} format that Claude Desktop’s config file can’t consume. Same bug class as the v1.4.1 wizard fix; this catches the second occurrence in the admin notice.
• Fix: relabeled the Settings page hero-card config block from «Claude Desktop Configuration» to «HTTP MCP clients (MCP Inspector, IDEs, scripts)» — the snippet is still the right config for those clients, just no longer mislabels its audience. Adds a one-line pointer to the setup wizard for stdio-only clients.

1.4.1

• Fix: setup wizard restructured around the three actual connection methods. The previous «1. URL → 2. Application Password → 3. Claude Desktop config» framing presented OAuth-via-Connectors users with a credential step they didn’t need, and the JSON snippet referenced @modelcontextprotocol/server-http — a package that doesn’t exist on npm. The wizard now leads with the endpoint URL, then presents three mutually exclusive method cards: Connectors UI (OAuth, recommended), Direct HTTP (Basic Auth for MCP Inspector / IDEs / scripts), and Manual config (stdio bridge for Claude Desktop config file, Cursor, Cline, Zed).
• Fix: stdio-bridge JSON snippet now uses mcp-remote (the real npm package) and passes the credential via an env entry referenced as ${IATO_AUTH} in args, working around Claude Desktop’s args parser breaking on spaces inside inline header strings.

1.4.0

• New: rollback MCP tool. Reverses any prior write by change_id. Wraps the existing wp-json/iato-mcp/v1/rollback REST endpoint so Claude can undo a change in one MCP call instead of the user constructing a manual HTTP request. Validates the stored before_value to prevent tampering, dispatches by target_type, and marks the receipt rolled-back so it cannot be re-applied. Requires edit_posts (with elevated manage_options for menu_item and redirect receipts to mirror the original write capability).
• New: change receipts on update_post and create_post. Previously these two write tools returned no audit trail, so even though every other write tool emitted a receipt, the most common edits — title, content, excerpt, status, and net-new posts — couldn’t be rolled back. update_post now records one receipt per actually-changed field (skipping no-op resends); create_post records target_type=post, field=create, and rollback reverses it via wp_trash_post (recoverable from the WP trash).
• New: capabilities.rollback: true in the initialize response so MCP clients can feature-detect rollback support without a tools/list round-trip — same pattern as the existing capabilities.elementor.v2.
• Migration: appends rollback to the saved iato_mcp_tools per-tool toggle option on first request after upgrade so existing installs see the new tool enabled by default. Same idempotent migration pattern used for the v2 Elementor tools in 1.3.5.

1.3.5

• Docs: corrected the FAQ entry that still claimed «30 built-in tools» — now reflects the v1.3.0 widget-grained Elementor surface (39 WordPress native + 12 IATO bridge = 51 total).
• Docs: added two example prompts demonstrating widget-grained edits («Set every H2 heading in these Elementor posts to H1» and «Find all button widgets on the site and change their color to #ff0000») so the v2 capability is concrete for end users who don’t know Elementor jargon.
• No code changes.

1.3.4

• Optimization: update_elementor_widgets_bulk no longer echoes change_receipt on per-result rows. Receipts are still persisted to the iato_change_receipts audit table; bulk callers who need them can query by post_id + applied_at. Saves ~120 bytes per result. Brings the canonical 4-page H1-flip benchmark response under the v2 spec’s <2 KB hard target. Singleton update_elementor_widget and update_elementor_patch responses keep the slim receipt for backward-compat and convenience.

1.3.3

• Optimization: v2 write tools (update_elementor_widget, update_elementor_patch, update_elementor_widgets_bulk) now elide previous_revision from per-result responses unless the caller passed if_revision. Rationale: a client that passed if_revision already knows the prior hash (echoing back confirms what the server saw on conflict), and a client that didn’t pass it doesn’t need it on the wire — they get current_revision to chain the next write. Saves ~93 bytes per result; brings the canonical 4-page H1-flip benchmark response under the v2 spec’s <2 KB hard target on the op: replace path.

1.3.2

• Fix: v2 write tools (update_elementor_widget, update_elementor_patch, update_elementor_widgets_bulk) used to echo a verbose change_receipt containing the entire applied_patch JSON-stringified into before_value. That duplicated the top-level applied_patch field on every response and pushed bulk-update payloads over the spec’s <2 KB target on a 4-page sweep. The receipt’s before_value was also semantically wrong (it should be the value being replaced, not the patch). Fixed both: storage rows now record the canonical previous_revision → current_revision pair, and the API response carries only the receipt id + metadata ({change_id, target_type, field, applied_at}). Full audit data still queryable from the iato_change_receipts table for rollback. Per-update savings ~0.6–0.8 KB; on a 4-page bulk sweep that’s ~3 KB shaved off the wire.

1.3.1

• Fix: update_elementor_widgets_bulk and find_elementor_widgets no longer reject every request with auth_denied. The handlers were calling current_user_can( 'edit_post', $post_id ) / current_user_can( 'read_post', $pid ) per-target, but bearer-authenticated MCP requests don’t establish a logged-in WP user — wp_get_current_user() returns 0, and meta-cap checks against post objects always fail. v1 tools sidestep this via IATO_MCP_Auth::require_cap(), which is a flag check that returns true for any bearer-authenticated request (per the documented «the plugin key grants full administrative access» auth model). The v2 handlers now match v1 semantics.
• Fix: idempotent one-shot migration on plugin update. Existing installs upgrading from 1.2.x to 1.3.x previously saw the nine new Elementor v2 tools auto-disabled because saved iato_mcp_tools per-tool toggle arrays didn’t include the new names. The migration appends new tool names to the saved option on first request after upgrade. New installs unaffected.

1.3.0

• New: widget-grained Elementor surface (v2). Nine new MCP tools — list_elementor_widgets, get_elementor_widget, update_elementor_widget, update_elementor_patch, update_elementor_widgets_bulk, find_elementor_widgets, set_heading_level, set_widget_setting, resolve_url. Replaces the all-or-nothing update_elementor_data for surgical edits while preserving the v1 tool unchanged.
• New: optimistic concurrency on every v2 write via if_revision (sha256 of stored Elementor data). Mismatch returns revision_conflict with the current revision so clients can re-sync without an extra read.
• New: idempotency keys on every v2 write via idempotency_key. Same key + same payload within 60s returns the cached response with idempotency_replay: true; same key + different payload returns 409. Scoped per-(user, tool).
• New: structured applied_patch diff response on every v2 write — RFC 6902 ops with previous_value extension. Identical shape in dry_run mode so clients can preview before committing.
• New: update_elementor_patch accepts an RFC 6902 JSON Patch over the entire document for surgical array-entry edits (repeater rows, indexed inserts) where v2 widget patch’s replace-only array semantics are too coarse.
• New: find_elementor_widgets searches every Elementor post in the workspace (capped at 500 in 1.3.0) for widgets matching a filter spec — operators eq, ne, in, nin, exists.
• New: resolve_url walks the WordPress rewrite cascade and reports the rendering post + Theme Builder template shadowing (Elementor Pro). Best-effort across Elementor versions; returns limited_resolution: true when the platform’s APIs aren’t available.
• New: is_shadowed_by field on get_post (opt-in via include_shadowing: true) — surfaces Theme Builder template overrides without requiring a separate resolve_url call.
• New: format parameter on get_elementor_data — raw (existing), compact (defaults stripped, top-20 widget types), summary (skeleton tree of {widget_id, type, peek_fields}). All formats include the canonical revision hash for use with v2 if_revision guards.
• New: initialize response advertises capabilities.elementor.v2: true when Elementor is active so clients can feature-detect without a tools/list round-trip.
• Existing v1 tools (get_elementor_data, update_elementor_data) remain functional with unchanged signatures — no breaking changes.

1.2.4

• Fix: list_iato_crawls now returns the UUID job_id as crawl_id instead of the numeric DB primary key. The numeric id had no FK relationship to the other bridge tools (which all key off the UUID via /crawl/jobs/{uuid}/...), so handing it back to Claude broke the analyze-and-fix chain at the first hop.
• Fix: list_iato_crawls envelope read now falls back from canonical data.jobs to bare jobs if the platform regresses or a new un-wrapped endpoint slips through. Same dual-key resilience pattern used for /workspaces during the v1.1 transition.

1.2.3

• Fix: start_iato_crawl now sends workspace_id as a JSON integer, not a JSON string. The platform’s POST /crawl/start handler binds the field as Optional[int] via Pydantic; depending on strict-mode it can reject "44" while accepting 44. Resolves orphan-crawl creation that persisted from 1.2.0–1.2.2.

1.2.2

• Fix: Test connection now persists the workspace_id when validation succeeds, so the crawl-control tools can scope requests correctly. Previously the option remained empty even after a successful validation, which made start_iato_crawl create orphan jobs and list_iato_crawls return an empty list.
• Fix: start_iato_crawl and list_iato_crawls now use resolve_workspace_id() (with built-in lazy-load fallback) instead of reading the option directly. Self-heals existing installs that validated their key before 1.2.2.

1.2.1

• Fix: start_iato_crawl now tags new crawls with the user’s workspace_id so they are properly scoped to the connected IATO account
• Fix: list_iato_crawls now filters by workspace_id to return crawls owned by the connected account (previously returned an empty list even when crawls existed)
• Fix: replace PHP 8.2-only : true|WP_Error literal type with : bool|WP_Error across class-auth, class-seo-adapter, class-rollback, and tool-redirects so the plugin parses cleanly on PHP 8.0/8.1 as the header advertises

1.2.0

• New: start_iato_crawl MCP tool — Claude can kick off an IATO crawl of the current site directly from a conversation (admin only; consumes IATO platform quota)
• New: get_iato_crawl_status MCP tool — poll a specific crawl job until it completes
• New: list_iato_crawls MCP tool — list recent crawl jobs to find the most recent completed crawl_id
• New «Crawl Management» category in Settings > IATO MCP > Tools
• Bridge tool count: 9 → 12; total registered tools: 39 → 42
• New FAQ entry on the dual auth methods (Application Password / OAuth for AI clients vs. Bearer token for the IATO platform’s WordPress Sync UI)

1.1.12

• Added Plugin URI to plugin header
• Added contextual links to iato.ai throughout the plugin description, installation, and FAQ sections
• Added link to documentation page

1.1.11

• Readme accuracy corrections: updated tool count from 17 to 30, expanded feature list with Elementor, canonical URLs, structured data, redirects, and excerpt support, corrected minimum WordPress version to 6.2

1.1.10

• 30 WordPress native tools including Elementor read/write and the new excerpt parameter on update_post
• 9 IATO bridge tools: sitemap, SEO fixes, broken links, content gaps, orphan pages, navigation audit, AI suggestions, performance reports, taxonomy analysis
• OAuth 2.0 authorization server with PKCE for Claude Desktop connector flow
• Dynamic client registration (RFC 7591)
• SEO adapter supporting Yoast SEO, RankMath, and SEOPress
• Single Settings page with General and Diagnostics tabs; 39 per-tool toggles
• AJAX-based Save Settings to sidestep host-level options.php timeouts
• «Test connection» button for explicit IATO API key validation
• Change receipts audit trail for every write operation, with Claude-callable rollback endpoint
• MCP notifications/* methods silently accepted per JSON-RPC spec
• Plugin-generated API key with Bearer token authentication