Skip to main content
Glama
Strand-AI

Slack Notifier MCP

by Strand-AI

get_thread_replies

Retrieve replies from a Slack thread by providing the channel ID and parent message timestamp. Optionally filter to return only messages after a specified timestamp, enabling you to check for new replies.

Instructions

Get replies in a Slack thread.

Use this to check for new messages in a thread you started.

Args: channel: Channel ID containing the thread. thread_ts: Timestamp of the parent message. since_ts: Only return messages after this timestamp (optional).

Returns: Dict with success status and list of replies.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
channelYes
thread_tsYes
since_tsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • Tool registration via @mcp.tool() decorator. The get_thread_replies function is registered as an MCP tool on the FastMCP server. It imports and delegates to the actual implementation from slack_mcp/tools/messaging.py.
    @mcp.tool()
    def get_thread_replies(
        channel: str,
        thread_ts: str,
        since_ts: str | None = None,
    ) -> dict:
        """Get replies in a Slack thread.
    
        Use this to check for new messages in a thread you started.
    
        Args:
            channel: Channel ID containing the thread.
            thread_ts: Timestamp of the parent message.
            since_ts: Only return messages after this timestamp (optional).
    
        Returns:
            Dict with success status and list of replies.
        """
        from .tools.messaging import get_thread_replies as _get_thread_replies
    
        return _get_thread_replies(channel=channel, thread_ts=thread_ts, since_ts=since_ts)
  • Core handler implementation of get_thread_replies. Gets a Slack client, calls client.get_thread_replies to fetch thread replies from Slack API, and returns a dict with success status, reply messages (text, user, user_id, ts), and count.
    def get_thread_replies(
        channel: str,
        thread_ts: str,
        since_ts: str | None = None,
    ) -> dict:
        """Get replies in a Slack thread.
    
        Use this to check for new messages in a thread you started.
    
        Args:
            channel: Channel ID containing the thread.
            thread_ts: Timestamp of the parent message.
            since_ts: Only return messages after this timestamp (optional).
    
        Returns:
            Dict with success status and list of replies.
        """
        client = _get_client()
    
        try:
            replies = client.get_thread_replies(channel, thread_ts, since_ts)
    
            return {
                "success": True,
                "message": f"Found {len(replies)} replies",
                "replies": [
                    {
                        "text": r.text,
                        "user": r.user_name or r.user,
                        "user_id": r.user,
                        "ts": r.ts,
                    }
                    for r in replies
                ],
                "count": len(replies),
            }
        except RuntimeError as e:
            return {
                "success": False,
                "message": str(e),
                "replies": [],
                "count": 0,
            }
  • Low-level Slack API helper method. Uses the Slack SDK's conversations_replies API to fetch thread replies, filters out the parent message and bot messages, resolves usernames via users_info API, and returns a list of Message objects.
    def get_thread_replies(
        self,
        channel: str,
        thread_ts: str,
        since_ts: str | None = None,
    ) -> list[Message]:
        """Get replies in a thread.
    
        Args:
            channel: Channel ID containing the thread.
            thread_ts: Timestamp of the parent message.
            since_ts: Only return messages after this timestamp.
    
        Returns:
            List of messages in the thread.
        """
        try:
            result = self.client.conversations_replies(
                channel=channel,
                ts=thread_ts,
                oldest=since_ts,
            )
    
            messages = []
            for msg in result.get("messages", []):
                # Skip the parent message and bot messages
                if msg.get("ts") == thread_ts:
                    continue
                if msg.get("bot_id"):
                    continue
                if since_ts and float(msg["ts"]) <= float(since_ts):
                    continue
    
                messages.append(
                    Message(
                        text=msg.get("text", ""),
                        user=msg.get("user", ""),
                        user_name=self._get_user_name(msg.get("user", "")),
                        ts=msg["ts"],
                        thread_ts=msg.get("thread_ts"),
                        channel=channel,
                    )
                )
    
            return messages
    
        except SlackApiError as e:
            raise RuntimeError(f"Failed to get thread replies: {e.response['error']}") from e
  • Helper function _get_client() used by the handler to create a SlackClient instance from environment configuration.
    def _get_client() -> SlackClient:
        """Get or create a Slack client."""
        config = SlackConfig.from_env()
        return SlackClient(config)
  • Input schema for get_thread_replies: channel (str), thread_ts (str), since_ts (Optional[str]). These are the parameters defined in the registered tool function signature.
    def get_thread_replies(
        channel: str,
        thread_ts: str,
        since_ts: str | None = None,
    ) -> dict:
Behavior3/5

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

No annotations are provided, so the description must disclose behavior. It explains the return format (dict with success status and list of replies) and the optional since_ts parameter. However, it does not mention potential errors, rate limits, or if the tool requires authentication.

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?

The description is structured with an Args section and Returns section, making it easy to parse. It is concise without unnecessary elaboration, though the first sentence 'Get replies in a Slack thread.' is somewhat redundant with the name.

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

Completeness3/5

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

For a tool with 3 parameters and an output schema mentioned but not detailed, the description provides adequate information for basic usage. However, it omits details about error handling, pagination of replies, and behavior if the thread is not found, leaving gaps for complex usage.

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. It explains each parameter: channel is a 'Channel ID', thread_ts is a 'Timestamp of the parent message', and since_ts is 'optional' and 'only return messages after this timestamp'. This adds sufficient meaning beyond 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 clearly states the tool gets replies in a Slack thread, using specific verb 'Get' and resource 'replies'. It distinguishes from sibling tools 'ask_user' and 'send' which have different purposes.

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

Usage Guidelines3/5

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

The description suggests using the tool 'to check for new messages in a thread you started', providing a specific use case. However, it lacks explicit guidance on when not to use it or alternatives, such as using the 'send' tool for posting messages.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Strand-AI/slack-notifier-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server