👁 5 views
Advanced Custom Fields has been indispensable to WordPress development for over a decade. It gave developers a clean GUI and a powerful API to do what WordPress core made clunky: adding structured data to posts, pages, and custom post types. For most of ACF’s life, that was an enormous value proposition.
But something has shifted. We’ve spent the last several months building and testing an MCP abilities plugin that lets AI agents manage ACF programmatically — creating field groups, populating repeaters, managing galleries, registering custom post types, all through natural language. The plugin works. The 84 abilities we built achieve a 90.9% success rate with zero crashes. By any reasonable measure, it’s a success.
And yet, the most interesting thing we learned during development had nothing to do with ACF at all.
The Moment the AI Went Around Us
During our testing cycles, we’d give Claude tasks like “create a Projects custom post type with a Project Type taxonomy and fields for client name, budget, and deadline.” The expected workflow was clear: the agent would call our ACF abilities to register the CPT, create a field group, define the fields, and wire everything together.
Instead, Claude kept trying to skip ACF entirely.
Given access to WordPress core through MCP, the AI’s instinct was to call register_post_type() and register_taxonomy() directly, then use WordPress’s native post meta system for the custom data. No field groups. No field definitions. No ACF abstraction layer at all. It wanted to talk straight to WordPress.
The AI didn’t see ACF as a feature. It saw it as a detour between the intent and the outcome.
We had to actively redirect it to use our ACF abilities — which, to be fair, is what the testing required. But the pattern was revealing. An AI agent doesn’t need a pretty GUI to define a text field. It doesn’t need drag-and-drop to reorder repeater rows. It doesn’t need a visual interface at all. It needs a clear schema and a direct path to the data layer.
What ACF Actually Does (and Doesn’t Do)
It’s worth being precise about what ACF provides. At its core, ACF does three things:
A registration layer. ACF gives you a GUI to register custom post types, taxonomies, and field groups — things WordPress can do natively through PHP functions like register_post_type(), register_taxonomy(), and register_meta(). ACF’s GUI is genuinely excellent for humans. But for an AI agent, the GUI is invisible. The agent needs an API, and WordPress already has one.
A data abstraction. ACF wraps WordPress’s native postmeta table with its own key conventions and helper functions like get_field() and update_field(). This is convenient for developers writing PHP templates, but it’s a proprietary layer over a system that already works. WordPress’s get_post_meta() and update_post_meta() do the same job without the dependency.
Complex field types. This is where ACF genuinely adds capability. Repeater fields, flexible content layouts, gallery fields, and options pages don’t have native WordPress equivalents. These are real features that solve real problems — particularly for content-heavy sites with structured, nested data.
The question is whether that third category justifies the overhead of the first two — especially when the operator is an AI agent rather than a human developer clicking through wp-admin.
What an Agent Can Already Do Through WordPress Core
Our wp-mcp-core plugin — the foundation layer beneath the ACF abilities — already exposes 85 abilities that talk directly to WordPress without any third-party plugins. Through MCP, an AI agent can already:
Create and manage content — posts, pages, and custom post types with full CRUD operations, categories, tags, and custom taxonomies.
Handle media — upload, update, delete, search, and retrieve metadata for any attachment in the media library.
Manage users and roles — list users, get user details, understand role capabilities.
Work with the block editor — list block types, patterns, and reusable blocks.
Administer the site — themes, plugins, menus, comments, site options.
Notably, WordPress core already supports custom post type and taxonomy registration. The wp-mcp-core abilities for listing post types and taxonomies work today. And the WordPress REST API, which MCP servers typically communicate through, already handles post meta — meaning an agent can read and write custom fields on any post without ACF installed at all.
For straightforward structured data — text strings, numbers, dates, boolean flags, simple relationships — WordPress post meta is sufficient. The agent doesn’t need ACF’s field type validation or its admin UI. It knows what data types it’s working with because it’s the one writing the data.
Where ACF Still Earns Its Place
None of this means ACF is irrelevant. There are real scenarios where it remains the right tool:
Legacy installations. If your site already has hundreds of posts with ACF field groups, repeaters, and flexible content layouts, the data is stored in ACF’s conventions. Migrating away from ACF means restructuring your meta key naming, updating all your theme templates, and potentially losing the nested data structures that repeaters and flex content provide. The MCP ACF abilities plugin exists precisely for this use case — to make existing ACF installations manageable through AI rather than requiring developers to manually click through the admin.
Complex nested content. WordPress post meta is flat. If you genuinely need repeating groups of sub-fields (like a list of team members each with a name, role, photo, and bio) or modular page layouts (flexible content), ACF’s data model handles this in ways that raw meta doesn’t. An agent could implement its own serialization scheme, but ACF’s is battle-tested and every theme and page builder in the ecosystem already knows how to read it.
Human editorial workflows. If non-technical editors regularly create and update content through wp-admin, ACF’s field UI is genuinely valuable. Dropdown selectors, date pickers, image uploaders, and relationship fields make the editing experience dramatically better than raw meta boxes. AI doesn’t replace editors — it augments them.
Ecosystem compatibility. With over 2 million active installations, ACF is deeply integrated into WordPress themes, page builders, and plugins. Elementor, Beaver Builder, Bricks, Breakdance — they all have first-class ACF support. If you’re building within that ecosystem, ACF isn’t overhead; it’s infrastructure.
The Uncomfortable Middle Ground
Here’s where it gets honest. For new WordPress installations being primarily managed by AI agents, the argument for installing ACF is weaker than it’s ever been.
Consider the workflow. An agency using Master Control Press to manage client sites through AI would typically: create custom post types, define content structures, populate content, and maintain it over time. If the AI agent is doing the creating, populating, and maintaining — and if the content structure is straightforward enough that WordPress core post meta can handle it — then ACF is a dependency that adds complexity (140+ database entries for field groups and definitions), introduces a potential point of failure, and costs $49–$249 per year per site.
The question isn’t whether ACF is good software. It is. The question is whether the problems it solves are problems that AI agents actually have.
An AI agent doesn’t struggle with WordPress’s native custom fields interface. It doesn’t need a visual field builder. It doesn’t benefit from drag-and-drop reordering. These are human problems, solved with human interfaces. When the operator changes from a human to an AI, the value proposition shifts.
Our Position (and Why We Built the Plugin Anyway)
We built 84 ACF abilities because the installed base demands it. There are millions of WordPress sites running ACF today, and those sites aren’t going to rip it out because an AI can talk to post meta directly. The ACF MCP plugin is for the real world — the world where your client’s site has 47 field groups, nested repeaters three levels deep, and a flexible content layout that took six months to architect. In that world, an AI agent that can manipulate ACF programmatically is transformative.
But for greenfield builds? For new sites where AI is the primary content operator? We think the honest answer is: start with WordPress core. Use MCP to register your post types and taxonomies directly. Store your structured data in post meta. If you hit a genuine wall — nested repeating data, modular layouts, complex editorial interfaces for human editors — then install ACF and use our abilities plugin to manage it through AI.
Don’t add a dependency because it’s what you’ve always done. Add it because it solves a problem you actually have.
What Comes Next
The broader trend here isn’t really about ACF. It’s about what happens to every abstraction layer when the operator shifts from human to AI.
Page builders exist because humans need visual interfaces to arrange content. AI doesn’t. SEO plugins exist because humans need dashboards and checklists to optimize content. AI can apply those principles directly. Form builders exist because humans need drag-and-drop form creation. AI can generate form markup and processing logic natively.
This doesn’t mean these tools disappear overnight. It means their value proposition changes. They shift from being the primary interface to being compatibility layers, data standards, and editorial tools for the humans who still interact with the site directly.
ACF’s future likely looks like this: essential for legacy sites, valuable for editorial teams, and increasingly optional for AI-managed content operations. The plugin isn’t dying. But its role is narrowing — from “the way you do custom fields in WordPress” to “one of the ways, when you need it.”
We’ll keep building and improving the ACF abilities plugin because the installed base is massive and the need is real. But we’ll also keep expanding what wp-mcp-core can do natively, because for a growing number of use cases, the shortest path between an AI agent and WordPress doesn’t run through any third-party plugin at all.
