rotate_webhook_secretChanges the secret that signs the webhooks (requires the token edm_…). The previous secret still signs for 24 h, so you can change it without a failure window. During the 24 h, the webhook-signature header has two v1,… parts: one with the new secret and one with the previous. The receiver only needs to accept any part that matches.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations (readOnlyHint=false, idempotentHint=false, destructiveHint=false) by disclosing the 24 h dual-signing grace period and the exact header shape the receiver must tolerate. This is precisely the behavioral context an agent needs to avoid breaking a consumer, and it also clarifies that the mutation is non-destructive in practice.
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?
Front-loads the mutation, then the credential requirement, then the grace-period mechanics and receiver contract. Four sentences, each carrying distinct, load-bearing information with no 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 parameters and no output schema, the description covers everything an agent needs: what changes, what auth is required, what happens during the transition, and how the receiver should handle it. Nothing material is missing.
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?
There are zero input parameters, so the baseline is 4. The description's mention of the required edm_… token adds auth context that the empty schema cannot express.
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 ('Changes the secret that signs the webhooks') with unambiguous scope. No sibling tool overlaps with webhook secret rotation, and the agent can tell immediately what this does.
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?
Names the prerequisite credential (the edm_… token) and explains the operational context in which rotating is safe ('you can change it without a failure window'). It does not discuss when-not-to-rotate or alternatives, but there are no plausible alternatives among the siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.