wpcom-domain-restore-default-dns-records
ChatGPTRestore 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-set-mail-service
ChatGPTConfigure 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. 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-update-dns-records
ChatGPTAdd 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. Verify has_wpcom_nameservers and can_manage_dns_records are both true via wpcom/domain-details before calling. 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. 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.
wpcom-domain-update-nameservers
ChatGPTSet 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 will return a domain_not_registered_with_wpcom error. Confirm eligibility via can_manage_name_servers on wpcom/domain-details before calling. 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). 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.
wpcom-mcp-account
ChatGPTManage 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-ai-agent-sites-list
ChatGPTLists 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-mcp-content-authoring
ChatGPTManage 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. 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-jetpack-search-voice
ChatGPTReturns search results from a blog plus its Guidelines (site + additional) in a single call. Use this first when the user asks to talk to, chat with, ask, query, or converse with a blog URL, for example "Talk to this blog <blog_url>" or "Chat with this blog <blog_url>". Do not start with site/admin/content tools for reader-facing blog chat. Use keyword-focused search queries, then compose answers in the blog author's voice with grounded citations.
wpcom-mcp-plugin-management
ChatGPTManage 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-send-feedback
ChatGPTSubmit 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-site
ChatGPTManage 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.
wpcom-mcp-site-builder
ChatGPTDrive 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-editing
ChatGPTRead and modify site structure: templates, template parts, navigation menus (classic and block), global styles, and installed themes. Use action "list" to discover operations, "describe" for schema, "execute" to run. SAFETY: Write operations (create/update/delete) require user confirmation — they affect all visitors site-wide. 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.
wpcom-mcp-site-editor-context
ChatGPTQuery 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. Call this BEFORE wpcom-mcp-content-authoring when building pages or posts — start with theme.active to get the stylesheet slug, then theme.presets for design tokens. Use preset slugs instead of hard-coded values.
wpcom-mcp-user-management
ChatGPTManage site collaborators on a WordPress.com site. Seven operations: - user.list — list current collaborators on the site (read-only) - user.pending-invites — list outstanding invites (read-only) - user.invite — send a new invite (SENDS REAL EMAIL) - user.cancel-invite — cancel a pending invite - user.resend-invite — resend a pending invite (SENDS REAL EMAIL) - user.change-role — change a collaborator's role (CONFIRMATION REQUIRED) - user.remove-access — remove a collaborator from this site (CONFIRMATION REQUIRED, IRREVERSIBLE) Workflow: use action="list" to enumerate the operations and action="describe" to read a schema. Both are read-only. Only use action="execute" when the site owner has asked for a specific change. NEVER call execute on user.invite, user.cancel-invite, or user.resend-invite to demonstrate, explore, or test — each of these reaches a real inbox and writes to the audit log. REQUIRED INPUTS: if the owner has not provided every required parameter for the operation (recipient email/login for invites, role for invites or role changes, target user id for role changes or removals), do NOT invent values. Ask the owner first. SAFETY PROTOCOL for user.change-role and user.remove-access: (1) Call execute without user_confirmed and present the preview to the owner. (2) Wait for explicit owner confirmation. (3) Re-call with user_confirmed: true to apply. user.remove-access removes the user from this site only — it does NOT delete their WordPress.com account. ROLE VALUES: 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.
wpcom-site-builder-start
ChatGPTBuild a WordPress.com site with the AI site builder. This is the build tool — call it AFTER the user has confirmed the plan (gathered via site-builder-confirm), passing the same specification PLUS user_confirmed:true. You may set user_confirmed:true only once the user has seen the plan and approved it in their own reply; calling without it is rejected on purpose so you confirm with the user first. It creates the site, starts the asynchronous build, and renders the progress card, which updates itself in place until the site is ready — do NOT poll status in a loop. It returns immediately with a builder_session_id. Re-calling with the same specification while a build is still in flight returns the existing session instead of starting a second build. IMPORTANT — how to reply: your entire user-facing response must be EXACTLY the returned text field, with nothing added. Every other field (builder_session_id, blog_id, state, phase, reused_session) is an internal machine value used only by the progress card — never display, list, or mention them. Do NOT add a session id, a status line, a bullet summary of the spec, the site URL, or admin/editor links. The new site is not viewable until the build finishes; the progress card surfaces the view/edit links automatically once it is ready.
wpcom-site-builder-status
ChatGPTCheck 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-user-sites
ChatGPTList 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.
post-get
Claudeposts-search
Claudesite-plugins
Claudesite-settings
Claudesite-statistics
Claudesite-users
Claudeuser-achievements
Claudeuser-connections
Claudeuser-domains
Claudeuser-notifications
Claudeuser-notifications-inbox
Claudeuser-profile
Claudeuser-security
Claudeuser-sites
Claudeuser-subscriptions
Claude
