Skip to main content
Glama

Undo a Cloudflare change

cf_undo
Destructive

Undo a Cloudflare change made through the cf_dns_, cf_firewall_ or cf_settings tools: a record or rule that was added is removed, a changed one gets its old values, a removed one is made again. Without change_id it lists the changes of the last 90 days.

Input Schema

NameRequiredDescriptionDefault
change_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations by spelling out the exact reversal semantics per operation type: an added record/rule is removed, a changed one is restored to old values, a removed one is recreated. This is materially useful given destructiveHint=true and idempotentHint=false, and it also discloses the default listing window of 90 days.

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 sentences, no filler. The core undo behavior is front-loaded and the no-argument fallback is placed second, which is the right priority order for an agent deciding how to call it.

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 one-parameter, no-output-schema tool with annotations already declaring the destructive profile, the description covers purpose, reversal semantics, and default behavior. It does not address permissions/auth needed to undo or whether the undo itself is reversible, which would be nice for a destructiveHint=true tool.

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% and the single attribute has no description, but the prose fully compensates by explaining the effect of supplying change_id versus omitting it (falling back to a 90-day listing). It stops short of saying where to obtain a change_id, though the listing behavior implies it.

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 (undo) plus the resource (a Cloudflare change) and narrows the scope to changes made by the cf_dns_, cf_firewall_ and cf_settings tools. An agent can distinguish this from sibling undo tools like redirects_undo or content_undo by the Cloudflare scope alone.

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 context for both invocation modes: with change_id it undoes that change, without it lists changes from the last 90 days. It does not explicitly name non-Cloudflare alternatives (rollback, redirects_undo) or state exclusions, so it falls just short of the 5 bar.

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