Pods
These abilities register when Pods is detected on the site and a Pro licence is active. If either is missing the module stays absent rather than failing at call time.
At a glance
Pods registers 25 abilities: 9 that only read, 12 that write, and 4 marked destructive. That split is the practical answer to how much of this module can run unattended. Reads cost nothing and are safe to repeat, so discovery is the part to be generous with; the writes are where review belongs, and the destructive calls stop for an explicit confirmation every single time regardless of which profile is active.
What this module is for
Operate Pods, custom post types, taxonomies, settings pods, fields, groups, items, and extensions of built-in content types through WPPilot Pro.
Before you rely on it: Schema changes should be treated as migrations and tested against Pods templates and relationships.
Typical workflows
- Inspect a Pod before creating or editing items
- Add a field to the correct group from its type schema
- Extend a built-in type only after reviewing existing fields
The Pods integration page covers the same module from the workflow side, with the capability map and the questions worth asking before a first write.
Availability on your site
The Pods module needs three things at once: WPPilot Free as the MCP foundation, an active Pro licence, and the companion plugin detected on the site. Miss any one and the module does not register, which is deliberate: an ability that appears in the tool list but fails at call time is worse than an ability that was never offered. What the connected agent can actually call is then narrowed twice more: by the safety profile active on the site, and by the WordPress capabilities of the user behind the credential. A read that succeeds for an administrator can be absent entirely for an editor.
Every write these abilities perform is recorded in the change ledger, and destructive calls can be routed through the approval queue so a person signs off before anything is applied. A successful tool result means the operation returned, not that the front end, the cache, and every dependent template are correct: that still needs a look.
Reads
Available in every safety profile, including Read Only. Inspection costs nothing and is not rate limited.
| Ability | What it does |
|---|---|
wppilot/pods-check-setupCheck Pods Setup | Reports the Pods environment: version, whether the API surface is loadable, the Advanced Content Types component (required by pods-create-act), the count of pods registered in the DB, and any actionable issues. Run this before any Pods write to confirm the runtime is ready. |
wppilot/pods-get-fieldGet Pods Field | Returns a single Pods field with every type-specific key Pods stored, flattened into the field object at the top level (Pods' Whatsit model does not nest options separately). Use this when you need to inspect or copy an existing field's configuration. |
wppilot/pods-get-field-type-schemaGet Pods Field Type Schema | Returns the agent-relevant options keys for a single Pods field type (e.g. pick, file, number). Each entry has key, type, and a one-line description. Call this before pods-create-field when you need to set type-specific options like pick_object, file_format_type, or number_decimals. Field types not listed here still accept any option keys Pods recognises — this is a hint surface, not a strict schema. |
wppilot/pods-get-itemGet Pods Item | Returns a single item from a pod with all its field values resolved (relationships expanded into IDs, files into attachment IDs, etc.). Use fields to project specific keys when the full payload is too large. |
wppilot/pods-get-podGet Pod | Returns the full schema of a single pod: identifying info (id, name, type, storage, object), the options blob (label, description, public flags, REST settings, …), and the field/group structure. Use this to introspect the schema before editing or to verify what create-cpt / create-taxonomy / create-act actually wrote. |
wppilot/pods-list-fieldsList Pods Fields | Lists every field defined on a pod. Output is compact: name, label, type, group_id, weight. Use pods-get-field for the full options blob of a single field. |
wppilot/pods-list-groupsList Pods Field Groups | Lists every group defined on a pod, compact form: id, name, label, weight. Use this instead of pods-get-pod include_groups=true when you only need the group list — keeps the response small and avoids loading every field at the same time. |
wppilot/pods-list-itemsList Pods Items | Lists items in a pod, paginated. Returns each item as {id, fields}. Pass fields to project specific keys (default: every field on the pod) — useful when items have a wysiwyg / large blob you do not need in the listing. |
wppilot/pods-list-podsList Pods | Lists every Pod (CPT, taxonomy, ACT, settings page, extended built-in) registered through Pods. Output is compact: id, name, label, type, storage, object. Use pods-get-pod for the full schema (fields, groups, options) of a single pod. |
Writes
Gated by the active profile and your WordPress capabilities. Rate limited to 120 per minute per credential.
| Ability | What it does |
|---|---|
wppilot/pods-create-actCreate Pods Advanced Content Type | Creates a brand-new Advanced Content Type — a Pods-managed content collection backed by a dedicated database table (wp_pods_<name>) instead of postmeta. Use this when you need scale, fast queries, and data that should not pollute the WP posts table. Requires the Advanced Content Types component to be active (pods-check-setup reports act_component_active). |
wppilot/pods-create-cptCreate Pods CPT | Creates a brand-new Pods-managed Custom Post Type. To attach Pods fields to an existing post type (post, page, attachment, third-party CPT), use pods-extend-builtin instead. After creation use pods-create-field / pods-create-group to model the schema. |
wppilot/pods-create-fieldCreate Pods Field | Adds a new field to a pod. Pods 3.x requires every field to belong to a group — pass group (or group_id). If the pod has no group yet, call pods-create-group pod=<pod> name=details first. For type-specific options (e.g. pick_object, file_format_type, number_decimals) call pods-get-field-type-schema field_type=<type> to discover option keys, then pass them in options. |
wppilot/pods-create-groupCreate Pods Field Group | Adds a new field group to a pod. Pods 3.x requires every field to belong to a group — call this once per pod before any pods-create-field. |
wppilot/pods-create-itemCreate Pods Item | Creates a new item in a pod. data is a flat field_name => value map. For post-type pods the standard WP fields (post_title, post_status, post_content) work alongside Pods custom fields. For pick (relationship) fields, pass an item ID (single) or an array of IDs (multi). |
wppilot/pods-create-settingsCreate Pods Settings Page | Creates a brand-new Pods Settings Page — a custom admin screen whose fields are stored in wp_options and queryable via pods_v / pods_field. Use this for site-wide configuration (e.g. social URLs, footer text, contact info) that does not belong on a single post. |
wppilot/pods-create-taxonomyCreate Pods Taxonomy | Creates a brand-new Pods-managed Taxonomy. To attach Pods fields to an existing taxonomy (category, post_tag, third-party), use pods-extend-builtin instead. After creation, attach the taxonomy to one or more post types via the built_in_post_types_<post_type> options. |
wppilot/pods-edit-fieldEdit Pods Field | Updates an existing Pods field — label, type, weight, options. Pass only the keys you want to change. To rename, set new_name. |
wppilot/pods-edit-groupEdit Pods Field Group | Updates a field group: rename, re-label, reorder, change options. |
wppilot/pods-edit-itemEdit Pods Item | Updates field values on an existing item. Pass id for content pods (post_type, taxonomy, ACT). For settings pods the id is irrelevant — pass any integer; values are merged into the option storage. Only the keys present in data are touched; unset fields keep their existing value. |
wppilot/pods-edit-podEdit Pod | Updates an existing Pod definition — labels, description, public flags, supports, menu, REST settings, custom options. Pass only the keys you want to change; existing options are preserved. To rename the pod, set new_name (renames the post type / taxonomy / table accordingly). |
wppilot/pods-extend-builtinExtend Built-in WP Object with Pods | Registers a Pods-managed wrapper around an existing built-in object so you can attach Pods fields to it. Targets: existing post types (incl. post, page, attachment, third-party CPTs), existing taxonomies (category, post_tag, …), user, comment, and media. After the wrapper is created, attach fields with pods-create-field. |
Destructive
Marked destructive in the source, so each call needs an explicit confirmation flag, every time.
| Ability | What it does |
|---|---|
wppilot/pods-delete-fieldDelete Pods Field | Deletes a Pods field. Removes the field schema; values stored for this field are wiped from the storage layer (postmeta / table column / option). Irreversible. |
wppilot/pods-delete-groupDelete Pods Field Group | Deletes a field group. By default fields in the group are preserved (re-parented to no group); pass delete_fields: true to delete them along with the group. |
wppilot/pods-delete-itemDelete Pods Item | Deletes a single pod item. For post-type and taxonomy pods the underlying WP post / term is also removed (posts go to trash, terms are deleted permanently). Pass delete_wp_object: false to keep the WP object and only wipe the Pods-managed data — useful when extending built-ins where the post is shared with other code. ACT items are always permanently removed (custom-table pods have no trash). |
wppilot/pods-delete-podDelete Pod | Deletes a Pod definition. By default the underlying WP objects (posts, terms, ACT rows) are preserved — pass delete_items: true to wipe them as well. Irreversible. |