Skip to main content
Glama

Check for Slack replies

check_replies

Checks pending Slack bot questions for replies without waiting, optionally for one conversation after a timestamp, and removes answered questions from the pending list.

Instructions

Check once, without waiting, whether people answered the bot. With no arguments, checks every pending question (saved by send_message with expect_reply, or by wait_for_reply on timeout), including ones from earlier sessions; answered questions are removed from the pending list. With channel and since_ts, checks one conversation instead. Cheap to call, so use it for long waits: end your turn, then call it later from a scheduled or looped run.

Input Schema

NameRequiredDescriptionDefault
channelNoCheck only this conversation (ID, #name, or user). Requires since_ts. Omit to check all pending questions.
dismissNoPending question IDs to drop without an answer (e.g. no longer needed)
since_tsNoWith channel: only messages after this ts
thread_tsNoWith channel: thread to check; new top-level messages in the channel are checked too

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.1

TDQS

A4.2/5.0
Behavior4/5

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

Beyond the annotations, it discloses that answered questions are removed from the pending list and that earlier-session pending questions are included. It does not describe authorization needs or rate limits, but the key mutation of pending state is explained.

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 front-loaded with the core behavior, then covers mode selection and usage advice without filler. The parenthetical about pending-question sources earns its place by explaining the tool's state model.

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?

It covers behavior, modes, side effects, and long-wait workflow, which is strong for a tool with four optional parameters and full schema coverage. Because there is no output schema and the description does not explain the return shape, a minor completeness gap remains.

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 description coverage is 100%, so the schema already documents channel, since_ts, thread_ts, and dismiss. The description adds mode-level context for no-argument versus channel/since_ts usage, but it does not add parameter details beyond the schema, making 3 the appropriate baseline.

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 states a specific verb and resource: checking once, without waiting, whether people answered the bot. It also distinguishes the all-pending mode from the single-conversation mode, so an agent can identify the tool's role immediately.

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 usage context: no arguments checks all pending questions, channel plus since_ts checks one conversation, and it is cheap to call for long waits via scheduled or looped runs. It does not explicitly route the agent to wait_for_reply as the blocking alternative, so it falls short of full when/when-not guidance.

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