Contract Testing: Regenerate API Token

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

Annotations already declare destructiveHint=true, idempotentHint=false and readOnlyHint=false, so the agent knows this is an irreversible mutation. The description adds nothing beyond them: it does not say whether the previous token value is immediately invalidated, whether the caller must be a token owner/admin, or whether the new value is returned. For a destructive, non-idempotent operation this is a real gap.

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 core action is front-loaded in one clear sentence. The trailing 'Toolset' and 'Parameters' block repeats what the schema already provides, adding minor redundancy but not obscuring the purpose.

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?

Annotations cover the safety profile and an output schema exists, so return format need not be described. Still, for a destructive rotation tool the description should warn about token invalidation and permission requirements, which it omits.

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% and the single tokenId parameter is fully described in the schema, so the description merely restates it ('ID of the token to regenerate'). Baseline 3 applies when the schema carries parameter meaning.

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 and resource: 'Regenerate (rotate) an API token by ID.' The parenthetical 'rotate' clarifies the sense of 'regenerate', and 'by ID' scopes it enough to separate it from siblings like contract-testing_list_api_tokens. It does not name an explicit counter-tool, but the action is unambiguous.

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?

No guidance on when to use this instead of, say, creating a new token or using contract-testing_admin_get_system_account_tokens. No prerequisites, permissions, or caveats about existing consumers of the token are mentioned.

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