Skip to main content
Glama
SalesSuite MCP Server

SalesSuite MCP Server

Official

Delete Call Activity

delete_call_activity
DestructiveIdempotent

Deletes a call activity by its unique ID, letting you remove outdated or incorrect call records from the SalesSuite CRM.

Instructions

Delete Call Activity.

Deletes a call activity by ID.

Input Schema

NameRequiredDescriptionDefault
callActivityIdYesThe unique ID of the call activity.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.5/5.0
Behavior2/5

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

The annotations already declare destructiveHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is covered structurally. The description adds nothing beyond them: it does not say whether deletion is permanent or recoverable, whether related data (feeds, notes, associations) is removed, or what happens if the ID does not exist. For a destructive mutation this leaves real behavioral questions unanswered.

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

Conciseness3/5

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

The text is short and front-loaded, which is good, but it is also redundant: the title is restated verbatim before the one sentence that carries any information. It is brief without being informative rather than efficient.

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

Completeness2/5

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

For a destructive, irreversible-operation tool with no output schema, the definition should mention consequences of deletion and error behavior for an unknown ID. Annotations cover the risk flags, but nothing here tells the agent what a successful or failed call actually means.

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?

With a single parameter at 100% schema description coverage and an explicit UUID pattern, the schema fully documents callActivityId. The description's 'by ID' phrasing is consistent but adds no syntax or format detail beyond the schema, so the baseline of 3 applies.

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

Purpose3/5

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

The description states a verb and resource ('Deletes a call activity by ID'), so the operation is identifiable, but the first line merely repeats the tool title and the second adds only the 'by ID' qualifier. It offers no differentiation from siblings like delete_email_activity, delete_note, or delete_contact_person, leaving the agent to rely on the name alone.

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 guidance on when to use this tool versus alternatives such as delete_email_activity or other cleanup paths, and no stated preconditions. Nothing indicates whether the caller should first retrieve the activity with get_call_activity or confirm it exists before deleting.

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