Skip to main content
Glama

mcp_update_menu

Rename a WordPress navigation menu by specifying its site ID, menu ID, and new name.

Instructions

Update a navigation menu (rename)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesMenu ID
nameYesNew menu name
siteYesSite id (see list_sites)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv3.4.0
    • addedInput schema / properties / site
      Added value: +{
      +  "description": "Site id (see list_sites)",
      +  "type": "string"
      +}
    • changedInput schema / required
      Previous value: -[
      -  "id",
      -  "name"
      -]New value: +[
      +  "site",
      +  "id",
      +  "name"
      +]
  2. First observedv2.0.0

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full disclosure burden, yet it only says 'update/rename'. It does not state required capabilities, whether the change is reversible, how other menu fields (items, locations) are affected, or what a failed rename looks like.

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?

A single short phrase with the scoping hint front-loaded and no waste, though it is arguably terse enough to be under-specified rather than genuinely concise.

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

Completeness2/5

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

For a mutating tool with no annotations and no output schema, the description omits prerequisites, side effects, and result behavior; it is not sufficient on its own to call this tool confidently.

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

Parameters3/5

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

With 100% schema description coverage, the schema already documents id, name, and site. The description adds nothing beyond the 'rename' hint, so the baseline of 3 is appropriate rather than lower or higher.

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

Purpose4/5

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

States a specific verb and resource ('Update a navigation menu') and the parenthetical '(rename)' narrows the operation, which implicitly distinguishes it from mcp_update_menu_item. It does not, however, explicitly contrast itself with its nearest siblings.

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

Usage Guidelines3/5

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

Usage is only implied: the agent can infer this renames an existing menu rather than creating or deleting one, but there is no statement of when to prefer it over mcp_update_menu_item, mcp_assign_menu_location, or mcp_create_menu.

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