wp_delete_term_meta: delete a permitted custom field
Use this operation for an identified content field. Internal plugin storage, credentials, permission settings, script configuration and keys beginning with an underscore are excluded. An empty or omitted key never returns a metadata dump.
Arguments
| Argument | Required | Meaning |
|---|---|---|
term_id |
Yes | Target term ID |
key |
Yes | One permitted field key |
dry_run |
No | JSON true previews without writing |
Requirements
The authenticated user needs manage_categories, the taxonomy's edit capability and access to this term metadata. Writing also requires Allow content writes and the corresponding write scope.
A key must be a WordPress-registered term field exposed through REST on a public taxonomy. The target must be supported content in this site. Site administrators can inspect field definitions in the native administration interface; do not guess internal keys.
Use and verify
- Identify the field from its supported native definition.
- Read that explicit key on the intended term.
- Preview the operation, apply it within the requested scope and read the field again.
Deletion removes that key from the selected object. It does not remove the field definition or other objects. Read the value first and check the owner's expected empty/default behavior.
pom_ai_mcp_meta_denied means the key, target or metadata permission is outside this operation. Use dedicated tools for SEO, featured images, layouts and script assignment. A write gate or capability error requires the site owner to grant the intended access. Field changes are not a site-wide undo mechanism; retain the previous value when recovery matters.
Related: MCP security and access.