Remove a registered webhook in Kommo CRM by providing the exact destination URL and client slug. Stops unwanted callbacks by canceling the subscription.
Remove um webhook existente. Para remover, você deve passar exatamente a mesma URL (destination) que foi cadastrada.
| Name | Required | Description | Default |
|---|---|---|---|
| client_slug | Yes | Identificador do cliente (slug) | |
| destination | Yes | URL do webhook a ser removido |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It discloses the exact-match requirement for the destination URL, which is genuinely useful, but does not mention permanence of deletion, error behavior when the webhook is not found, or whether client_slug must also match the registration. This is adequate but not comprehensive.
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 concise sentences with no filler. The primary purpose is front-loaded and the critical usage requirement follows immediately.
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?
For a simple delete tool with two required parameters, the description plus schema covers the essential invocation. However, it does not clarify whether client_slug also needs to match the original registration, and there is no output schema or note about success/failure behavior, leaving some gaps for an agent.
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%, establishing a baseline of 3. The description adds extra meaning to the destination parameter by specifying that it must exactly match the registered URL, which is a non-obvious constraint beyond the schema's simple 'URL do webhook a ser removido'.
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 states a specific action and resource: 'Remove um webhook existente' (remove an existing webhook). This clearly distinguishes it from sibling tools like create_webhook and get_webhooks, and from the many other resource-specific tools in the list.
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?
The description gives a clear usage condition: the destination URL must be exactly the same as the one previously registered. It does not explicitly name alternatives or when-not-to-use, but the delete context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.