Skip to main content
Glama

Remove a batch of redirects

redirects_undo
Destructive

Remove the redirects one redirects_apply batch wrote. batch is the id from redirects_apply or redirects_history.

Input Schema

NameRequiredDescriptionDefault
siteNoSite root folder or one of its domains. Optional when the server has one site.
batchYesFor undo: the batch id from apply or history.
serverNoServer name or id. Optional when the account has one server.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false and non-idempotency, so the safety profile is carried. The description adds the valuable scoping detail that destruction is limited to the redirects one apply batch wrote, which is the key behavioral fact an agent needs before calling it. It stops short of saying what happens on a re-run of an already-undone batch or whether manually edited redirects in that batch are affected.

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

Conciseness5/5

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

Two short sentences, zero filler, and the destructive action plus its scope is front-loaded before the parameter provenance. Every clause earns its place.

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?

With no output schema and only three parameters, the definition covers the essentials: what is removed, its scope, and where the required id comes from. Residual gaps (post-undo state, error behavior on stale batch ids) are modest given the annotations already flag destructiveness.

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?

Schema description coverage is 100%, so the schema already documents site, batch, and server. The description only restates the batch parameter, though it sharpens 'apply or history' into the concrete tool names redirects_apply and redirects_history. That earns the baseline 3 rather than more.

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 (remove), a precise resource (the redirects written by one redirects_apply batch) and the scope limitation that defines the operation. It names the sibling tools (redirects_apply, redirects_history) that the batch id comes from, so an agent can distinguish it from redirects_apply, redirects_history, and redirects_list without opening a 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?

The description gives clear context: use this to reverse a specific apply batch, and it explains exactly where the required batch id comes from (redirects_apply or redirects_history). It does not state exclusions or alternatives (e.g., how this differs from rollback or seo_fields_undo, or what to do if the batch was already undone), so it falls short of a full when/when-not treatment.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources