Skip to main content
Glama
SalesSuite MCP Server

SalesSuite MCP Server

Official

Delete Webhook Subscription

delete_webhook_subscription
DestructiveIdempotent

Deletes a webhook subscription by ID and stops future event delivery to its URL. Use it to remove outdated or unwanted webhook endpoints from SalesSuite.

Instructions

Delete Webhook Subscription.

Deletes a webhook subscription by ID and stops future event delivery to its URL.

Input Schema

NameRequiredDescriptionDefault
idYesThe unique identifier for the subscription.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is largely covered. The description adds genuine value by explaining the consequence ('stops future event delivery to its URL'), but it does not state whether the subscription record is unrecoverable, whether in-flight deliveries are affected, or what authorization is needed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with purpose and followed by the effect. The opening sentence largely restates the tool title, which is minor waste, but nothing else could be removed without losing content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter delete tool with no output schema and full annotation coverage, the definition supplies enough to call it correctly and understand its effect. Only the reversibility/permission details are missing, which keeps it short of a 5.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is a single parameter with 100% schema description coverage, so the schema already documents 'id' as the unique subscription identifier. The description's 'by ID' phrasing matches the schema without adding format, sourcing, or validation detail, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Deletes a webhook subscription by ID') that unambiguously separates it from the get/create/update_webhook_subscription siblings listed. It does not explicitly name those siblings, but the naming and effect statement make the distinction obvious.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance, no mention of alternatives such as update_webhook_subscription or get_webhook_subscription, and no stated prerequisites or warnings about performing this action. The only hint of intent is the effect statement about stopping event delivery.

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