The governing idea
See the model before you change the record
A Toolset site is defined by more than post titles and content. Its post types, fields, taxonomies, relationships, Views, forms, and access rules determine what a record means and where it belongs.
Discover the structure
Inspect post types, their fields and taxonomies, field groups, forms, Views, and registered relationships before choosing a target.
Mutate the owner
Create or update the exact native post, term, field group, field definition, relationship, post type, taxonomy, or taxonomy control that owns the change.
Read back the consequence
After a mutation, inspect the resulting record or relationship so the automation can confirm what WordPress now holds.
A controlled first run
Set up the smallest safe route
Use this order when introducing the add-on to an MCP client. The sequence keeps discovery, authorization, mutation, and verification separate.
1
Install the foundation
Prepare a supported WordPress and PHP runtime, then make the required supporting components active before activating the add-on.
2
Activate the add-on
Install and activate MCP Abilities – Toolset alongside the Toolset components that own the site’s content model.
3
Inspect before acting
List the relevant post type, fields, taxonomies, relationships, users, forms, or Views and identify the exact source-owned identifiers.
4
Change and verify
Call the focused operation on the confirmed target, then retrieve the changed object or related posts to verify the outcome.
Content records and terms
Keep ordinary content work exact
These operations cover selected records and taxonomy terms without hiding the distinction between reading, changing, and removing them.
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 that are 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 authenticated user has manage_categories.
Content structures
Change the schema 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 an authorized 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 authenticated caller 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 authenticated 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 first, clean up second
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 precise Toolset surface
Download MCP Abilities – Toolset to put the native Toolset model within reach of an AI assistant. The next step is to let it inspect the exact structures before changing a record or relationship.