rollback_apply

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that the reversal call is re-dispatched through the same MCP handler, re-entering auth/rate-limiting/validation, and that on success a new action_log entry is appended with rollback_of=index. This is useful, but it does not mention failure behavior or return values, so it is not fully comprehensive.

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

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

The description is only two sentences and packs in the operation, the re-dispatch behavior, side-effect, and a required parameter. Every clause serves a purpose with no fluff or repetition.

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

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

Given there is no output schema, the description provides enough context for a rollback execution tool: what it does, its internal re-validation, side effects, and the confirm requirement. It lacks explicit return-value information or failure handling, but these are not essential for executing a rollback plan and are reasonably inferred.

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

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

Schema coverage is 100%, so the input schema already documents all three parameters (index, confirm, state_file). The description adds some context by tying index to action_log and emphasizing confirm=true, but it does not materially expand on the schema descriptions. This aligns with the baseline score of 3.

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

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

The description opens with a specific action: 'Execute the rollback plan for action_log[index].' This clearly identifies the verb (execute), the resource (rollback plan), and the target (the action_log entry at the given index). It also implicitly distinguishes itself from sibling tool rollback_plan_get, which likely creates or retrieves a plan rather than executing it.

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

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

The description states the trigger and requirement: 'Requires confirm=true.' It also explains that the call re-enters auth, rate-limiting, and validation, which implies it should be used when executing a previously generated rollback plan. However, it does not explicitly mention when not to use it or name alternative tools, so it falls 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.