Jetpack

Manage the current user's WordPress.com account: profile, notifications, achievements, domains, subscriptions, connections, and security. Exposes read operations and write operations (profile and notification updates, billing currency, domain and subscription changes); every write requires the user's explicit approval before it runs. Workflow: "list" to discover available operations, "describe" for parameter schema, "execute" to run. Always share results with the user.

wpcom-mcp-account

Manage content on WordPress.com sites: posts, pages, media, comments, taxonomies, and patterns. Also covers custom post types such as WooCommerce products and portfolio projects, and their own taxonomies (such as product categories), through the content-types.*, content-items.* and content-terms.* operations. Includes block-level section operations (page-sections.* / post-sections.*) that edit one top-level block of an existing page or post in place, alongside pages.update / posts.update for new content and full rewrites. Every create, update, or delete operation requires the user's explicit approval before it runs. 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.

wpcom-mcp-content-authoring

Create a new WordPress.com site on the user's account. This facade is the only entry point for site creation. Operations: site.instructions returns the runbook (field schema, conversational rules, confirmation policy including the subdomain derivation rule, the handoff to site.provision, the next actions available after creation, and a preflight_required block when the user has not enabled site creation); subdomain.check reports whether the slug derived from a title is valid and available, with the would_be_url the user would receive; site.provision creates the site from a spec in which only title is required, description (a one-sentence tagline) is optional, and locale defaults from the account. The subdomain is derived from the title and is not an input. site.provision creates a real site and requires the user's explicit confirmation of the title and subdomain preview before it runs. CORE RULES (apply without calling site.instructions): - The subdomain is DERIVED from `title` automatically. NEVER ask the user for a URL slug, subdomain, or custom site address - it is not an input field. Show a subdomain preview derived from the title for confirmation only. - Ask ONE direct question for the title. Do NOT ask about site type, audience, tone, topic, or goals - those are NOT required to create a site. - After the site is created, share the URL and STOP. Do NOT auto-chain into theme picking or homepage authoring; offer them only if the user asks. WORKFLOW: 1. action="execute", operation="site.instructions" (no params) - returns the runbook: field schema, conversational rules, confirmation policy (including the deterministic subdomain-derivation rule), the handoff to site.provision, and a list of next actions available after creation. When the user has not enabled the create-site capability, the runbook also surfaces a `preflight_required` block - walk the user to the link in that block BEFORE asking any interview question. Call site.instructions ONCE, up front. 2. Ask the user a single direct question for the title (or detect test-site intent - see the runbook rules - and skip to step 3 with "Test site" as the title). 3. Derive the subdomain slug from `title` locally per the `subdomain_derivation_rule` in the runbook (lowercase, strip diacritics, remove every non-alphanumeric character). Then call action="execute", operation="subdomain.check", params: { slugs: [ <derived slug> ] }. Read the first entry in `results`; it reports whether the slug is valid + available, plus the `would_be_url` the user will actually receive (which may carry a numeric suffix when the base slug is taken). Show the user the actual `results[0].would_be_url` verbatim before asking for title confirmation. If `results[0].is_valid` is false (empty slug, blacklisted, invalid characters), ask the user for a different title and re-derive - do NOT proceed to site.provision. 4. (Optional) Ask once whether the user wants a short tagline; accept "skip" / "not now" cleanly. 5. Summarize the collected fields - especially the title and the `would_be_url` from subdomain.check - and ask for explicit confirmation. 6. action="execute", operation="site.provision", params: { spec: { title: <confirmed title>, [description: <tagline if provided>] }, user_confirmed: true }. `title` is the only required field on `spec`; `description` is the only common optional field. `user_confirmed` MUST be the boolean `true` (or one of the strings `"true"` / `"yes"` / `"on"` / `"1"`) after the user has approved the title and subdomain preview. 7. On success, share the returned site_url and stop. On `invalid_spec` errors, the error message lists each offending field on its own line (for example `- spec.title: missing field`); fix only the listed fields and retry site.provision. On `empty_subdomain_after_derivation` errors, the title strips to an empty subdomain (subdomain.check should have caught this earlier) - ask the user for a different title and retry. SPEC SHAPE: only `title` is required. `description` (one-sentence tagline) is optional. `locale` is auto-defaulted from the user's account locale. SAFETY: site.provision creates a real site on the user's account. Only call it after the user has explicitly confirmed the title and subdomain preview.

wpcom-mcp-create-site

Returns search results from a public, opted-in blog plus its Guidelines (site + additional) in a single call, for answering reader-facing questions from a public blog URL in that blog's voice. Covers public blog content only: not private or internal content, WordPress.com site or account management, or owner/admin content operations. 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, the site opt-in that also makes a site available to Jetpack Search Voice. Accepts 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. Results are paginated by after_blog_id/per_page, and pagination.has_more reports whether more pages exist. 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. 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. When displaying or referencing a site, use its primary_domain, not the host of site_url.

wpcom-user-sites

Manage plugins on a WordPress.com site: list installed plugins, search the marketplace catalog, install, activate, deactivate, update, and uninstall. plugin.search is account-level and does not require a site; all other operations require wpcom_site. Every write operation requires the user's explicit approval before it runs; plugin.uninstall first returns a preview naming the plugin, its version and whether it is active; it does not list the plugin's stored data. Workflow: "list" to discover operations, "describe" for parameter schema, "execute" to run.

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. The caller must have manage_options on the site the domain is connected to. Verify has_wpcom_nameservers and can_manage_dns_records are both true via wpcom/domain-details before calling. 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, or check the status of feedback you already sent. Feedback is reviewed internally; submitting returns a feedback ID. Suggest this tool when the user encounters errors, expresses frustration, or struggles to accomplish their goal with the available tools. When the user asks what happened to feedback they sent, call it with action "status".

wpcom-mcp-send-feedback

Configure DNS records on a domain for an external mail service (Google Workspace, iCloud Mail, Office 365, or Zoho Mail) by applying the provider DNS template in one step. Supply the verification token the provider asked you to add to your DNS as proof of domain ownership. The caller must have manage_options on the site the domain is connected to. Changes only take effect when the domain uses the WordPress.com nameservers; for domains pointed at a third-party DNS provider, the records must be applied at that provider. For Google Workspace, DKIM is optional: pass dkim_selector and dkim_txt_record together to add the DKIM record, or omit both to set up verification, SPF and MX only. The user generates those two values in the Google Admin console, where the default selector is "google". Confirm has_wpcom_nameservers and can_manage_dns_records via wpcom/domain-details before calling. To see what records were applied, call wpcom/domain-dns-records afterwards. 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-set-mail-service