Skip to main content
Glama
Sign In
MCP Hub

MCP Hub

by airano-ir
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

WordPress: Wp menu set

wordpress_specialist_wp_menu_set
Destructive

Replace all items in a WordPress navigation menu, including adding, updating, and deleting entries, with permission validation before any mutation.

Instructions

[UNIFIED] Full-replace a nav-menu's items. Pass the complete items array — items not in the array are deleted, new items are created (omit id or set it to 0), existing items (matched by id) are updated. Slug stays frozen so the theme_location mapping survives. Optional name renames the menu. S-22: each item's object_id is validated against the caller's read permissions — post_type items require read_post on the target; non-public taxonomy items require the taxonomy's assign_terms cap; custom URL items skip the object check. Validation runs across every item before any mutation, so a refusal mid-array leaves the menu untouched. Requires Airano MCP Bridge v2.17.0+ and manage_options.

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>",
      "menu_id": "<menu_id>",
      "items": "<items>"
    },
    "name": "wordpress_specialist_wp_menu_set"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNo
siteYes
itemsYes
menu_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv3.14.0

TDQS

A4/5.0
Behavior3/5

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

Adds substantial behavior beyond annotations: deletion of omitted items, creation/update matching rules, the atomic pre-validation pass, per-item permission checks (read_post, assign_terms, custom URL exemption), and the frozen slug. The annotations already declare destructiveHint=true, so the description is adding real context rather than carrying the whole safety burden alone — but there is a slight tension in that a pure full-replace that is applied identically twice yields the same state, while idempotentHint=false; the description does not clarify that orthogonal detail.

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?

Front-loaded with the core semantics in the first sentence and the lifecycle rules right after, then prerequisites last. It is dense but nearly every clause adds information; the 'S-22' internal tag is noise for an external caller.

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

Completeness3/5

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

Covers mutation semantics, atomicity, permission validation, and version requirements for a destructive four-parameter tool with no output schema, which is strong. Completeness is capped by the unexplained 'site' parameter, the undocumented shape of item objects, and no statement about what the call returns or how refusals are surfaced.

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?

With schema coverage at 0% and items typed only as a bare array of untyped objects, the description carries the load: it explains that items are matched by id, that omitting id or setting 0 creates new items, and that item kinds (post_type, taxonomy, custom) have different validation paths. It does not explain 'site' at all and does not enumerate the item fields (e.g. title, url, parent), leaving a real gap.

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 ('Full-replace a nav-menu's items') and immediately distinguishes the operation from read-oriented siblings (wp_menu_get/wp_menu_list) by emphasizing complete-array replacement semantics. An agent can tell exactly what class of operation this is 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?

Gives clear usage context: pass the complete items array, omit/zero id for creation, existing ids are updated, anything absent is deleted. It also states prerequisites (Airano MCP Bridge v2.17.0+, manage_options). It stops short of naming an alternative for partial edits or reading menus, so a 4 rather than 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