secret_rotateReopens the intake page for an existing secret to rotate credentials, preserving its label, destination, and metadata. Use when a secret is expired or rotation is due.
Re-opens the intake page for an existing secret (same label, destination and metadata). Use when secret_list shows expired or rotation_due.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| title | No |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It usefully reveals this is a human-interactive flow (re-opening an intake page, 'ask the person') and that only the value changes while label/destination/metadata persist. However, it never says whether this blocks, whether the old value is destroyed or retained, or what permissions are needed — meaningful gaps for a secret-mutating operation.
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?
Two tight sentences with the action front-loaded and the trigger condition second; nothing is wasted and the parenthetical scoping detail adds value rather than padding.
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?
With no annotations, no output schema, and 0% schema coverage, the description leaves important things unaddressed: what happens to the prior secret value, whether the caller must follow up with secret_wait, and the meaning of the input parameters. It is minimally adequate for a 2-param tool but not complete.
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 0% and the description does not explain the two parameters at all. Worse, it references 'label, destination and metadata' while the schema exposes only 'name' and 'title', leaving the reader unable to map the described fields onto the actual inputs or infer the required 'name'.
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 pairs a specific action ('re-opens the intake page') with a specific resource (an existing secret) and reinforces it with the title. It implies the distinction from secret_request (which presumably creates a new secret) by scoping to 'an existing secret', but does not name that sibling to make the boundary explicit.
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?
It gives an explicit trigger condition: 'Use when secret_list shows expired or rotation_due' — a concrete, checkable state that names another tool. It stops short of stating when-not-to-use or naming secret_request/secret_write as alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.