Skip to main content
Glama
crunchtools

mcp-slack-crunchtools

by crunchtools

slack_cancel_scheduled_message

Cancel a scheduled Slack message before it sends. Provide the channel ID and scheduled message ID to retract it.

Instructions

Cancel a scheduled Slack message before it sends.

Args: channel_id: Channel ID the message was scheduled in scheduled_message_id: The scheduled_message_id returned by slack_send_message

Returns: Confirmation with scheduled_message_id

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
channel_idYes
scheduled_message_idYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.2/5.0
Behavior3/5

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

With no annotations, the description carries the burden; it does disclose the core behavior, the timing constraint ('before it sends'), and the confirmation-shaped return. However, it does not mention permissions/scope requirements, error behavior for already-sent messages, or whether cancellation is irreversible.

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?

The description is compact and front-loaded with the one-sentence purpose, followed by a clear Args/Returns structure. Every line adds information and there is no filler.

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 two-parameter cancellation tool, the description covers the core invocation details, lifecycle origin, and return value; an output schema exists to fill in return structure. It leaves out only edge-case behavior such as already-sent messages or required Slack scopes, which keeps it from a 5.

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

Parameters4/5

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

Schema description coverage is 0%, so the description must compensate, and it does: it identifies channel_id as the channel where the message was scheduled and explains that scheduled_message_id comes from slack_send_message. This is meaningful guidance beyond the bare string names in the schema.

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?

The description opens with a specific verb and resource: 'Cancel a scheduled Slack message before it sends.' It clearly identifies the tool as the cancellation counterpart to slack_send_message and is not confusable with any sibling tool.

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?

It gives clear context: use this to cancel a scheduled message before it sends, and it anchors the scheduled_message_id to a value 'returned by slack_send_message.' It does not explicitly list when-not-to-use alternatives, but no true alternative exists among the siblings.

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