Remove an agent's webhook by passing agent_id, or omit it to delete the project-level webhook.
Remove a webhook. Pass agent_id to remove an agent's webhook (falls back to project default). Omit agent_id to remove the project-level webhook.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | No | Agent ID to delete that agent's webhook. Omit for project-level. |
Changes observed during successful MCP inspections.
v0.7.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=true, which sets the safety floor. The description adds the non-obvious fallback/scope semantics (agent-level delete falls back to project default; omitting targets project-level) that annotations cannot express. Does not state irreversibility explicitly, but the destructive hint plus 'remove' wording covers the essential traits.
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?
Three short sentences, front-loaded with the verb and resource, then the branching guidance. Zero filler.
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?
Complete for a one-parameter destructive tool: what it does, the scope branching, and the fallback are all present. An output schema is absent but a delete's return value is conventionally minimal; no critical gap remains.
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 schema already documents agent_id, so baseline would be 3. The description adds the fallback behavior ('falls back to project default') that the schema field description does not convey, which is meaningful semantics beyond the schema.
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+resource ('Remove a webhook') and immediately clarifies the two scopes (agent-level vs project-level). Distinguishable from siblings like get_webhook, set_webhook, and test_webhook without opening 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?
Explains precisely when to pass agent_id versus omit it, which is the sole decision point for this tool. No explicit exclusions or named alternatives, but the branching logic is fully spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.