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

Despite annotations already marking destructiveHint=true and idempotentHint=true, the description adds significant behavioral context: revocation is not instantaneous, the timing of enforcement, irreversibility for this lease ID, inability to renew, and that already admitted actions are not undone. This goes well beyond the annotations and gives the agent a clear picture of consequences.

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 concise, with four sentences focused on the core action and its key consequences. The critical warning about irreversibility is front-loaded, and every sentence contributes value without redundancy. It avoids unnecessary fluff while covering essential edge cases.

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 the tool's complexity (a destructive, irreversible operation) and that there is no output schema, the description covers the most important aspects: timing, irreversibility, and scope of impact. It does not describe the return value or any prerequisites, but those are less critical given the annotations and the simple parameter set. It is nearly complete for the agent's needs.

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 schema already describes both parameters (lease_id and the deprecated vigil_key) with coverage at 100%. The description does not add any parameter-specific meaning beyond what the schema provides. It merely references 'lease ID' without new details, so the baseline of 3 for high schema coverage is appropriate.

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 clear verb and resource: 'Revoke a lease.' It immediately distinguishes itself from siblings like vigil_grant_lease, vigil_renew_lease, and vigil_verify_lease by focusing solely on revocation. The subsequent details (timing, irreversibility) further solidify its unique purpose.

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 provides strong operational context, explaining when revocation takes effect (at recheck_by_ms or earlier) and that it is irreversible. However, it does not explicitly name alternatives or state when NOT to use this tool. The guidance is implied (use for revoking) rather than explicit about exclusions, but it is clear enough for an agent to infer the right use case.

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