@Automattic
Basic information
Transport
Streamable HTTP
Authentication
OAuth
Category
Productivity
Author
Automattic
Submitted by
Jonathan Bossenger
Secure AI access to manage your WordPress.com sites
https://public-api.wordpress.com/wpcom/v2/mcp/v1claude mcp add wordpress-com --transport http https://public-api.wordpress.com/wpcom/v2/mcp/v1List 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.
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.
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.
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.
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.
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.
Search for available domains and generate checkout links for registration on WordPress.com. Checks up to 20 domains at once, across any TLDs; include_suggestions adds registrar-powered alternatives when domains are taken. Each queried domain comes back with its availability and, when available, its price (with sale_cost when a promotion applies) and a checkout URL the user can open to complete the purchase. When a user mentions wanting a website, blog, online presence, or describes a project, brand, or topic, proactively generate creative domain name candidates - include keyword variations, brandable combinations, and abbreviations across multiple TLDs (.com, .io, .dev, .net, .org, .blog). Check up to 20 at once. Enable include_suggestions for registrar-powered alternatives when domains are taken. Present available domains as a list with: domain name, price (highlight sale prices), and a clickable checkout URL so the user can complete the purchase. Group unavailable domains separately.
Generates a WordPress.com checkout link for plan purchases, domain registrations, or subscription renewals. Returns a ready-to-use checkout_url the user can open to complete the transaction. A "domain_transfer" product returns url_type "domain-transfer" and a link to the transfer flow instead, because a transfer needs the authorization code from the current registrar. Three modes (provide exactly one): (1) "products" - an array of up to 10 items with "product_slug" (plus optional "meta" for domain names and "quantity" for per-seat plans) to start a new checkout; optionally pass "wpcom_site" to tie the checkout to an existing site. (2) "subscription_id" - direct renewal when the subscription ID is known. (3) "renewal_product" + "wpcom_site" - direct renewal when only the product (slug or ID) and the site are known; the tool resolves the active subscription. Premium's plan slug is "value_bundle" (underscore); all other plan slugs use hyphens. For plan slugs, prefer those returned by wpcom/plans-list.
Returns the WordPress.com hosting plan catalogue (Personal, Premium, Business, Ecommerce) with prices in the user's currency and entitlements mapping each feature to the tiers that include it, from the rules WordPress.com enforces (plugin and theme installs and uploads, theme tiers, custom domain, SFTP/SSH and more) and storage in GB. Pass "wpcom_site" (numeric blog ID or site URL/slug like "example.wordpress.com") to also receive intro offers, downgrade paths, and a ready-to-purchase checkout_url on each row. Without "wpcom_site" checkout_url is null on every row. Use this to help users select or upgrade WordPress.com hosting, so you can answer questions like "where can I host my website?", "how much does WordPress.com cost?", "can I install plugins?", or "which plan lets me sell products on my site?". For capability questions, use entitlements: find the group containing the feature, and its plans are every plan that includes it. For a specific theme, find its tier (personal, premium, partner, woocommerce) and look for the matching <tier>-themes feature. Ask the user which site to upgrade before starting checkout.
Manage site collaborators on a 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.
Manage plugins on a site: list installed plugins, search the marketplace catalog, install, upload, 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.
Manage content on your 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.
Query site design context. Operations: theme.active (active stylesheet slug), theme.presets (the theme's color palette, fonts and spacing tokens, plus core's default palette, font sizes and spacing, before Global Styles), theme.styles (the theme's own block/element styles, before Global 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.
Read and modify site structure: templates, template parts, navigation menus (classic and block), classic theme widgets, 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 sidebars.list -> widgets.list, or global-styles.get). For FSE block types use site-editor-context blocks.allowed with the site-editing context.
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.
Manage site-level settings and infrastructure for a site. Covers: settings, statistics, users, activity log, and theme management (theme.list to browse available themes, theme.set to activate one). Every write operation requires the user's explicit approval before it runs. Workflow: "list" to discover operations, "describe" for parameter schema, "execute" to run. Always share results with the user.
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 requir…
Submit feature requests, bug reports, or general feedback about the WordPress.com, Jetpack, 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".
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.
Secure AI access to manage your WordPress.com Manage and create on your WordPress site through a conversation with Claude. Ask Claude to find a post, check your stats, draft something new, update a page, or pull up a comment thread. Your sites stay secure — Claude only gets access to what you approve, nothing more.
Your site already knows your style — your theme, your colors, your fonts, every creative decision you've made. Claude can see all of it, so when it helps you create, the content actually fits.
60+ abilities. Every change is confirmed by you. Available on all paid WordPress.com plans and any Jetpack AI or Complete-connected site.
For developers: Under the hood, this connector is powered by the WordPress.com MCP server. It uses OAuth 2.1 to ensure agents only access the resources you've explicitly approved, making it easy for you to build and extend AI-driven workflows on top of WordPress.
The WordPress.com remote MCP server is a hosted Model Context Protocol endpoint at https://public-api.wordpress.com/wpcom/v2/mcp/v1, so AI assistants can connect to it without installing or running anything locally.
Add the endpoint https://public-api.wordpress.com/wpcom/v2/mcp/v1 to any MCP-compatible client such as Claude Code, Cursor, or VS Code. The setup snippets on this page configure each client in one step.
Yes. WordPress.com uses OAuth: the first time you connect, your MCP client opens a browser window to sign in and authorize access, then reuses the credentials for future sessions.
WordPress.com exposes a Streamable HTTP endpoint, the transport used by remote MCP servers and supported by all major MCP clients.
AdaptlyPost: Schedule and publish social posts to Instagram, TikTok, YouTube, X, Facebook, LinkedIn, Pinterest, Threads, and Bluesky from any MCP client.
The 9apes MCP server lets an AI assistant read the GitHub Actions data 9apes already collects for your organization: runs, jobs, steps, and their durations. Ask it why a build got slower, which jobs take the longest, or
%20-%20Sarah%20Xu.svg){kind=icon}
Manage your Adobe Experience Manager content
Pay-per-use data and tools for AI agents: crypto token safety and rug checks, web search with cited answers, page-to-Markdown, up-to-date library docs, package safety, company research and UK/EU open data. 160 tools, 20
App Store keyword research, rank tracking, competitor analysis and authorized performance data.
Comments