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

Goes well beyond the annotations: notes that old links cannot be restored, that revocation is immediate and destructive, that the token is returned only once and should be disclosed sparingly, that publish permission and expectedAclVersion from sheets.get_sharing are required, and describes retry behavior after an interrupted response. The idempotencyKey replay guidance is consistent with idempotentHint=false (a fresh key rotates again), so no contradiction.

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 destructive consequence and required permission are front-loaded, and the retry semantics are placed last. It is longer than most definitions but nearly every clause carries operational weight; a few statements (e.g., restating that no invitations are sent) could be trimmed.

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?

For a destructive, open-world mutation with an output schema, the description covers what is destroyed, irreversibility, authorization prerequisites, secret-handling guidance, and idempotent retry semantics. An agent has everything needed to call it safely and correctly.

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 only 33%, but the description compensates: it explains where expectedAclVersion must come from (sheets.get_sharing) and reinforces the idempotencyKey reuse semantics. sheetId's role is self-evident from its uuid format, so little meaning is lost.

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?

States a specific verb (rotate/create a new secret read-access link), resource (sheet), and the immediately-coupled side effect (revoking all previous secret links). This clearly distinguishes it from siblings such as sheets_enable_public_access, sheets_share_with_email, and sheets_get_sharing.

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?

Gives explicit usage guidance ('Use only when the user requests a new or replacement share link') and rules out adjacent behaviors ('does not send invitations or change direct, team or public access'), which implicitly routes to sibling tools. It does not name the specific alternative tool to use for those other access changes, 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.