Rotate Webhook Signing Secret

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

With no annotations provided, the description carries the full behavioral disclosure burden. It goes beyond a simple 'rotate' by explaining the dual-signing window: 'For 24 hours, payloads are signed with both the new and the previous secret... After that, only the new secret does.' It also states the return value ('Returns the new secret'), giving agents crucial context for mutation effects. Slight deduction for not mentioning idempotency or failure behaviors, but for a single-step rotation it is very thorough.

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 well-structured with clear section headers ('Purpose:', 'NOT for:', 'When to use:'). It is front-loaded with the core purpose, then discards exclusions and usage context in a compact, scannable format. Every sentence earns its place—no filler or redundant wording.

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?

Despite lacking an output schema and annotations, the description covers the essential context for a mutation tool: purpose, alternatives, behavioral implications (dual signing), and return value. It could optionally mention permanence or side effects on other systems, but for a single-parameter action that mirrors a dashboard button, it is nearly complete. Minor gap: does not state whether rotation is reversible or if any cleanup is needed, but this is implied by the action.

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 input schema has 100% description coverage, with the only parameter webhookId documented as 'Webhook ID'. The description does not add any further parameter-specific meaning beyond what the schema provides. Baseline 3 is appropriate because the schema adequately covers the parameter, and the description focuses on overall behavior rather than param details.

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 clearly states the tool's purpose with a specific verb and resource: 'Replace a webhook's signing secret with a new one — the same action as the dashboard's Rotate button.' It explicitly distinguishes from sibling tools by naming update-webhook (for endpoint URL/events) and get-webhook (for reading the secret), making differentiation clear without needing to inspect schemas.

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?

Provides explicit guidance on both when to use ('User believes the signing secret leaked, or wants to rotate it as routine hygiene') and when not to ('NOT for: Changing the endpoint URL or subscribed events (use update-webhook), or reading the current secret (use get-webhook)'). This directly routes the agent to the appropriate sibling tools, leaving no ambiguity.

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