WordPress Custom Fields MCP that reads the schema before writing values.

Where each framework keeps its definitions decides what an agent can edit

Before comparing field types, ask where the plugin stores the shape of your data. A definition saved in the database can be read and changed by an ability; one written in a PHP file can only be read, and the fix has to be made in that file. Every framework in this category lists its records with a source label, so an agent can tell you up front which ones are off limits.

• Advanced Custom Fields keeps groups as internal posts, can mirror them to an acf-json folder, and also accepts groups registered in code. Database and JSON groups are editable; PHP groups are listed as not editable.
• ACPT has no code-registration route at all. Everything sits in its own tables, so every definition it lists can be changed from a prompt.
• Meta Box saves builder-made groups, post types, taxonomies, settings pages and relationships as posts, but only with the matching extension active. Anything added through its filters in code is read-only.
• JetEngine keeps post types, options pages and custom content types in its own tables and all meta boxes in one option row. Records registered from PHP refuse edits.
• Pods stores every pod, group and field as one object model, and every field must belong to a group. Advanced Content Types get a table of their own rather than living in wp_posts.
• Admin and Site Enhancements stores definitions as posts. On its free edition only the setup check registers; field groups, values, post types and taxonomies need ASE Pro.

How much of a custom-data change you can take back

This is the comparison that matters most once a site is live, and the frameworks differ sharply. The general rule: value writes addressed to a post can usually be restored from the change ledger with rollback-change, while definition changes rarely can.

• ACF, ACPT and ASE: post value writes roll back. Term, user and options values, and schema edits, are recorded without a before-image. An ASE create can be undone because the new definition is trashed.
• Meta Box: post value writes roll back, except while MB Custom Table is active, when every value write is logged as irreversible.
• JetEngine: only meta box writes are restorable. Post types, options pages, CCT definitions and CCT records are not.
• Pods: every pods-* write is logged without an undo, so treat each schema change as a migration and keep a backup first.

Custom post types with an AI agent: the create is easy, the delete is not

ACF, ACPT, ASE, JetEngine, Meta Box and Pods can all register a post type and a taxonomy from a prompt, and that half carries less risk because no content depends on a type that did not exist yet. It is not risk-free: a new type or taxonomy claims a slug and a URL base, which can collide with an existing page's address or another plugin's type, so check its archive URL and a nearby page on staging before registering it on a live site. Deleting one is where the frameworks protect you in different ways. Most keep the posts and leave them under an unregistered type unless you pass an explicit flag to remove them too, and ACF needs force before it deletes a type that still has content. Orphaned posts are invisible in wp-admin but still in the database, so ask the agent to count the items of that type before any delete.

ASE refuses a slug that collides with a core type such as post, page or attachment, and will not rename an existing slug at all, which means a rename there is a delete and a create. If permalinks or menus point at the old slug, plan the redirects before the change, not after.

One writer for the same value on many posts

Backfilling a field across a catalogue is a different job from editing one record. fields-bulk-update-values writes up to 100 posts per call through whichever field plugin is active, using that plugin's own save routine rather than a raw meta key: ACF, Meta Box, Pods, ACPT, ASE Pro or JetEngine. A dry run returns each post's current and planned value, and the real write needs confirm. When two field plugins are active on the same site, pass the provider so the agent does not guess.

Each written post gets its own ledger row. Inspect its provider, before-image and recovery support before offering a post-by-post undo. The exceptions follow the storage: Pods post types that keep fields in their own table, and Meta Box while MB Custom Table is active, are recorded as irreversible.

When the field plugin has its own AI surface

Two plugins in this category now ship agent access of their own. Recent ACF releases register acf/* abilities that each item must opt into with an Allow AI Access toggle; they do not cover options pages. JetEngine runs an MCP server of its own, with add-style tools for listings, queries, relations and glossaries that GoBuildWP does not offer. Separate vendor routes may be configured alongside GoBuildWP, but coexistence and their installed tool contracts need a staging test. Use each route only for its documented task and inspect its own permission, approval and recovery boundary. Check which of the two your client actually called when you review a change.

Displaying field values: where Dynamic Shortcodes fits

Dynamic Shortcodes is the odd one out here: it stores no fields, it prints them. It resolves values at render time from the data plugins it detects, ACF, Meta Box, Pods, JetEngine and ACPT among them. An agent can compose and validate a shortcode freely, but evaluating one runs it against the live site, and creating a Power Shortcode is closer to publishing code, since every author can then use it. Keep that last step for an administrator to approve.

A prompt to run before any schema change

“List every field group, post type and taxonomy on this site with its source and whether you can edit it. For the group I want to change, show the schema, how many posts hold values under each field, and which of my intended changes the change ledger could undo. Do not write anything yet.” The answer helps scope the work; schema changes still need a backup, staging review and checks of dependent templates and queries. The fields reference lists what the bulk writer accepts, and each integration page above covers its own framework in detail.