Buda agents reach your WordPress.com sites through Automattic’s official MCP server, with every write tool off until you switch it on. An agent handles the reading and drafting: searching, auditing, comparing, and preparing changes.
Content problems are rarely about one post. They are about the forty posts that reference a product you renamed, or the category that quietly collected half your archive.
This integration lets agents work across the whole site: through Automattic’s official MCP server they search content, read posts and settings, and prepare changes you approve. An agent handles the reading and drafting: searching, auditing, comparing, and preparing changes.
Your content never leaves WordPress.com; what Buda adds is somewhere to audit it and stage corrections.
A chatbot can rewrite the post you paste. A WordPress-connected agent can find every post that needs the same change — searching content, reading the actual published text, checking categories and tags, and preparing the edits as a set rather than one at a time.
Instead of hunting through the admin for everything affected by a rename, you can ask:
Find every published post that still refers to the old product name, read each one, and prepare updated drafts that keep the surrounding sentence natural.
The agent searches the site, reads the content, and prepares the changes for you to review before anything is published.
Your content stays on WordPress.com. Buda is the workspace where site context meets your other systems and becomes reviewed work.
WordPress.com’s MCP server groups tools by area, with read tools enabled by default and write tools disabled until you turn them on.
Buda agents can retrieve supported information including:
Where you enable the corresponding write tools, agents can perform supported actions including:
Two boundaries matter. All read-only tools are enabled by default and write tools are disabled; you turn individual tools on in your account settings. A site-level control can block all MCP tools for all users on that site, overriding account settings. MCP access is available on WordPress.com paid plans. This integration covers WordPress.com — self-hosted WordPress.org sites are outside its scope.
Editing one post is not the problem. The problem is the work that requires reading everything you have published and holding it in view at once.
Published content drifts away from the product it describes.
Renames leave a long tail nobody finishes.
Categories and tags accumulate faster than they are pruned.
Example workflowInternal links decay as content is republished and restructured.
Comment moderation is repetitive and easy to postpone.
Site state is spread across settings, plugins, and stats.
Four patterns, each ending with a person publishing rather than an agent.
Trigger: Run at the start of each quarter.
Buda agent workflowTrigger: A product or brand term changes.
Buda agent workflowTrigger: A draft is ready for review.
Buda agent workflowTrigger: Run daily.
Buda agent workflowHand any of these to a connected Buda agent, changing the terms and sites to fit your archive.
Find published posts that still describe our old pricing model. Read each one and tell me which are getting the most traffic.
Search all content for the old product name and prepare updated drafts. Do not publish anything — show me the changes first.
List our categories and tags with post counts, flag near-duplicates and single-use tags, and propose a merge plan.
Find published posts with almost no internal links pointing to them, and suggest which existing posts should link to each.
Show me posts not updated in over a year that still get meaningful traffic, ranked by how out of date the content looks.
Read pending comments, separate real questions from noise, and draft replies to the questions using our published content.
Plugins are the right tool when the behavior is fixed and should run on every request.
For example:
Automatically generate a sitemap and ping search engines when a post is published.
An MCP-connected agent earns its place when the task requires reading content and judging what it means.
Read our published posts about the integrations feature and tell me which ones now contradict how the feature actually works.
| Capability | WordPress Plugins | Buda WordPress MCP Integration |
|---|---|---|
| Deterministic site behavior | Strong | Not the target use |
| Natural-language instructions | Not applicable | Yes |
| Reading published content for meaning | Not designed for it | Agent reads and reasons over text |
| Comparing content against external truth | Not available | Agent can combine other sources |
| Bulk edits requiring judgment per case | Find-and-replace only | Agent drafts each change in context |
| Cross-tool context | Requires separate integrations | Combines with other Buda tools |
| Explaining why a post was flagged | Not available | Yes, quoting the passage |
| Draft-first output | Depends on the plugin | Natural agent pattern |
| Write tools off by default | Not applicable | Enabled per tool by you |
For example:
Use plugins for site behavior. Use a Buda agent for the editorial work that requires reading what you published.
A published post is the end of work that happened in other systems.
The research is in a docs tool, the campaign is tracked in a project tool, the discussion happened in chat, and the performance shows up in analytics. An agent reading across them keeps the published record aligned with what is now true.
Compare published content against the source research and messaging documents.
Connect the content calendar to what has actually been published.
Turn editorial feedback in a channel into tracked, drafted changes.
Check whether content changes moved the behavior they were meant to move.
Line up the assets used in a post against the current brand versions.
Checking the archive against those systems is how published claims stay accurate over time.
Access runs through Automattic’s own server, with a permission model that starts closed rather than open.
Authentication uses OAuth 2.1, which WordPress.com documents as including PKCE, dynamic client registration, token rotation, and no client secrets. The flow is explicit that your WordPress.com credentials are never stored locally or shared with the AI client; only expiring access tokens are used.
The permission model is unusually conservative and worth using as designed. All read-only tools are enabled by default and write tools are disabled. You enable individual tools in your account settings. Separately, disabling access for a specific site blocks all MCP tools for all users on that site and overrides account-level settings — a genuine kill switch rather than a preference.
Anything an agent publishes is immediately visible to customers and search engines. A wrong edit is not an internal mistake.
Buda is arranged around it: content an agent can read, drafts a person approves, and nothing public without a human in between.
Agents can search, read, audit, compare, and draft.
People should keep approving anything involving:
The teams that gain most are the ones whose published archive has grown past what anyone can review by hand.
Audit the archive against current product truth instead of spot-checking.
Prepare terminology and consistency passes as reviewable drafts.
Find internal linking gaps and refresh candidates using real traffic data.
Inspect settings, themes, plugins, and activity across sites from one place.
Run the same audit across multiple client sites without repeating the work.
Keep configuration visible and changes reviewable, with write tools scoped tightly.
It is a connection that lets another application work with a WordPress site — reading content and settings, and changing them where the relevant tools have been switched on.
Through Automattic’s official WordPress.com MCP server. Agents authenticate over OAuth 2.1 and call only the tools you have switched on in your account settings.
No. This integration covers WordPress.com. WordPress.com’s MCP server does not support self-hosted WordPress.org installations, so a self-hosted site cannot be managed this way.
It is the arrangement that lets an agent turn an editorial task into the right WordPress.com content calls, rather than raw REST requests.
A Buda agent can search and read posts, pages, comments, media, categories, tags, block patterns, theme data, site settings, plugins, statistics, and activity logs, and — where you enable write tools — create and update content, manage media and taxonomy, and change supported settings.
Only if you enable the relevant write tools. Write tools are disabled by default, you enable them individually, and Buda’s recommended pattern keeps publishing behind human review regardless.
The connection uses OAuth 2.1 with PKCE, token rotation, and no client secrets. WordPress.com documents that your credentials are never stored on your machine or shared with the AI client; only expiring access tokens are used.
Yes. Disabling access for a site blocks all MCP tools for all users on that site and overrides account-level tool settings.
MCP access is available on WordPress.com paid plans. Free-plan sites are not covered.
No. Buda sits alongside it, using your published archive for audits, drafts, and corrections you approve.
No. The WordPress AI Assistant works inside WordPress.com on your site’s content. Buda sits outside WordPress, using your published archive for audits, drafts, and corrections that you approve before they go live.
Almost never. Those tools exist, but they affect site availability rather than content. Leave them disabled unless you have a specific reason and a person driving each change.
Most content teams know their older posts have drifted out of date. What stops them is that checking means reading everything.
Connect WordPress.com to Buda and let agents read the archive, find what no longer holds, and prepare the corrections as drafts — with write tools staying off until you decide otherwise.