The governing idea
Work from the native model, not a guessed label
Before an automation touches a record, the surrounding model answers whether the intended target is a post, field, term, relationship, structure, or editor control.
Discover the structure
Inspect post types with their fields and taxonomies, field groups, forms, Views, and registered relationships before selecting a target.
Change the native owner
Use the operation the owner supports: create or update posts, field groups, and field definitions; list or create taxonomy terms; create relationships or link exact posts; create or delete post types and taxonomies; and inspect or select the taxonomy editor control for one post type.
Verify the result
After a change, retrieve the resulting post, field definition, or relationship so the assistant can compare WordPress’s stored result with the intended target.
A controlled first run
Introduce the plugin through a verified route
Use this order when introducing the add-on to an MCP client: establish the supported stack, identify the native target, then verify the result of a focused operation.
1
Prepare the foundation
Use the supported WordPress and PHP runtime, then activate the required supporting components before activating the add-on.
2
Activate the add-on
Install and activate MCP Abilities – Toolset beside the Toolset components that own the site’s post types, fields, taxonomies, relationships, Views, forms, and access data.
3
Resolve exact identifiers
Inspect the relevant post type, fields, taxonomies, relationships, users, forms, or Views and carry their registered identifiers into the next operation.
4
Act, then read back
Call the focused operation on the confirmed target and retrieve the changed object or related posts so the result is visible before the workflow continues.
Content records and terms
Operate on records and terms with explicit boundaries
These operations keep ordinary content work separate from discovery, querying, changing, and removal, so the caller can choose the least destructive action.
Create a post
Create one selected post in the confirmed post type when the target type and required native fields are known.
Inspect a post
Retrieve one exact post to see its current values before an update or relationship change.
List posts
List posts for a chosen post type when the workflow needs a bounded inventory of records.
Query posts
Query the selected content set when a repeatable filter is needed instead of an unbounded list.
Update a post
Update one exact post after confirming its identity and the fields meant to change.
Trash a post
Move one selected post to trash as the reversible default for removal.
Delete permanently
Delete one exact post permanently only when the caller explicitly enables force; the decision is not implicit.
Work with terms
List terms for a selected taxonomy or create a term when the signed-in WordPress user has manage_categories.
Content structures
Change the content model only with an exact target
Toolset structure operations affect the model itself. They are for administrators who know the registered name and the wider effect of the change.
Inspect post types
List the registered post types and inspect the fields and taxonomies attached to the selected type.
Inspect taxonomies
List the registered taxonomies and identify the exact taxonomy used by the content model.
Create a post type
Create a custom post type only from a deliberate, source-owned definition and with administrator permission.
Delete a post type
Delete the exact registered post type only with administrator permission, knowing that every post of that type is processed.
Create a taxonomy
Create the exact custom taxonomy required by the model rather than inventing a parallel classification.
Delete a taxonomy
Delete the exact registered taxonomy only with administrator permission, knowing that its terms are deleted.
Confirm the target
Use the source-owned post type or taxonomy name as the target. A similar label is not sufficient.
Respect the boundary
Structure mutations require manage_options; ordinary content permissions do not authorize them.
Fields and groups
Keep field definitions tied to their identifiers
Field work is a model change, not an anonymous metadata edit. Establish the group and field identity first.
Inspect fields
Retrieve the exact field definition and its current settings before changing it.
Inspect groups
List or retrieve field groups to understand which fields are presented together.
Create a field group
Create a group with a deliberate native identity and the fields the content model actually needs.
Update a field group
Update the confirmed group rather than creating a duplicate with a similar label.
Create or update a field
Create or update the field definition against its exact identifier and verify the resulting definition after the change.
Relationships
Link records only after both ends are known
Relationships are part of the content model. The safe route makes the relationship definition and both post targets explicit before linking them.
1
Inspect the definition
List registered relationships and inspect the relationship relevant to the workflow.
2
Inspect the post view
Retrieve the relationships for the selected post so existing links are visible before a mutation.
3
Create the relationship when needed
Create a relationship only when the model requires a new exact definition and the caller has the required structural permission.
4
Link exact posts
Add the relationship between the exact relationship identifier and the exact post IDs. A title or approximate match is not a target.
5
Retrieve related posts
Query the related posts afterward to confirm the link and give the next workflow a usable result.
Users and access
Make authorization inspectable
Toolset automation is permissioned WordPress work. These operations let a workflow understand the user model and test the current caller’s access before it acts.
Inspect user fields
Retrieve the Toolset user fields that define what user records can contain.
List users
List users only where the signed-in user has list_users; the ability does not bypass that boundary.
Inspect one user
Retrieve the selected user’s Toolset fields when the workflow has an exact user target.
List roles
List the available roles to understand the site’s current access model.
Inspect role capabilities
Retrieve the capabilities assigned to one exact role before relying on it for an operation.
List users by role
Find users assigned to the selected role when the workflow needs a bounded membership result.
Inspect one user’s capabilities
Retrieve the capabilities of one exact user to distinguish assigned access from assumed access.
Check current access
Ask whether the current user can perform the requested action before mutation; content, taxonomy, user, and administrator operations still enforce their matching WordPress capabilities.
Toolset presentation controls
Inspect the surfaces that shape the editor
Forms, Views, and taxonomy editor controls affect how a content model is used. Inspect them as native Toolset controls instead of recreating their behavior elsewhere.
List forms
List the Toolset forms available to the signed-in workflow.
List Views
List Toolset Views so the workflow can identify the native presentation surface it needs to inspect.
Inspect taxonomy control
Inspect the taxonomy editor control for one exact post type to see how taxonomy editing is configured.
Select taxonomy control
Select the taxonomy editor control for the exact post type when the workflow must change that native editor setting.
Migration boundary
Audit use before cleaning up migration residue
The usage audit is read-only. It reports concrete content markers, metadata markers, and Toolset configuration objects so a migration can be based on observed use rather than assumption.
Stale-data cleanup begins as a dry run. If mutation is justified, enable each of its three scopes explicitly: stale Toolset metadata, stale Toolset objects, and stale content attributes. Give the run a bounded limit and review the preview before allowing removal.
The add-on works with Toolset’s native model. It does not infer a new architecture, silently broaden a target, or replace a deliberate schema decision.
Runtime requirements
Install the complete supported stack
Each dependency has one job in the route from a native WordPress model to an authenticated MCP client.
6.9 or later
WordPress 6.9+Supplies the native Abilities API and the content, taxonomy, user, media, and permission interfaces used by the plugin.
8.0 or later
PHP 8.0+Provides the minimum PHP runtime required by MCP Abilities – Toolset.
Installed and active
WordPress Abilities APIRegisters the 40 Toolset operations as typed WordPress abilities.
Installed and active
WordPress MCP AdapterTransports registered WordPress abilities to authenticated MCP clients.
Installed and active
MCP Expose AbilitiesExposes the registered public abilities through the controlled Devenia MCP surface.
Installed and active
ToolsetOwns the custom post types, fields, taxonomies, relationships, Views, forms, and access data used by the matching operations.
The useful next step
Give an AI assistant a native Toolset surface
Download MCP Abilities – Toolset to put Toolset’s native WordPress model within reach of an AI assistant. It exposes typed operations for inspecting exact targets, making focused changes, and reading back the result.