figma_cancel_operation

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

With no annotations, the description carries the full disclosure burden and does provide one important behavioral detail: applied changes are not rolled back. The word 'request' also avoids promising immediate termination, but confirmation semantics, behavior for completed or unknown operations, and failure or idempotency behavior remain undocumented.

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?

A single front-loaded sentence states the action and the critical non-rollback behavior without filler or redundancy. Its brevity is effective, although the omitted operational details affect other dimensions.

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?

The retained-changes warning is valuable, and the output schema means the description need not explain the response. For a stateful cancellation tool with an undocumented nested scope and no annotations, however, the definition still lacks operation-state requirements, parameter provenance, and guidance on confirming cancellation or handling errors.

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?

The description explains neither operationId nor scope, including its nested sessionId and connectionGeneration fields. With 0% schema description coverage, property names and the UUID pattern are the only parameter guidance, with no explanation of identifier provenance, scope lifetime, or how these values relate.

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 specifies the action and resource: requesting that an operation stop. It also clarifies that applied changes remain, but it does not explicitly distinguish this tool from siblings such as figma_get_operation or identify which operations can be cancelled.

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 no-rollback clause implicitly indicates that this tool is for stopping an operation while preserving changes already applied. It provides no explicit prerequisites, eligible operation states, or guidance to use figma_get_operation to obtain an identifier or verify the resulting status.

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