AI workers for WordPress.com
Ready-made AI workers for WordPress.com: blog drafts arriving on schedule, comments triaged instead of piling up, content kept fresh, and every write a tool you deliberately granted — on the WordPress.com and Jetpack-connected sites your login already manages.
What is an AI worker for WordPress.com?
An AI worker for WordPress.com is an AI agent scoped to one job on your sites — drafting the week's post, summarizing and triaging comments, keeping content current, or tending a custom domain's DNS. It works through your own WordPress.com connection to Automattic's official MCP server, it is bound by your WordPress role on each site, and every tool it may call, reading or writing, is granted individually when the worker is set up.
What these workers do
Keep the blog on its cadence
A draft post arrives on schedule, written to the brief in the worker's instruction and aligned to the theme's own styles, ready for a person to review and publish.
Triage the comment queue
New comments get read, summarized and flagged on a schedule — spam-shaped ones surfaced, questions collected — so moderation is a ten-minute review instead of an evening.
Keep content current
Pages and posts get checked against what they should say — dates, prices, seasonal copy — and updated as drafts where they have drifted.
Write on-brand by construction
The theme-context tool hands a worker the site's active theme presets, so generated content uses the site's own colors and sizes instead of hard-coded values.
Tend a custom domain deliberately
A dedicated worker holds only the DNS tools and one domain, applying planned record changes and restoring defaults — never sharing a binding with content work.
How an AI worker runs in WordPress.com
Every tool is a separate grant
Family tools, kept honest three ways
What has to be true at WordPress first
Domains are the sharp edge
What WordPress workers are actually for
WordPress.com questions, answered.
Which sites can a worker reach?
The sites your WordPress.com login can reach — both WordPress.com-hosted and self-hosted sites connected through Jetpack — and on each site, only what your WordPress role allows. Administrators reach everything MCP exposes, editors reach content and comments but not settings or plugins, and lesser roles reach less. You can also exclude individual sites from MCP entirely in your WordPress.com preferences, and each worker is further narrowed to the tools you bound to it.
Can a worker publish without a human?
Only if you shape it that way. Posts a worker creates are drafts by default, publishing is a distinct operation, and WordPress.com additionally requires an explicit confirmation inside every write call. The recurring shape that works is draft-first: the worker prepares content on its schedule and a person publishes, or one deliberately-configured worker holds the publish step and nothing else.
Can it break my domain or email?
Only if you bind it the domain tools, which is why they are separate from everything else. The DNS, nameserver and mail-service tools change where a domain's website and email actually resolve, and the copy on each one says exactly that. Bind them to a dedicated DNS worker with one domain named in its instruction, or to nobody — a content worker never needs them, and without the binding it cannot touch them however it is prompted.
A tool is bound but calls fail — why?
Almost always one of WordPress.com's own gates rather than the connection: the site's plan (MCP needs a paid plan; free sites get 30 days), the account-level Enable MCP access toggle in your AI and MCP preferences, a site excluded from MCP there, or your WordPress role on that site being below what the operation needs. Check those four in order; reconnecting rarely changes anything because the connection was never the problem.
Is there a record of what a worker did?
Yes, twice over. Every call a worker makes through this connection is logged with the worker, the tool and the time, reads and writes alike. WordPress keeps its own history too — post revisions, comment moderation logs and account activity — so a change that appeared overnight can be traced to the run that made it, and compared against everything people did around it.
What AI workers can do in WordPress.com
The tools a worker can be granted in WordPress.com once you connect it. A kit grants only the ones its job needs, and you can narrow them further on the worker.
Wpcom checkout URL
Generate a WordPress.com checkout link for a plan or product. Nothing is purchased by the tool — a human completes checkout in their own browser.
Wpcom domain purchase
Search available domains with prices and produce pre-built registration checkout links. Search and links only — purchasing stays with a human in the browser.
Wpcom domain restore default dns records
Reset one custom domain to WordPress.com's default A records or the default www CNAME — the recovery move after DNS experiments.
Wpcom domain set mail service
Point one custom domain's mail records at a mail service — changes where the domain's email is delivered.
Wpcom domain update dns records
Add or remove DNS records (A, AAAA, CNAME, MX, TXT, SRV, …) on one custom domain. Misconfigured DNS breaks email and websites, so bind this only to a worker whose job IS DNS, and have it read current records first via the account tool.
Wpcom domain update nameservers
Set the nameservers on one custom domain — this transfers DNS control entirely, the heaviest domain write here. Requires managing the site the domain is connected to.
Wpcom mcp account
The connected user's own account behind one action-based tool — profile and account-level resources, including domain DNS record reads (domains.dns_records). Operates on the authenticated user, so it takes no site id.
Wpcom mcp content authoring
Create, edit and manage content on one site: posts, pages, comments, media, categories, tags and content search — a family of operations behind one action-based tool (action: list/describe/execute, operation like posts.create). Posts create as drafts by default, and every write requires user_confirmed inside the call.
Wpcom mcp site
Site administration on one site behind one action-based tool: settings, plugin status, site users. WordPress role-gates it server-side — admins see everything, editors much less.
Wpcom mcp site editor context
Read one site's active theme and its presets — colors, sizes, style slugs — so content a worker writes uses theme-aligned presets instead of hard-coded values. The vendor recommends calling it before authoring.
Wpcom plans list
List WordPress.com plans with pricing — reference data when a job needs to reason about plan features or upgrades.
Wpcom user sites
List every site the connected login can reach — WordPress.com-hosted and Jetpack-connected self-hosted alike — with the site ids the site-scoped tools need, plus optional per-site metrics. The usual first call of any job.