Slack API용 MCP 서버를 사용하면 Claude가 사용자로서 Slack 작업 공간과 상호 작용할 수 있습니다.
slack_list_channels
작업 공간에 공개 채널 나열
선택 입력 사항:
limit (숫자, 기본값: 100, 최대: 200): 반환할 최대 채널 수
cursor (문자열): 다음 페이지의 페이지 번호 커서
반환: ID와 정보가 포함된 채널 목록
slack_post_message
Slack 채널에 새 메시지 게시
필수 입력 사항:
channel_id (문자열): 게시할 채널의 ID
text (문자열): 게시할 메시지 텍스트
반환: 메시지 게시 확인 및 타임스탬프
slack_reply_to_thread
특정 메시지 스레드에 답장하기
필수 입력 사항:
channel_id (문자열): 스레드가 포함된 채널
thread_ts (문자열): 부모 메시지의 타임스탬프
text (문자열): 응답 텍스트
반환: 응답 확인 및 타임스탬프
slack_add_reaction
메시지에 이모티콘 반응 추가
필수 입력 사항:
channel_id (문자열): 메시지가 포함된 채널
timestamp (문자열): 반응할 메시지 타임스탬프
reaction (문자열): 콜론 없는 이모티콘 이름
반환: 반응 확인
slack_get_channel_history
채널에서 최근 메시지 가져오기
필수 입력 사항:
channel_id (문자열): 채널 ID
선택 입력 사항:
limit (숫자, 기본값: 10): 검색할 메시지 수
반환: 콘텐츠 및 메타데이터가 포함된 메시지 목록
slack_get_thread_replies
메시지 스레드의 모든 답변 가져오기
필수 입력 사항:
channel_id (문자열): 스레드가 포함된 채널
thread_ts (문자열): 부모 메시지의 타임스탬프
반환: 콘텐츠 및 메타데이터가 포함된 답변 목록
slack_get_users
기본 프로필 정보가 포함된 작업 공간 사용자 목록 가져오기
선택 입력 사항:
cursor (문자열): 다음 페이지의 페이지 번호 커서
limit (숫자, 기본값: 100, 최대: 200): 반환할 수 있는 최대 사용자 수
반환: 기본 프로필이 있는 사용자 목록
slack_get_user_profile
특정 사용자에 대한 자세한 프로필 정보를 얻으세요
필수 입력 사항:
user_id (문자열): 사용자의 ID
반환: 자세한 사용자 프로필 정보
Related MCP server: Slack MCP Server
Slack 앱 만들기:
Slack 앱 페이지를 방문하세요
"새로운 앱 만들기"를 클릭하세요
"처음부터"를 선택하세요
앱 이름을 지정하고 작업 공간을 선택하세요
사용자 토큰 범위 구성: "OAuth 및 권한"으로 이동하여 다음 범위를 추가합니다.
channels:history - 공개 채널의 메시지 및 기타 콘텐츠 보기
channels:read - 기본 채널 정보 보기
chat:write - 본인 계정으로 메시지 보내기
reactions:write - 메시지에 이모티콘 반응 추가
users:read - 사용자 및 기본 정보 보기
작업 공간에 앱 설치:
"작업 공간에 설치"를 클릭하고 앱을 승인합니다.
xoxp- 로 시작하는 "사용자 OAuth 토큰"을 저장하세요.
이 지침 에 따라 팀 ID( T 로 시작)를 얻으세요.
claude_desktop_config.json 에 다음을 추가하세요.
먼저 서버를 설치하고 빌드하세요.
지엑스피1
그런 다음 Claude Desktop을 구성합니다.
{
"mcpServers": {
"slack": {
"command": "npm",
"args": [
"run",
"--prefix",
"/path/to/slack-user-mcp",
"start"
],
"env": {
"SLACK_TOKEN": "xoxp-your-user-token",
"SLACK_TEAM_ID": "T01234567"
}
}
}
}{
"mcpServers": {
"slack": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-slack-user"
],
"env": {
"SLACK_TOKEN": "xoxp-your-user-token",
"SLACK_TEAM_ID": "T01234567"
}
}
}
}{
"mcpServers": {
"slack": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"-e",
"SLACK_TOKEN",
"-e",
"SLACK_TEAM_ID",
"mcp/slack-user"
],
"env": {
"SLACK_TOKEN": "xoxp-your-user-token",
"SLACK_TEAM_ID": "T01234567"
}
}
}
}Smithery 를 통해 Claude Desktop용 Slack 사용자 서버를 자동으로 설치하려면:
npx -y @smithery/cli install @lars-hagen/slack-user-mcp2 --client claude권한 오류가 발생하면 다음 사항을 확인하세요.
모든 필수 범위가 Slack 앱에 추가되었습니다.
앱이 작업 공간에 제대로 설치되었습니다.
토큰과 작업 공간 ID가 구성에 올바르게 복사되었습니다.
앱이 접근해야 하는 채널에 추가되었습니다.
봇 토큰이 아닌 사용자 OAuth 토큰(xoxp-로 시작)을 사용하고 있습니다.
Docker 빌드:
docker build -t mcp/slack-user -f src/slack/Dockerfile .이 MCP 서버는 MIT 라이선스에 따라 라이선스가 부여됩니다. 즉, MIT 라이선스의 조건에 따라 소프트웨어를 자유롭게 사용, 수정 및 배포할 수 있습니다. 자세한 내용은 프로젝트 저장소의 LICENSE 파일을 참조하세요.
Add a reaction emoji to a message
| Name | Required | Description | Default |
|---|---|---|---|
| channel_id | Yes | The ID of the channel containing the message | |
| timestamp | Yes | The timestamp of the message to react to | |
| reaction | Yes | The name of the emoji reaction (without ::) |
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.
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.
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.
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.
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.
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.
Get recent messages from a channel
| Name | Required | Description | Default |
|---|---|---|---|
| channel_id | Yes | The ID of the channel | |
| limit | No | Number of messages to retrieve (default 10) |
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 ('Get recent messages') but doesn't mention critical details like whether this requires specific permissions, rate limits, pagination behavior, or what 'recent' means (e.g., time-based or count-based). This leaves significant gaps for a tool that likely interacts with an external API.
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 wasted words. It's appropriately sized and front-loaded, 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 the complexity of a Slack API tool with no annotations and no output schema, the description is incomplete. It doesn't address behavioral aspects like authentication needs, error handling, or return format (e.g., message objects with timestamps). For a tool that retrieves data from an external service, more context is needed to ensure proper 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?
The input schema has 100% description coverage, with clear documentation for 'channel_id' and 'limit' (including a default value). The description adds no additional meaning beyond the schema, such as explaining channel ID formats or limit constraints. With high schema coverage, the baseline score of 3 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 verb ('Get') and resource ('recent messages from a channel'), making the purpose understandable. However, it doesn't distinguish this tool from sibling tools like 'slack_get_thread_replies' or 'slack_list_channels', which also retrieve Slack data, so it misses full differentiation.
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 clarify if this is for general channel history versus thread-specific replies (handled by 'slack_get_thread_replies') or user-focused data (handled by 'slack_get_user_profile'). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all replies in a message thread
| Name | Required | Description | Default |
|---|---|---|---|
| channel_id | Yes | The ID of the channel containing the thread | |
| thread_ts | Yes | The 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. |
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.
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.
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.
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.
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.
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.
Get detailed profile information for a specific user
| Name | Required | Description | Default |
|---|---|---|---|
| user_id | Yes | The ID of the user |
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.
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.
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.
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.
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.
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.
Get a list of all users in the workspace with their basic profile information
| Name | Required | Description | Default |
|---|---|---|---|
| cursor | No | Pagination cursor for next page of results | |
| limit | No | Maximum number of users to return (default 100, max 200) |
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.
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.
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.
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.
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.
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.
List public channels in the workspace with pagination
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of channels to return (default 100, max 200) | |
| cursor | No | Pagination cursor for next page of results |
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 helpfully mentions pagination behavior, which is valuable context not in the schema. However, it doesn't disclose important traits like rate limits, authentication requirements, whether this requires specific permissions, or what the response format looks like (especially critical with no output schema).
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 perfectly concise - a single sentence that communicates the core functionality and key behavioral trait (pagination) with zero wasted words. It's front-loaded with the essential information and earns its place efficiently.
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 read-only listing tool with 2 well-documented parameters, the description is minimally adequate. However, with no annotations and no output schema, it should ideally provide more context about response format, error conditions, or typical use cases. The pagination mention helps, but doesn't fully compensate for the missing structured information.
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 already fully documents both parameters (limit and cursor). The description adds no additional parameter semantics beyond what's in the schema - it mentions pagination generally but doesn't explain parameter interactions or usage patterns. 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 verb ('List') and resource ('public channels in the workspace'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'slack_get_users' or 'slack_get_channel_history' which also retrieve Slack data, leaving some ambiguity about when this specific listing tool is preferred.
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 whether this is for initial discovery, filtering criteria, or how it relates to sibling tools like 'slack_get_channel_history' or 'slack_get_users'. The agent must infer usage context 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.
Post a new message to a Slack channel
| Name | Required | Description | Default |
|---|---|---|---|
| channel_id | Yes | The ID of the channel to post to | |
| text | Yes | The message text to post |
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.
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.
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.
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.
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.
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.
Reply to a specific message thread in Slack
| Name | Required | Description | Default |
|---|---|---|---|
| channel_id | Yes | The ID of the channel containing the thread | |
| thread_ts | Yes | The 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. | |
| text | Yes | The reply text |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0slack_add_reactionslack_get_channel_historyslack_get_thread_repliesslack_get_user_profileslack_get_usersslack_list_channelsslack_post_messageslack_reply_to_threadScored across 8 tools
Each tool has a clearly distinct purpose targeting specific Slack operations: adding reactions, retrieving channel history, fetching thread replies, getting user profiles, listing users, listing channels, posting messages, and replying to threads. There is no overlap or ambiguity between these functions.
All tool names follow a consistent 'slack_verb_noun' pattern using snake_case, such as slack_post_message and slack_get_user_profile. This uniformity makes the tool set predictable and easy to navigate.
With 8 tools, the server is well-scoped for a Slack integration, covering essential messaging, user management, and channel operations. Each tool serves a clear purpose without redundancy, making the count appropriate for the domain.
The tool set provides strong coverage for core Slack workflows, including message posting, reactions, threading, and user/channel listing. Minor gaps exist, such as updating or deleting messages, but agents can likely work around these with the available tools.
Enable interaction with Slack workspaces. Supports subscribing to Slack events through Resources.
Catch up on Slack without reading it. Unreads, threads, search. Browser-session or hosted OAuth.
Messaging tools for AI agents: send messages, manage chats, groups and channels.
Appreciate teammates, celebrate milestones, and run workspace ops from MCP clients via OAuth.
