Provides tools for interacting with Slack workspaces, enabling AI assistants to manage channels, send and search messages, manage user profiles, handle file operations, and manage reactions.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Slack MCP Server summarize the latest discussion in the #project-alpha channel"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server for Slack API integration. This server allows AI assistants to interact with Slack workspaces through OAuth 2.0 authenticated user tokens.
Channel Operations: List channels, get channel info, get channel members
Message Operations: Read messages, send messages, reply to threads, search messages
User Operations: List users, get user info, get user profiles
File Operations: List files, get file info, upload files
Reaction Operations: Add/remove reactions, get message reactions
Related MCP server: Slack MCP Server
Node.js 18+
A Slack App with OAuth 2.0 configured
User token (xoxp-...) with appropriate scopes
npm install
npm run buildGo to api.slack.com/apps
Click "Create New App" → "From scratch"
Enter app name and select workspace
Add these User Token Scopes under "OAuth & Permissions":
channels:read # List channels
channels:history # Read channel messages
groups:read # List private channels
groups:history # Read private channel messages
im:read # List direct messages
im:history # Read direct messages
mpim:read # List group DMs
mpim:history # Read group DMs
chat:write # Send messages
users:read # List users
users.profile:read # Read user profiles
files:read # List files
files:write # Upload files
reactions:read # Read reactions
reactions:write # Add/remove reactions
search:read # Search messagesAdd your platform's callback URL under "OAuth & Permissions" → "Redirect URLs":
https://your-platform.com/oauth/slack/callbackNote down your:
Client ID
Client Secret
The MCP server reads credentials from environment variables:
# Required
SLACK_ACCESS_TOKEN=xoxp-your-user-token
# Optional
SLACK_TEAM_ID=T0123456789const SLACK_CLIENT_ID = 'your-client-id';
const REDIRECT_URI = 'https://your-platform.com/oauth/slack/callback';
const SCOPES = 'channels:read,channels:history,chat:write,users:read,files:read,files:write,reactions:read,reactions:write,search:read,groups:read,groups:history,im:read,im:history,mpim:read,mpim:history,users.profile:read';
const authUrl = `https://slack.com/oauth/v2/authorize?client_id=${SLACK_CLIENT_ID}&user_scope=${SCOPES}&redirect_uri=${encodeURIComponent(REDIRECT_URI)}&state=${generateRandomState()}`;
// Redirect user to authUrl// In your callback handler
app.get('/oauth/slack/callback', async (req, res) => {
const { code, state } = req.query;
// Verify state to prevent CSRF
if (!verifyState(state)) {
return res.status(400).send('Invalid state');
}
// Exchange code for token
const response = await fetch('https://slack.com/api/oauth.v2.access', {
method: 'POST',
headers: {
'Content-Type': 'application/x-www-form-urlencoded',
},
body: new URLSearchParams({
client_id: SLACK_CLIENT_ID,
client_secret: SLACK_CLIENT_SECRET,
code,
redirect_uri: REDIRECT_URI,
}),
});
const data = await response.json();
if (data.ok) {
// Save user token to your database
const userToken = data.authed_user.access_token; // xoxp-...
const userId = data.authed_user.id;
const teamId = data.team.id;
await db.saveSlackToken(currentUserId, {
token: userToken,
slackUserId: userId,
teamId: teamId,
});
res.redirect('/success');
} else {
res.status(400).send(`OAuth error: ${data.error}`);
}
});// When starting the MCP server for a user, inject their token as env var
const userSlackToken = await db.getSlackToken(currentUserId);
const mcpProcess = spawn('node', ['/path/to/slack-mcp/dist/index.js'], {
env: {
...process.env,
SLACK_ACCESS_TOKEN: userSlackToken,
},
});Add to your Claude Code configuration (~/.claude/claude_desktop_config.json):
{
"mcpServers": {
"slack": {
"command": "node",
"args": ["/path/to/slack-mcp/dist/index.js"],
"env": {
"SLACK_ACCESS_TOKEN": "xoxp-your-token"
}
}
}
}Tool | Description |
| List all accessible channels |
| Get channel details |
| Get channel member list |
Tool | Description |
| Get messages from a channel |
| Get replies in a thread |
| Send a message to a channel |
| Reply to a thread |
| Search messages (requires user token) |
Tool | Description |
| List workspace users |
| Get user details |
| Get user profile |
Tool | Description |
| List shared files |
| Get file details |
| Upload a file |
Tool | Description |
| Add emoji reaction |
| Remove emoji reaction |
| Get message reactions |
{
"tool": "slack_list_channels",
"arguments": {
"types": "public_channel,private_channel",
"limit": 50
}
}{
"tool": "slack_send_message",
"arguments": {
"channel_id": "C1234567890",
"text": "Hello from MCP!"
}
}{
"tool": "slack_search_messages",
"arguments": {
"query": "from:@user in:#channel important",
"count": 20
}
}The server returns structured error responses:
{
"error": "Slack API Error (invalid_auth): Invalid authentication token."
}Common error codes:
invalid_auth: Token is invalid
token_revoked: Token has been revoked
missing_scope: Token lacks required scope
channel_not_found: Channel doesn't exist
ratelimited: Rate limit exceeded
Never expose user tokens in client-side code
Store tokens securely in your database (encrypted)
Use HTTPS for all OAuth redirects
Validate state parameter to prevent CSRF
Rotate tokens periodically using refresh tokens
Request only necessary scopes
MIT
Add an emoji reaction to a message
| Name | Required | Description | Default |
|---|---|---|---|
| channel_id | Yes | The ID of the channel containing the message | |
| timestamp | Yes | Timestamp of the message (e.g., 1234567890.123456) | |
| emoji | Yes | Emoji name without colons (e.g., thumbsup, heart, rocket) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Add an emoji reaction') but does not cover critical aspects like required permissions (e.g., user authentication), potential side effects (e.g., notification to channel members), rate limits, or error handling, leaving significant gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence ('Add an emoji reaction to a message') that efficiently conveys the core action without any unnecessary words. It is front-loaded and appropriately sized for the tool's complexity, earning full marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's mutation nature (adding a reaction) and lack of annotations and output schema, the description is incomplete. It fails to address behavioral traits like permissions, side effects, or response format, which are crucial for an AI agent to use the tool effectively in a real-world context like Slack.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting all three required parameters (channel_id, timestamp, emoji) with examples. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline for high schema coverage without compensating value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Add') and resource ('emoji reaction to a message'), making the purpose specific and understandable. However, it does not explicitly differentiate from its sibling 'slack_remove_reaction', which performs the opposite action, leaving room for slight ambiguity in sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, such as 'slack_remove_reaction' for removing reactions or 'slack_send_message' for other interactions. It lacks context about prerequisites, permissions, or typical scenarios, offering minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific Slack channel
| Name | Required | Description | Default |
|---|---|---|---|
| channel_id | Yes | The ID of the channel (e.g., C1234567890) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it 'gets' information without disclosing behavioral traits. It doesn't cover permissions needed, rate limits, error handling, or what 'detailed information' includes (e.g., metadata, settings), which is a significant gap for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any fluff. It's front-loaded and appropriately sized, with every word contributing to clarity, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a simple input schema, the description is incomplete. It lacks details on what 'detailed information' entails, potential errors, or usage context, which is insufficient for an agent to fully understand the tool's behavior and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'channel_id' fully documented in the schema. The description adds no additional meaning beyond implying it's for a 'specific' channel, which the schema already covers. Baseline 3 is appropriate as the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 information about a specific Slack channel', making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'slack_list_channels' (which lists channels) or 'slack_get_channel_members' (which gets members), missing full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It doesn't mention prerequisites (e.g., needing channel ID), exclusions, or comparisons to siblings like 'slack_list_channels' for browsing or 'slack_get_channel_members' for member data, leaving usage context implied at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the list of members in a Slack channel
| Name | Required | Description | Default |
|---|---|---|---|
| channel_id | Yes | The ID of the channel (e.g., C1234567890) | |
| limit | No | Maximum number of members to return (max 1000) | |
| cursor | No | Pagination cursor for next page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but only states the basic action without details on permissions, rate limits, pagination behavior (implied by cursor parameter but not explained), or response format. This is inadequate for a tool with potential access and data constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and appropriately sized, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool with 3 parameters and potential complexity like pagination and member data retrieval. It fails to address behavioral aspects or return values, leaving significant gaps for an AI agent to understand full usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema fully documents parameters like 'channel_id', 'limit', and 'cursor'. The description adds no additional meaning beyond the schema, such as explaining member data format or pagination usage, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 'list of members in a Slack channel', making the purpose unambiguous. However, it does not differentiate from sibling tools like 'slack_get_channel_info' or 'slack_list_users', which might also retrieve member-related data, so it lacks specific sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, such as 'slack_get_user_info' for individual details or 'slack_list_users' for all users. It also omits prerequisites like needing channel access or authentication, leaving usage context implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about the currently active Slack workspace.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it 'gets information' but lacks details on what information is returned, potential errors, authentication needs, or rate limits, making it insufficient for a mutation-free but context-rich tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words, effectively front-loading the core action and resource. It earns its place by succinctly conveying the essential information without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters) but lack of annotations and output schema, the description is incomplete. It doesn't explain what 'information' is returned or any behavioral traits, leaving gaps that could hinder an agent's effective use in a Slack integration context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no parameter information is needed in the description. The baseline for this case is 4, as the description appropriately doesn't discuss parameters, focusing on the tool's purpose instead.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 'information about the currently active Slack workspace', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'slack_list_workspaces' or 'slack_get_user_info', which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It doesn't mention context like needing workspace details for setup or how it differs from 'slack_list_workspaces', leaving the agent to infer usage without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific file
| Name | Required | Description | Default |
|---|---|---|---|
| file_id | Yes | The ID of the file (e.g., F1234567890) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it 'gets detailed information,' implying a read-only operation, but doesn't specify what 'detailed information' includes (e.g., file metadata, permissions, size), whether it requires authentication, or any rate limits. This leaves significant gaps for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words. It's front-loaded with the core action and resource, making it efficient and easy to parse. Every part of the sentence contributes essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, 100% schema coverage) but lack of annotations and output schema, the description is incomplete. It doesn't explain what 'detailed information' entails in the response, which is critical for an agent to use the tool effectively. For a read operation with no structured output, more context on return values is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with 'file_id' clearly documented as 'The ID of the file (e.g., F1234567890).' The description adds no additional meaning beyond this, such as where to find the file ID or format constraints. Given the high schema coverage, a baseline score of 3 is appropriate as the schema handles the parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get detailed information') and resource ('about a specific file'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'slack_list_files' (which lists files) or 'slack_get_user_info' (which gets user info), so it doesn't fully distinguish its scope from similar operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. For example, it doesn't mention if this is for retrieving metadata after listing files with 'slack_list_files' or how it differs from other 'get' tools like 'slack_get_channel_info'. There's no context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get messages from a Slack channel
| Name | Required | Description | Default |
|---|---|---|---|
| channel_id | Yes | The ID of the channel (e.g., C1234567890) | |
| limit | No | Maximum number of messages to return (max 1000) | |
| cursor | No | Pagination cursor for next page | |
| oldest | No | Only messages after this Unix timestamp | |
| latest | No | Only messages before this Unix timestamp |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Get messages' but doesn't mention permissions needed (e.g., channel access), rate limits, pagination behavior beyond the cursor parameter, or what the return format looks like (e.g., list of message objects). This leaves significant gaps for a read operation with multiple parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any fluff or redundancy. It's front-loaded and appropriately sized for a straightforward retrieval tool, earning full marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, no output schema, no annotations), the description is incomplete. It doesn't explain the return values, error conditions, or behavioral nuances like pagination or filtering logic. For a tool with multiple input options and no structured output documentation, more context is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter well-documented in the schema (e.g., channel_id format, limit max, cursor for pagination, oldest/latest as Unix timestamps). The description adds no additional parameter semantics beyond the schema, so it meets the baseline of 3 for high coverage without extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 ('messages from a Slack channel'), making the purpose immediately understandable. However, it doesn't distinguish this tool from sibling tools like 'slack_search_messages' or 'slack_get_thread_replies', which also retrieve messages but with different scopes or filters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. With siblings like 'slack_search_messages' (for searching across channels) and 'slack_get_thread_replies' (for thread-specific messages), the agent lacks context on whether this tool is for general channel messages, how it differs, or any prerequisites for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all reactions on a specific message
| Name | Required | Description | Default |
|---|---|---|---|
| channel_id | Yes | The ID of the channel containing the message | |
| timestamp | Yes | Timestamp of the message (e.g., 1234567890.123456) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It states what the tool does but doesn't describe how it behaves: no information on permissions required, rate limits, pagination, error conditions, or output format. For a read operation with zero annotation coverage, this leaves critical behavioral traits unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any fluff. It's front-loaded with the core action and resource, making it easy to parse. Every word earns its place, achieving ideal conciseness for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (fetching reactions involves nested data like users and emojis), no annotations, and no output schema, the description is incomplete. It doesn't explain what the output contains (e.g., reaction types, user associations), error handling, or access requirements. For a tool with rich potential output and zero structured support, more descriptive context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters clearly documented in the schema. The description adds no additional parameter semantics beyond implying the tool operates on a 'specific message' (which the schema already covers via channel_id and timestamp). This meets the baseline of 3 when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('all reactions on a specific message'), making the purpose immediately understandable. It distinguishes from siblings like slack_get_messages or slack_get_thread_replies by focusing specifically on reactions. However, it doesn't explicitly mention what 'reactions' entail (e.g., emoji reactions with user info), which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It doesn't mention prerequisites (e.g., needing channel access), contrast with slack_get_messages (which might include reactions), or specify use cases like analyzing engagement. With multiple sibling tools available, this lack of contextual guidance is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get replies in a message thread
| Name | Required | Description | Default |
|---|---|---|---|
| channel_id | Yes | The ID of the channel containing the thread | |
| thread_ts | Yes | Timestamp of the parent message (e.g., 1234567890.123456) | |
| limit | No | Maximum number of replies to return | |
| cursor | No | Pagination cursor for next page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states what the tool does ('Get replies') but lacks critical details: it doesn't specify if this is a read-only operation, mention rate limits, describe pagination behavior (beyond the cursor parameter in the schema), or explain the return format. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence with no wasted words. It's front-loaded with the core purpose, making it easy to scan and understand quickly. Every word earns its place, adhering to best practices for brevity in tool descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a read operation with 4 parameters, 2 required), lack of annotations, and no output schema, the description is incomplete. It doesn't address behavioral aspects like safety, performance, or return values, leaving the agent with insufficient context to use the tool effectively beyond basic parameter input. More detail is needed to compensate for the missing structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters (channel_id, thread_ts, limit, cursor). The description adds no additional meaning beyond what's in the schema—it doesn't clarify parameter relationships, provide examples, or explain semantics like how 'thread_ts' identifies the parent message. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 ('replies in a message thread'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'slack_get_messages' or 'slack_search_messages', which might also retrieve message-related data, leaving some ambiguity about when this specific tool is uniquely appropriate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It doesn't mention prerequisites (e.g., needing a specific channel ID and thread timestamp), exclusions, or comparisons to siblings like 'slack_get_messages' (which might handle non-threaded messages). Usage is implied but not explicitly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific user
| Name | Required | Description | Default |
|---|---|---|---|
| user_id | Yes | The ID of the user (e.g., U1234567890) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it 'gets' information, implying a read-only operation, but doesn't specify permissions required, rate limits, error conditions, or what 'detailed information' entails (e.g., fields returned). This is inadequate for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It is appropriately sized and front-loaded, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is insufficiently complete. It doesn't explain what 'detailed information' includes (e.g., user properties), potential errors, or behavioral traits like authentication needs, leaving gaps for a tool that likely returns structured user data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'user_id' well-documented in the schema. The description adds no additional parameter details beyond what the schema provides, such as format examples or constraints, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get detailed information') and resource ('about a specific user'), making the purpose understandable. However, it doesn't distinguish this tool from its sibling 'slack_get_user_profile', which might provide similar user-related information, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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_user_profile' or 'slack_list_users'. It lacks context about prerequisites (e.g., needing a user ID) or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a user's profile information
| Name | Required | Description | Default |
|---|---|---|---|
| user_id | No | The ID of the user. If omitted, returns the authenticated user's profile |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action but doesn't mention authentication needs, rate limits, error handling, or what the profile information includes (e.g., fields like email, status, avatar). This is a significant gap for a tool that likely requires API access and returns structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any fluff or redundancy. It's front-loaded and wastes no words, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the profile information entails, how it's returned, or any behavioral traits like authentication requirements. For a tool that interacts with a platform like Slack, more context is needed to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting the optional 'user_id' parameter and its default behavior. The description doesn't add extra parameter details, which is acceptable given the high schema coverage, but it could have hinted at the default case more explicitly. With only one parameter well-covered, a baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('user's profile information'), making it immediately understandable. However, it doesn't differentiate from sibling tools like 'slack_get_user_info', which might retrieve similar or overlapping data, leaving some ambiguity about what distinguishes these tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, such as 'slack_get_user_info' or 'slack_list_users'. It lacks any context about prerequisites, use cases, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Slack channels (public and private) accessible to the user
| Name | Required | Description | Default |
|---|---|---|---|
| types | No | Comma-separated channel types: public_channel, private_channel, mpim, im | public_channel,private_channel |
| exclude_archived | No | Exclude archived channels | |
| limit | No | Maximum number of channels to return (max 1000) | |
| cursor | No | Pagination cursor for next page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool lists channels but doesn't mention pagination behavior (implied by 'cursor' parameter), rate limits, authentication requirements, or what the return format looks like (no output schema). For a list operation with 4 parameters, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that immediately conveys the core functionality without unnecessary words. It's appropriately sized for a list operation and front-loads the essential information ('List all Slack channels').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't address behavioral aspects like pagination, return format, or error conditions, nor does it provide usage guidance relative to sibling tools. The 100% schema coverage helps with parameters but doesn't compensate for other contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents all 4 parameters. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain the 'types' parameter values or 'cursor' usage). Baseline 3 is appropriate when the schema does all the parameter documentation work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all Slack channels') with scope ('public and private accessible to the user'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'slack_get_channel_info' or 'slack_list_workspaces', which would require more specific comparison context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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_channel_info' (for single channel details) or 'slack_list_workspaces' (for listing workspaces instead of channels). It mentions scope ('accessible to the user') but offers no explicit when/when-not instructions or sibling tool comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List files shared in the workspace
| Name | Required | Description | Default |
|---|---|---|---|
| channel | No | Filter files by channel ID | |
| user | No | Filter files by user ID | |
| types | No | Filter by file types (comma-separated): all, spaces, snippets, images, gdocs, zips, pdfs | |
| count | No | Number of files per page (max 100) | |
| page | No | Page number |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but only states the basic action. It doesn't cover critical aspects like pagination behavior (implied by 'count' and 'page' parameters but not explained), rate limits, authentication requirements, or what the output looks like (e.g., list format, error handling). This leaves significant gaps for an AI agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—it directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy for an AI agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a list operation with 5 parameters, no annotations, and no output schema, the description is incomplete. It lacks information on behavioral traits (e.g., pagination, errors), output format, and usage context. While the schema covers parameters well, the overall tool understanding remains inadequate for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, providing clear details for all 5 parameters (e.g., 'channel' filters by channel ID, 'types' with comma-separated values). The description adds no additional parameter semantics beyond the schema, so it meets the baseline of 3 where the schema does the heavy lifting but doesn't compensate or enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('files shared in the workspace'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'slack_get_file_info' (which retrieves details about a specific file) or 'slack_upload_file' (which uploads files), missing an opportunity for clearer sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It doesn't mention sibling tools like 'slack_search_messages' (which might find files in message content) or 'slack_get_file_info' (for specific file details), nor does it specify prerequisites such as authentication or workspace context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all users in the Slack workspace
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of users to return (max 1000) | |
| cursor | No | Pagination cursor for next page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('List all users') but doesn't mention key behaviors like pagination (implied by the 'cursor' parameter in the schema), rate limits, authentication requirements, or what the output format looks like (e.g., list of user objects). This leaves significant gaps for an agent to understand how to use it effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and easy to parse, earning its place by providing the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a list operation with pagination and no output schema or annotations, the description is incomplete. It doesn't cover behavioral aspects like pagination mechanics, response format, or error handling. For a tool with 2 parameters and no structured output information, more context is needed to guide an agent fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear documentation for 'limit' and 'cursor' parameters. The description doesn't add any semantic details beyond what the schema provides (e.g., it doesn't explain how pagination works or typical use cases for the parameters). Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all users in the Slack workspace'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'slack_get_user_info' or 'slack_get_user_profile', which might retrieve specific user details rather than listing all users.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. For example, it doesn't mention how this differs from 'slack_get_user_info' (which likely fetches a single user) or 'slack_get_user_profile' (which might retrieve profile details). There's no context on prerequisites, such as workspace access, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all connected Slack workspaces. Shows available workspaces and indicates which one is currently active.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool lists workspaces and indicates the active one, which is useful behavioral context. However, it lacks details on permissions needed, rate limits, error conditions, or the format of the returned list (e.g., pagination, fields included), leaving gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that are front-loaded with the core purpose ('List all connected Slack workspaces') and add valuable context ('Shows available workspaces and indicates which one is currently active'). Every sentence earns its place with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, no annotations, no output schema), the description is reasonably complete for a simple listing operation. However, without annotations or an output schema, it could benefit from more detail on the return format (e.g., structure of the list, what 'active' means) to fully guide the agent, leaving room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the input schema has 100% description coverage (though empty). The description does not need to add parameter semantics, so it appropriately focuses on the tool's purpose. A baseline of 4 is applied as there are no parameters to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'all connected Slack workspaces', specifying it shows available workspaces and indicates the active one. This distinguishes it from sibling tools like 'slack_get_current_workspace' (which might return only the active workspace) and 'slack_list_channels/users/files' (which list other resources).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by stating it lists workspaces and shows which is active, suggesting it's for discovering or managing workspace connections. However, it does not explicitly state when to use this tool versus alternatives like 'slack_get_current_workspace' or 'slack_switch_workspace', nor does it provide exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove an emoji reaction from a message
| Name | Required | Description | Default |
|---|---|---|---|
| channel_id | Yes | The ID of the channel containing the message | |
| timestamp | Yes | Timestamp of the message (e.g., 1234567890.123456) | |
| emoji | Yes | Emoji name without colons (e.g., thumbsup, heart, rocket) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Remove') which implies a mutation, but doesn't clarify permissions required, whether the operation is reversible, rate limits, or what happens on success/failure. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It's front-loaded with the core action and target, making it immediately understandable without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't address behavioral aspects like permissions, side effects, or response format. While concise, it lacks the completeness needed for safe and effective tool invocation in this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all three parameters. The description doesn't add any parameter-specific information beyond what's in the schema (e.g., it doesn't explain parameter relationships or provide examples). This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove') and target ('emoji reaction from a message'), making the purpose immediately understandable. It distinguishes from sibling tools like 'slack_add_reaction' by specifying removal rather than addition. However, it doesn't explicitly mention Slack as the platform, though this is implied by the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 doesn't mention prerequisites (e.g., needing appropriate permissions), when not to use it, or how it differs from similar tools like 'slack_get_reactions'. The agent must infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reply to a message thread in Slack
| Name | Required | Description | Default |
|---|---|---|---|
| channel_id | Yes | The ID of the channel containing the thread | |
| thread_ts | Yes | Timestamp of the parent message to reply to | |
| text | Yes | The reply text |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the action ('Reply to') which implies a write operation, but doesn't mention authentication needs, rate limits, error conditions, or what happens on success (e.g., whether it returns the new message timestamp). For a mutation tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with zero wasted words. It's front-loaded with the core action and immediately communicates the essential purpose. Every word earns its place, making it highly efficient for agent comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the tool returns, error conditions, or behavioral nuances. Given the complexity of a Slack API write operation and the lack of structured metadata, the description should provide more context about outcomes and constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all three parameters clearly documented in the schema. The description doesn't add any parameter-specific information beyond what's in the schema (e.g., format examples for thread_ts, character limits for text). This meets the baseline for high schema coverage but doesn't enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Reply to') and target ('a message thread in Slack'), making the purpose immediately understandable. It distinguishes this from sibling tools like 'slack_send_message' by specifying thread-based replies, though it doesn't explicitly contrast with all alternatives. The description avoids tautology by not just restating the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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_send_message' for non-threaded messages or 'slack_get_thread_replies' for reading threads. It doesn't mention prerequisites (e.g., needing an existing thread) or contextual constraints, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for messages across all channels (requires user token with search:read scope)
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query (supports Slack search syntax: from:user, in:channel, has:reaction, etc.) | |
| count | No | Number of results per page (max 100) | |
| page | No | Page number | |
| sort_by | No | Sort results by relevance score or timestamp | timestamp |
| sort_dir | No | Sort direction | desc |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds valuable context about authentication requirements ('requires user token with search:read scope'), which isn't covered elsewhere. However, it doesn't describe other behavioral traits like rate limits, pagination behavior beyond parameters, or what the search results look like (format, fields returned). This leaves gaps for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose and includes essential context (authentication requirement). Every word earns its place with zero waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (search across all channels with 5 parameters), no annotations, and no output schema, the description is incomplete. It covers authentication and purpose but lacks details on return values, error conditions, or behavioral constraints like rate limits. The high schema coverage helps, but for a search tool with no output schema, more context would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 all 5 parameters thoroughly (e.g., query syntax, count max, sort options). The description adds no additional parameter semantics beyond what's in the schema. According to the rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Search for messages') and scope ('across all channels'), distinguishing it from sibling tools like slack_get_messages (which retrieves messages from a specific channel) or slack_get_thread_replies (which focuses on thread replies). The verb+resource combination is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('Search for messages across all channels') and provides a prerequisite ('requires user token with search:read scope'). However, it doesn't explicitly mention when NOT to use it or name specific alternatives among the siblings (e.g., slack_get_messages for channel-specific retrieval), which prevents a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a message to a Slack channel
| Name | Required | Description | Default |
|---|---|---|---|
| channel_id | Yes | The ID of the channel to send the message to | |
| text | Yes | The message text to send | |
| thread_ts | No | Optional: Reply to a thread by providing the parent message timestamp |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool sends a message but does not mention any behavioral traits, such as permission requirements, rate limits, message formatting support (e.g., markdown), or error handling. This leaves critical operational details unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states the tool's function without unnecessary words. It is front-loaded and efficiently communicates the core purpose, making it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a message-sending tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral aspects, error cases, return values, and differentiation from siblings, making it insufficient for an agent to fully understand how to use the tool effectively in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, fully documenting all three parameters (channel_id, text, thread_ts). The description adds no additional semantic context beyond what the schema provides, such as examples or constraints, so it meets the baseline for adequate but unenhanced parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('send') and target ('a message to a Slack channel'), making the purpose immediately understandable. However, it does not differentiate this tool from its sibling 'slack_reply_to_thread', which also sends messages but in a specific context, leaving room for ambiguity in sibling selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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_reply_to_thread' for threaded replies or 'slack_upload_file' for file sharing. It lacks context about prerequisites, such as needing channel access or message formatting options, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Switch to a different Slack workspace. All subsequent Slack operations will use the selected workspace.
| Name | Required | Description | Default |
|---|---|---|---|
| team_id | Yes | The team/workspace ID to switch to (e.g., T0123456789) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it states the tool switches workspaces and affects subsequent operations, it lacks details on permissions needed, error conditions (e.g., invalid team_id), persistence of the switch, or whether it's reversible. For a state-changing tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and every word earns its place—no redundancy or fluff. It efficiently conveys the purpose and effect.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (state-changing with one parameter), no annotations, and no output schema, the description is minimally adequate. It covers the basic purpose and effect but lacks details on behavioral aspects like error handling or permissions, leaving gaps for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'team_id' documented in the schema. The description does not add any meaning beyond the schema (e.g., it doesn't explain how to obtain the team_id or provide examples). Baseline 3 is appropriate when the schema fully covers parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Switch to a different Slack workspace') and resource ('Slack workspace'), distinguishing it from all sibling tools which perform operations like sending messages, listing channels, or getting information. It explicitly defines the tool's scope and effect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('All subsequent Slack operations will use the selected workspace'), indicating it sets a workspace context for follow-up actions. However, it does not explicitly state when not to use it (e.g., if already in the desired workspace) or name specific alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload a file to a Slack channel
| Name | Required | Description | Default |
|---|---|---|---|
| channel_id | No | The ID of the channel to upload to | |
| content | Yes | File content as text | |
| filename | No | Filename with extension (e.g., report.txt) | file.txt |
| title | No | Title of the file | |
| initial_comment | No | Message to post along with the file | |
| thread_ts | No | Thread timestamp to upload file as a reply |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Upload' implies a write operation, it lacks details on permissions required, rate limits, file size constraints, error handling, or what happens on success (e.g., whether a file ID is returned). This is a significant gap for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It front-loads the core purpose ('Upload a file to a Slack channel') without unnecessary elaboration, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't address behavioral aspects like authentication needs, side effects, or return values, leaving gaps that could hinder an AI agent's ability to use the tool correctly in complex scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 all six parameters thoroughly. The description adds no parameter-specific information beyond implying file upload functionality, which is already clear from the tool name and schema. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Upload') and resource ('a file to a Slack channel'), making the purpose immediately understandable. It distinguishes this tool from siblings like 'slack_send_message' (which sends text messages) or 'slack_list_files' (which retrieves files), though it doesn't explicitly mention these distinctions in the description itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It doesn't mention prerequisites (e.g., needing channel access), exclusions (e.g., not for editing existing files), or comparisons to siblings like 'slack_send_message' for text-only communication or 'slack_list_files' for viewing files.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.1slack_add_reactionslack_get_channel_infoslack_get_channel_membersslack_get_current_workspaceslack_get_file_infoslack_get_messagesslack_get_reactionsslack_get_thread_repliesslack_get_user_infoslack_get_user_profileslack_list_channelsslack_list_filesslack_list_usersslack_list_workspacesslack_remove_reactionslack_reply_to_threadslack_search_messagesslack_send_messageslack_switch_workspaceslack_upload_fileEvery tool has a clearly distinct purpose with no ambiguity, as each targets a specific resource (e.g., channel, user, message, file) and action (e.g., get, list, send, upload). Overlap is minimal, such as slack_get_user_info and slack_get_user_profile, but their descriptions clarify distinct focuses on general info versus profile details.
Tool names follow a highly consistent verb_noun pattern throughout, all using snake_case with a 'slack_' prefix and clear action-resource combinations (e.g., slack_get_channel_info, slack_send_message). There are no deviations in style or convention, making them predictable and readable.
With 20 tools, the count is slightly high but reasonable for a comprehensive Slack integration covering channels, users, messages, files, and workspaces. It feels a bit heavy but not excessive, as each tool serves a specific function without obvious redundancy.
The tool set provides complete CRUD/lifecycle coverage for the Slack domain, including operations for channels (list, get, send), users (list, get info/profile), messages (send, get, search, react, thread), files (upload, list, get), and workspaces (list, switch, get). No significant gaps are apparent, enabling full agent workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Enable interaction with Slack workspaces. Supports subscribing to Slack events through Resources.
Query your team's drift, vulnerability, and upgrade data from any AI assistant. OAuth 2.1, 51 tools.
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
OAuth 2.1 short-link tools for AI agents with scoped tokens, approvals, audit logs, and revocation.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/iskifogl/slack-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
