Skip to main content
Glama
stackia
by stackia

Delete Channel Message

delete_channel_message
DestructiveIdempotent

Delete a channel message by marking it as deleted. Only the original sender can remove their own messages.

Instructions

Soft delete a message in a channel. Only the message sender can delete their own messages. The message will be marked as deleted.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
teamIdYesTeam ID
replyIdNoReply ID if deleting a reply to a message (optional)
tenantIdNoTarget tenant ID from list_tenants. Omit only when a default is configured or exactly one tenant is connected. Resource IDs belong to this tenant.
channelIdYesChannel ID
messageIdYesMessage ID to delete

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.1

TDQS

A4.2/5.0
Behavior4/5

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

The description reveals that the delete is soft ('will be marked as deleted') and imposes a sender-only permission, which goes beyond the annotations' destructiveHint and idempotentHint. This clarifies the actual effect on the message and who is allowed to trigger it. No contradiction with annotations since readOnlyHint=false and destructiveHint=true align with deletion.

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

Conciseness5/5

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

Two sentences totaling ~30 words, front-loading the core action and then layering the permission and outcome. No filler or redundancy. Every sentence contributes either the primary action or a necessary constraint.

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?

The description covers the essential usage and effect, and the annotations handle idempotency and destructiveness. The optional replyId is sufficiently documented in the schema, and no output schema means return values aren't expected. A minor gap is the lack of error behavior when the caller is not the sender, but the ownership rule already prevents misuse.

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?

Schema coverage is 100% and all parameters have individual descriptions, so the baseline is 3. The description does not add any parameter-specific semantics, such as how replyId interacts with messageId, leaving that to the schema. The sender-only rule is a behavioral constraint, not a parameter clarification.

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

Purpose5/5

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

Clearly states the action ('soft delete'), resource ('message in a channel'), and distinct nature ('marked as deleted'). Differentiates from sibling delete_chat_message via the channel context and soft-delete wording. No ambiguity about what the tool does.

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

Usage Guidelines4/5

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

Gives a clear when-not condition: only the sender can delete their own message, so an agent knows not to invoke this on behalf of other users. It implies use for channel messages rather than chat messages but does not explicitly name alternative tools like delete_chat_message. The context is adequate for most routing decisions.

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