Skip to main content
Glama
Sign In
MCP Hub

MCP Hub

by airano-ir
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

WordPress: Wp bulk term update

wordpress_specialist_wp_bulk_term_update
Destructive

Update multiple WordPress taxonomy terms in one call by passing term IDs and fields, receiving per-item success or error status.

Instructions

[UNIFIED] Fan-out update across multiple terms in a single taxonomy via stock REST wp/v2/{taxonomy}/{id}. taxonomy is the REST base — categories, tags, or a custom taxonomy's rest_base. Pass updates=[{id, ...fields}] where each item carries the id plus whichever term fields to write (name, slug, description, parent, meta). Returns [{id, status:'ok'|'error', error?}]. Per-item manage_terms (or the taxonomy-specific edit cap) is enforced server-side. S-26: 50-item cap per call. Concurrency is bounded to 10 in flight.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "site": "<site>",
      "taxonomy": "<taxonomy>",
      "updates": "<updates>"
    },
    "name": "wordpress_specialist_wp_bulk_term_update"
  }
}

Input Schema

NameRequiredDescriptionDefault
siteYes
updatesYes
taxonomyYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv3.14.0

TDQS

A4.5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the destructiveHint/idempotentHint annotations: it discloses the 50-item cap per call, the 10-request concurrency bound, and that per-item manage_terms capability is enforced server-side. It also reveals the per-item result contract ([{id, status:'ok'|'error', error?}]), which signals partial-success semantics that annotations leave opaque.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One dense paragraph, front-loaded with the endpoint and the primary data shape, and no wasted sentences. Minor noise from internal markers ('[UNIFIED]', 'S-26:') that carry no meaning for an agent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive bulk mutation with no output schema, it supplies limits, auth enforcement, concurrency, and the return shape, which is close to everything needed to call it safely. Remaining gap is the site parameter and what happens to the rest of the batch when some items fail beyond the per-item status field.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must carry the load, and it largely does: taxonomy is explained as the REST base with concrete examples (categories, tags, custom rest_base), and the updates item shape is spelled out with the writable fields (name, slug, description, parent, meta). The site parameter is never described, leaving one of three params undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource — 'Fan-out update across multiple terms in a single taxonomy' — and pins the underlying endpoint (wp/v2/{taxonomy}/{id}), which distinguishes it from the sibling bulk_post_update that operates on posts rather than terms. An agent can tell what is written and at what scope without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Clear context for when this is the right tool: multiple terms within one taxonomy, with the 'single taxonomy' constraint implicitly excluding mixed-taxonomy batches. It never names an alternative (e.g. the single-term create sibling) or states explicit when-not conditions, so it stops short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools