WordPress.com

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.

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.

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.

Add or remove DNS records (A, AAAA, ALIAS, CAA, CNAME, MX, NS, SRV, TXT) for a single custom domain. Supply two arrays: records_to_add (records to create) and records_to_remove (records to delete, matched against existing records by their fields). 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 ability verifies the nameservers itself: when the domain does not use the WordPress.com nameservers the update is refused with status wpcom_nameservers_required and no records are changed, unless apply_without_wpcom_nameservers is true. Root NS records on domains registered with WordPress.com cannot be modified. The caller must have manage_options on the site the domain is connected to.

When the update is refused with wpcom_nameservers_required, relay the message field to the user, and only set apply_without_wpcom_nameservers to true if the user wants to prepare the WordPress.com zone before switching nameservers. Verify can_manage_dns_records is true via wpcom/domain-details before calling. To inspect the current records first, 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.

Set the nameservers for a single custom domain. Only works for domains registered with WordPress.com; for connected/mapped domains the nameservers are managed at the external registrar and this ability returns a domain_not_registered_with_wpcom error. Provide between 2 and 13 valid nameserver hostnames as plain strings (e.g. ["ns1.example.com", "ns2.example.com"]). The caller must have manage_options on the site the domain is connected to. Root NS records on domains registered with WordPress.com may be subject to additional restrictions (e.g. during TLD maintenance).

Confirm eligibility via can_manage_name_servers on wpcom/domain-details before calling. To inspect the current nameservers first, call wpcom/domain-get-nameservers. 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.

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.

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 categories and tags, 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.

Create a new WordPress.com site. This tool is the ONLY entry point the agent should use to create a site.

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.

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.

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 returns a data-aware preview first.

Workflow: "list" to discover operations, "describe" for parameter schema, "execute" to run.

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".

Manage site-level settings and infrastructure for a WordPress.com site — not content (use wpcom-mcp-content-authoring for posts, pages, media). Covers: settings, statistics, plugins, users, activity log, and theme management (theme.list to browse available themes, theme.set to activate one). Use wpcom-user-sites first if you need to find the target site ID. Workflow: "list" to discover operations, "describe" for parameter schema, "execute" to run. Always share results with the user.

SAFETY PROTOCOL: Before ANY write operation (settings.update, theme.set), 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.

Read and modify site structure: templates, template parts, navigation menus (classic and block), global styles, and installed themes. Write operations (create/update/delete) affect all visitors site-wide and require the user's confirmation before they run.

Use action "list" to discover operations, "describe" for schema, "execute" to run. Recommended sequence before any write: fetch current state first (templates.list -> templates.get, or navigation.list -> navigation.get, or global-styles.get). For FSE block types use site-editor-context blocks.allowed with the site-editing context.

Query site design context. Operations: theme.active (active stylesheet slug), theme.presets (color palette, fonts, spacing tokens), theme.styles (applied block/element styles), blocks.allowed (registered block types). theme.presets and theme.styles auto-resolve the stylesheet from the active theme if omitted.

Use action "list" to discover operations, "describe" for schema, "get" to fetch data. Start with theme.active to get the stylesheet slug, then theme.presets for design tokens. Use preset slugs instead of hard-coded values.

Manage site collaborators on a WordPress.com site. Seven operations: user.list and user.pending-invites are read-only; user.invite and user.resend-invite send a real email; user.cancel-invite cancels a pending invite; user.change-role and user.remove-access return a preview; every write runs only with user_confirmed: true. user.remove-access is irreversible: it removes the user from this site only and does not delete their WordPress.com account. user.invite and user.change-role accept only the five stock WordPress roles (administrator, editor, author, contributor, subscriber); custom or plugin-introduced roles (e.g. shop_manager, bbp_moderator) are not supported on this surface. All operations require wpcom_site at the top level of the input.

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.