WordPress.com

Manage the current user's WordPress.com account — profile, notifications, achievements, domains, subscriptions, connections, and security. To list all your sites, use the standalone wpcom-user-sites tool. Workflow: "list" to discover available operations, "describe" for parameter schema, "execute" to run. Always share results with the user. SAFETY PROTOCOL: Before ANY write operation (profile.update, notifications.update), you MUST: (1) Describe exactly what you plan to change. (2) Ask the user for confirmation and wait for their response. Never auto-execute write operations without user approval.

wpcom-mcp-account

Drive the AI site builder. This is the card-less conversation surface: use it to learn what to collect (instructions), and to validate and confirm the spec (confirm). The actual build — and the only progress card — is a separate tool, site-builder-start. WORKFLOW: 1. action="execute", operation="instructions" (no params) — returns the interview runbook: exactly which specification fields to collect and the rules for asking vs. inferring. Call this once, up front. No card. 2. Interview the user in ordinary chat, one question at a time, until you have the required fields. Then action="execute", operation="confirm", params: { ...spec }. confirm is read-only and card-less: it validates the spec, lists any still-missing fields, and returns a plain-text summary (purpose, pages, style) for the user to confirm. No card appears. 3. Show the confirm summary and END YOUR TURN — wait for the user to reply. Do NOT build in the same turn. Only after the user approves, call the SEPARATE build tool site-builder-start with params: { ...spec, user_confirmed: true }. That call kicks off the asynchronous build and is where the progress card first appears; it updates itself in place until the site is ready — do NOT poll status in a loop. The build tool rejects calls without user_confirmed:true, by design, to force this confirmation. 4. (optional, text-only snapshot) action="execute", operation="status", params: { builder_session_id: <id from start> } returns build progress as text for a host without card support. Skip it on card hosts — the card self-updates. 5. (optional, after ready) action="execute", operation="design", params: { builder_session_id: <id> } — read-only: lists the built site's theme style presets. After the user picks one, apply it with the site-editing tool (operation global-styles.update). Use the site-editing tools for navigation, menus, and templates. SAFETY: instructions, confirm, status, and design make no changes. The build tool (site-builder-start) creates a real site and runs a real build. Applying a design style changes the live site, so confirm with the user first. Show the confirm summary and get the user's agreement before calling site-builder-start.

wpcom-mcp-site-builder

Check the progress of a site build started with site-builder-start. Pass the builder_session_id you received from start. Returns the current state (draft, provisioning, building, ready, published, failed), a percent estimate, the current build step, and a human-readable summary. Poll this until state is "ready" or "failed".

wpcom-site-builder-status

Manage content on WordPress.com sites — posts, pages, media, comments, taxonomies, and patterns. For site infrastructure (settings, plugins, users), use wpcom-mcp-site instead. Workflow: "list" to discover operations, "describe" for parameter schema, "execute" to run. To change one part of an existing page or post without rewriting the whole thing, use the block-level (section) operations (page-sections.* / post-sections.*) instead of pages.update / posts.update; they edit a single top-level block in place. Reserve pages.update / posts.update for new content and full rewrites. For design-aligned content: fetch wpcom-mcp-site-editor-context (theme.active → theme.presets) first, then browse patterns here (patterns.list → patterns.get), customize with preset slugs, and create as draft. Show edit/preview links after create/update. Always share results with the user. SAFETY PROTOCOL: Before ANY create, update, or delete operation, you MUST: (1) Describe exactly what you plan to do. (2) Ask the user for confirmation and wait for their response. (3) Re-call with `user_confirmed: true` (boolean) in params. Never auto-execute write operations without user approval.

wpcom-mcp-content-authoring

Returns search results from a public, opted-in blog plus its Guidelines (site + additional) in a single call. Use this only for reader-facing requests to answer from a public blog URL in that blog's voice, for example "Talk to this blog <blog_url>" or "Chat with this blog <blog_url>". Do not use this for private/internal content, WordPress.com site or account management, or owner/admin content operations. Use keyword-focused search queries, then compose answers in the blog author's voice with grounded citations.

wpcom-mcp-jetpack-search-voice

Lists public production WordPress.com sites whose owners enabled AI Agent Access. Use this when the user asks to list, find, discover, or show sites/blogs that opted into AI agents, AI Agent Access, Blog Talks Back, or sites available for Jetpack Search Voice. Pass query or keywords to filter by what a site is about, matched against existing site metadata like title, description, site vertical, and site intent. This is the discovery/listing tool; it does not search within a blog. Page with after_blog_id/per_page until pagination.has_more is false.

wpcom-ai-agent-sites-list

List the authenticated user's accessible sites across WordPress.com and self-hosted Jetpack-connected sites. Returns blog IDs, URLs, names, platform type, MCP access status, and optional metrics. Use this to discover which site IDs exist before calling site-scoped abilities.

wpcom-user-sites

Manage plugins on a WordPress.com site — list installed plugins, search the marketplace catalog, install / activate / deactivate / update / uninstall. Workflow: "list" to discover operations, "describe" for parameter schema, "execute" to run. plugin.search is account-level and does not require a site; all other operations require wpcom_site. SAFETY PROTOCOL: Before ANY write operation (install / activate / deactivate / update / uninstall) you MUST: (1) Describe exactly what you plan to change. (2) Ask the user for confirmation and wait for their response. (3) Pass user_confirmed: true in params for the four standard write operations. plugin.uninstall additionally returns a data-aware preview when called without user_confirmed: true — use that preview to confirm with the user before re-calling with user_confirmed: true.

wpcom-mcp-plugin-management

Restore the WordPress.com defaults for a single custom domain. With record_type "A", replaces the apex A records with the WordPress.com default IPs and removes any apex AAAA records (handy after a DNS misconfiguration that broke pointing the bare domain at WordPress.com). With record_type "CNAME", replaces the www CNAME with one pointing back at the apex (e.g. www → example.com). Changes go into effect only if the domain uses the WordPress.com name servers — for domains pointed at a third-party DNS provider, the records must be managed at that provider. Verify has_wpcom_nameservers and can_manage_dns_records are both true via wpcom/domain-details before calling. The caller must have manage_options on the site the domain is connected to. To inspect the resulting records, call wpcom/domain-dns-records. Always check domain_status via wpcom/user-domains first; if it is not "active", mention that to the user — expired domains may not resolve even when DNS and nameservers look correct.

wpcom-domain-restore-default-dns-records

Submit feature requests, bug reports, or general feedback about the WordPress.com and ContextA8c MCP servers to the development team. Feedback is reviewed internally. Suggest this tool when the user encounters errors, expresses frustration, or struggles to accomplish their goal with the available tools.

wpcom-mcp-send-feedback