JetEngine MCP for custom content types and their records

Working through CCT records in volume

Most day-to-day JetEngine MCP work is not schema at all. It is finding and correcting rows: directory entries with a wrong phone number, products whose warranty changed, events with a missing venue. jetengine-list-cct-records pages through a CCT fifty rows at a time by default and up to two hundred, sorts on any column, and takes a where object for simple equality filters that are ANDed together. That is enough to answer 'which rows have status draft and city Leeds' without SQL.

Changes then go row by row through jetengine-edit-cct-record, which writes only the fields you send and returns the merged record. Selecting by key_field_value, such as a SKU, is safer than by _ID when the agent is working from a spreadsheet the client sent, because the spreadsheet never knew the auto-increment numbers.

• A new row whose key value already exists is refused with cct_record_key_collision, so imports cannot silently duplicate a SKU.
• A field name the CCT does not define returns cct_invalid_field rather than being dropped.
• None of these record writes can be rolled back from the change log, so for a large correction export the affected rows first with list-cct-records and keep that output.

A schema export before every CCT migration

jetengine-get-cct returns a definition in the same shape jetengine-create-cct accepts, minus the read-only extras. Saving that output before an edit gives you a schema export you can recreate the type from, which is the minimum the workflow checks ask for alongside a database backup. On a site running a supported backup plugin, backup-status shows whether a recent good backup exists before anyone touches db_field_data.

Plan field changes around what edit-cct refuses. Renames, SQL type changes and moving the key flag are rejected before any write, so a change of format means adding a new field, copying values across with record edits, and only then removing the old field with an explicit confirm. Each step can be checked on its own, and the destructive one comes last.

JetEngine post types and meta boxes: what replaces what

JetEngine post types come back in JetEngine's grouped shape: general_settings, labels, advanced_settings and meta_fields. jetengine-edit-post-type merges each group you send key by key, but meta_fields replaces the whole array, and the slug cannot be changed here at all because existing posts would need remapping. Types that WordPress or another plugin registers are not in JetEngine's store and return post_type_not_found.

Meta boxes follow a similar rule with a sharper edge. Sending args.allowed_post_type or args.visibility_conditions replaces that list, so attaching an existing meta box to one more post type means sending every post type it should keep. The upside is that meta boxes live in one option row, so a meta box edit is the JetEngine change the GoBuildWP change log can restore if the result is wrong.