Skip to main content
Glama
gustavonline

slack

by gustavonline
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Slack MCP Server

MCP Server for the Slack API, enabling Claude to interact with Slack workspaces.

Tools

  1. slack_list_channels

    • List public or pre-defined channels in the workspace

    • Optional inputs:

      • limit (number, default: 100, max: 200): Maximum number of channels to return

      • cursor (string): Pagination cursor for next page

    • Returns: List of channels with their IDs and information

  2. slack_post_message

    • Post a new message to a Slack channel

    • Required inputs:

      • channel_id (string): The ID of the channel to post to

      • text (string): The message text to post

    • Returns: Message posting confirmation and timestamp

  3. slack_reply_to_thread

    • Reply to a specific message thread

    • Required inputs:

      • channel_id (string): The channel containing the thread

      • thread_ts (string): Timestamp of the parent message

      • text (string): The reply text

    • Returns: Reply confirmation and timestamp

  4. slack_add_reaction

    • Add an emoji reaction to a message

    • Required inputs:

      • channel_id (string): The channel containing the message

      • timestamp (string): Message timestamp to react to

      • reaction (string): Emoji name without colons

    • Returns: Reaction confirmation

  5. slack_get_channel_history

    • Get recent messages from a channel

    • Required inputs:

      • channel_id (string): The channel ID

    • Optional inputs:

      • limit (number, default: 10): Number of messages to retrieve

    • Returns: List of messages with their content and metadata

  6. slack_get_thread_replies

    • Get all replies in a message thread

    • Required inputs:

      • channel_id (string): The channel containing the thread

      • thread_ts (string): Timestamp of the parent message

    • Returns: List of replies with their content and metadata

  7. slack_get_users

    • Get list of workspace users with basic profile information

    • Optional inputs:

      • cursor (string): Pagination cursor for next page

      • limit (number, default: 100, max: 200): Maximum users to return

    • Returns: List of users with their basic profiles

  8. slack_get_user_profile

    • Get detailed profile information for a specific user

    • Required inputs:

      • user_id (string): The user's ID

    • Returns: Detailed user profile information

Related MCP server: slack-mpm

Setup

  1. Create a Slack App:

    • Visit the Slack Apps page

    • Click "Create New App"

    • Choose "From scratch"

    • Name your app and select your workspace

  2. Configure Bot Token Scopes: Navigate to "OAuth & Permissions" and add these scopes:

    • channels:history - View messages and other content in public channels

    • channels:read - View basic channel information

    • chat:write - Send messages as the app

    • reactions:write - Add emoji reactions to messages

    • users:read - View users and their basic information

    • users.profile:read - View detailed profiles about users

  3. Install App to Workspace:

    • Click "Install to Workspace" and authorize the app

    • Save the "Bot User OAuth Token" that starts with xoxb-

  4. Get your Team ID (starts with a T) by following this guidance

Usage with Claude Desktop

Add the following to your claude_desktop_config.json:

NPX

{
  "mcpServers": {
    "slack": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-slack"
      ],
      "env": {
        "SLACK_BOT_TOKEN": "xoxb-your-bot-token",
        "SLACK_TEAM_ID": "T01234567",
        "SLACK_CHANNEL_IDS": "C01234567, C76543210"
      }
    }
  }
}

docker

{
  "mcpServers": {
    "slack": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "-e",
        "SLACK_BOT_TOKEN",
        "-e",
        "SLACK_TEAM_ID",
        "-e",
        "SLACK_CHANNEL_IDS",
        "mcp/slack"
      ],
      "env": {
        "SLACK_BOT_TOKEN": "xoxb-your-bot-token",
        "SLACK_TEAM_ID": "T01234567",
        "SLACK_CHANNEL_IDS": "C01234567, C76543210"
      }
    }
  }
}

Usage with VS Code

For quick installation, click one of the installation buttons below...

Install with NPX in VS Code Install with NPX in VS Code Insiders

Install with Docker in VS Code Install with Docker in VS Code Insiders

For manual installation, add the following JSON block to your User Settings (JSON) file in VS Code. You can do this by pressing Ctrl + Shift + P and typing Preferences: Open Settings (JSON).

Optionally, you can add it to a file called .vscode/mcp.json in your workspace. This will allow you to share the configuration with others.

Note that the mcp key is not needed in the .vscode/mcp.json file.

NPX

{
  "mcp": {
    "inputs": [
      {
        "type": "promptString",
        "id": "slack_bot_token",
        "description": "Slack Bot Token (starts with xoxb-)",
        "password": true
      },
      {
        "type": "promptString",
        "id": "slack_team_id",
        "description": "Slack Team ID (starts with T)"
      }
    ],
    "servers": {
      "slack": {
        "command": "npx",
        "args": ["-y", "@modelcontextprotocol/server-slack"],
        "env": {
          "SLACK_BOT_TOKEN": "${input:slack_bot_token}",
          "SLACK_TEAM_ID": "${input:slack_team_id}"
        }
      }
    }
  }
}

Docker

{
  "mcp": {
    "inputs": [
      {
        "type": "promptString",
        "id": "slack_bot_token",
        "description": "Slack Bot Token (starts with xoxb-)",
        "password": true
      },
      {
        "type": "promptString",
        "id": "slack_team_id",
        "description": "Slack Team ID (starts with T)"
      }
    ],
    "servers": {
      "slack": {
        "command": "docker",
        "args": ["run", "-i", "--rm", "mcp/slack"],
        "env": {
          "SLACK_BOT_TOKEN": "${input:slack_bot_token}",
          "SLACK_TEAM_ID": "${input:slack_team_id}"
        }
      }
    }
  }
}

Environment Variables

  1. SLACK_BOT_TOKEN: Required. The Bot User OAuth Token starting with xoxb-.

  2. SLACK_TEAM_ID: Required. Your Slack workspace ID starting with T.

  3. SLACK_CHANNEL_IDS: Optional. Comma-separated list of channel IDs to limit channel access (e.g., "C01234567, C76543210"). If not set, all public channels will be listed.

Troubleshooting

If you encounter permission errors, verify that:

  1. All required scopes are added to your Slack app

  2. The app is properly installed to your workspace

  3. The tokens and workspace ID are correctly copied to your configuration

  4. The app has been added to the channels it needs to access

Build

Docker build:

docker build -t mcp/slack -f src/slack/Dockerfile .

License

This MCP server is licensed under the MIT License. This means you are free to use, modify, and distribute the software, subject to the terms and conditions of the MIT License. For more details, please see the LICENSE file in the project repository.

Available Tools

8 tools
slack_add_reactionB

Add a reaction emoji to a message

ParametersJSON Schema
NameRequiredDescriptionDefault
reactionYesThe name of the emoji reaction (without ::)
timestampYesThe timestamp of the message to react to
channel_idYesThe ID of the channel containing the message

TDQS

B3.3/5.0
Behavior2/5

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

No annotations provided; the description does not disclose whether adding a duplicate reaction is idempotent, whether it modifies the original message, or any rate limits. Minimal behavioral context.

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?

Single focused sentence with no fluff. Efficiently communicates the core purpose.

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?

Adequate for a simple action, but lacks usage guidance and behavioral details that would fully inform agent decision-making. No output schema to compensate.

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% with parameter descriptions; the tool description adds no additional meaning beyond what the schema already provides. Baseline score of 3 is appropriate.

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 'Add a reaction emoji to a message' clearly states the action and resource, distinguishing it from sibling tools like slack_post_message or slack_get_channel_history.

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?

No guidance on when to use this tool vs alternatives, no prerequisites mentioned (e.g., must have a valid timestamp), and no exclusion criteria.

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

slack_get_channel_historyB

Get recent messages from a channel. Requires 'groups:history' scope for private channels.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoNumber of messages to retrieve (default 10)
channel_idYesThe ID of the channel

TDQS

B3.3/5.0
Behavior2/5

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

No annotations provided, so description must disclose all behavioral traits. Only mentions scope requirements. Fails to describe ordering, pagination, rate limits, or return format. Significant gaps.

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?

Two sentences, front-loaded with core action. Efficient, though could include more structure.

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?

Simple tool but lacks key context: what does 'recent' mean? How are messages ordered? No output schema to clarify return format. Incomplete for an agent to use correctly.

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%, so schema already documents both parameters. Description adds no additional meaning beyond 'recent' which is ambiguous.

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 'Get recent messages from a channel' - a specific verb and resource. Distinguishes from siblings like slack_get_thread_replies (threads) and slack_post_message (posting).

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?

Mentions required scope for private channels, which is helpful context. However, no explicit guidance on when to use vs alternatives or when not to use. The name and sibling tools imply use cases.

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

slack_get_thread_repliesB

Get all replies in a message thread

ParametersJSON Schema
NameRequiredDescriptionDefault
thread_tsYesThe timestamp of the parent message in the format '1234567890.123456'. Timestamps in the format without the period can be converted by adding the period such that 6 numbers come after it.
channel_idYesThe ID of the channel containing the thread

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are provided, and the description adds minimal behavioral context. It does not disclose rate limits, authentication needs, error handling, or what happens if the thread does not exist. The only behavioral detail is the parameter description for thread_ts format, which pertains to parameter semantics, not overall tool behavior.

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 a single sentence with no unnecessary words. It is concise and front-loaded. However, it may be slightly too brief for a tool with no annotations, as it omits additional context that could be included without becoming verbose.

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?

Given the lack of output schema and annotations, the description does not adequately explain return format (e.g., an array of messages), whether replies are nested, or pagination behavior. The tool's complexity (2 required params) and the absence of structured metadata demand more context than provided.

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% with descriptive parameter details, so baseline is 3. The tool description adds no additional meaning beyond the schema; it simply states the tool's function without elaborating on parameters. Thus, it does not provide extra value beyond what the schema already conveys.

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 'Get all replies in a message thread' clearly states the verb (get) and resource (replies in a thread). It effectively distinguishes this tool from siblings like slack_reply_to_thread (which creates replies) and slack_get_channel_history (which retrieves messages but not specifically thread replies).

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?

No guidance is provided on when to use this tool versus alternatives. It does not specify appropriate scenarios, prerequisites, or cases where another tool would be more suitable, leaving the agent without context for tool selection.

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

slack_get_user_profileB

Get detailed profile information for a specific user

ParametersJSON Schema
NameRequiredDescriptionDefault
user_idYesThe ID of the user

TDQS

B3.3/5.0
Behavior2/5

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

No annotations provided. The description does not disclose if the operation is read-only, rate limits, or any side effects. For a read tool, this is minimal but insufficient.

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?

One sentence, no fluff, front-loaded with verb and resource. Very concise.

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?

Given low complexity (1 param) and no output schema, the description is minimally adequate. However, it lacks detail on what 'detailed profile information' includes.

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% with a clear description for user_id. The description adds no extra meaning beyond the schema, meeting the 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 clearly states the verb 'Get' and resource 'detailed profile information for a specific user'. It distinguishes from sibling tools like slack_get_users (list all users) and others.

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?

The description provides no guidance on when to use this tool versus alternatives like slack_get_users. No context about prerequisites or limitations.

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

slack_get_usersB

Get a list of all users in the workspace with their basic profile information

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of users to return (default 100, max 200)
cursorNoPagination cursor for next page of results

TDQS

B3.3/5.0
Behavior2/5

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

No annotations are present, so the description carries the full burden. It does not disclose pagination behavior, rate limits, or whether deactivated users are included. The schema hints at pagination via cursor, but the description adds no extra context.

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 a single, clear sentence with no redundant or unnecessary information. It is efficiently front-loaded with the core action and resource.

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 list tool with two parameters and no output schema, the description is minimally adequate but lacks details like pagination behavior, what 'basic profile information' includes, or any example usage. It could be improved.

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%, with both parameters having descriptions in the schema. The tool description adds no additional meaning beyond the schema, so baseline score of 3 is appropriate.

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 verb 'get' and the resource 'list of all users', with the addition of 'basic profile information' specifying scope. It distinguishes from sibling tools like slack_get_user_profile which retrieves a single user.

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?

No guidance is provided on when to use this tool versus alternatives. For example, it could mention that for a single user's full profile, use slack_get_user_profile, or that the result is paginated.

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

slack_list_channelsA

List public and private channels in the workspace with pagination. Requires 'groups:read' scope for private channels.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of channels to return (default 100, max 200)
cursorNoPagination cursor for next page of results

TDQS

A3.9/5.0
Behavior3/5

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

In absence of annotations, the description carries full burden. It discloses the scope requirement but lacks details on rate limits, which channels are returned (membership-based), and response structure. This is adequate but not comprehensive.

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 focused sentences: first states the core action, second adds prerequisite. No extraneous words, front-loaded with key information.

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 list operation with no output schema, the description lacks details about what is returned per channel (e.g., id, name, topic), whether archived channels are included, and pagination specifics beyond cursors. Adequate for simple use but could improve.

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%, so baseline is 3. The description does not add parameter-specific information beyond the schema, which already describes limit and cursor with defaults.

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 tool lists public and private channels with pagination. The verb 'list' and resource 'channels' are specific, and the description distinguishes from sibling tools which perform different actions like adding reactions or getting messages.

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?

Specifies the required 'groups:read' scope for private channels, providing necessary context. However, it does not explicitly state when to use this tool versus alternatives, though siblings are sufficiently different that no exclusion is critical.

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

slack_post_messageB

Post a new message to a Slack channel

ParametersJSON Schema
NameRequiredDescriptionDefault
textYesThe message text to post
channel_idYesThe ID of the channel to post to

TDQS

B3.2/5.0
Behavior2/5

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

No annotations provided; the description only states the action. It does not disclose required permissions (scopes), whether the message is plain text or supports markdown, or any side effects like rate limits.

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 a single, direct sentence with no wasted words. It is sufficiently concise but could benefit from a slightly structured format.

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 simple tool with 2 parameters and no output schema, the description is minimal. It lacks information about the return value (e.g., message ID) and error cases, but is acceptable for basic usage.

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% with descriptions for both parameters. The description adds no extra meaning beyond what the schema provides, so baseline score of 3 is appropriate.

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 action (Post), resource (new message), and target (Slack channel). It distinguishes from siblings like slack_reply_to_thread and slack_add_reaction.

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?

No guidance on when to use this tool versus alternatives (e.g., reply vs post, or when formatting is supported). The description lacks context about prerequisites or use cases.

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

slack_reply_to_threadB

Reply to a specific message thread in Slack

ParametersJSON Schema
NameRequiredDescriptionDefault
textYesThe reply text
thread_tsYesThe timestamp of the parent message in the format '1234567890.123456'. Timestamps in the format without the period can be converted by adding the period such that 6 numbers come after it.
channel_idYesThe ID of the channel containing the thread

TDQS

B3.2/5.0
Behavior2/5

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

With no annotations, the description carries full burden for behavioral disclosure. It only mentions the action 'reply' but does not disclose any traits like rate limits, formatting constraints, required permissions, or what happens on invalid thread_ts.

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?

Single sentence, no fluff. It is appropriately sized for a simple action, though could be more informative.

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?

Given 3 required params, no output schema, and no annotations, the description is adequate but lacks details on return value or error scenarios. It covers the basic purpose but leaves gaps.

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%; the description adds no additional meaning beyond what the schema already provides. Baseline score of 3 applies.

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 verb 'reply', the resource 'specific message thread', and the platform 'Slack'. It is specific and distinguishes from siblings like slack_post_message (for new messages) and slack_get_thread_replies (for reading).

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?

No guidance on when to use this tool versus alternatives like slack_post_message. No mentions of prerequisites, best practices, or when not to use.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 8 tool updatesv0.6.2
    • First observedslack_add_reaction
    • First observedslack_get_channel_history
    • First observedslack_get_thread_replies
    • First observedslack_get_user_profile
    • First observedslack_get_users
    • First observedslack_list_channels
    • First observedslack_post_message
    • First observedslack_reply_to_thread
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.6/5.0

Scored across 8 tools

Disambiguation5/5

Each tool targets a distinct action: adding reactions, fetching history, retrieving threads, user profiles, user lists, channel lists, posting messages, and replying to threads. There is no ambiguity between tools.

Naming Consistency5/5

All tool names follow the consistent pattern 'slack_verb_noun' using snake_case, such as slack_get_channel_history and slack_post_message. No deviations.

Tool Count5/5

8 tools is well-suited for a Slack integration, covering core messaging, reactions, user and channel info, and threads. The count is neither too sparse nor excessive.

Completeness3/5

The set covers essential read and write operations but lacks message update/delete, channel creation, file uploads, and direct messaging. Notable gaps that agents may encounter.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers