Which integrations are available for this server?

Provides read-only access to Slack workspaces, including listing channels, retrieving channel history and thread replies, looking up user information, listing users, and searching messages.

How do I use slack-readonly-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@slack-readonly-mcp list the recent messages in #general" 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.

slack-readonly-mcp

by tomfunk

Overview Schema Related Servers Score Discussions

JavaScript

Local

slack-readonly-mcp

A self-hosted, read-only Slack MCP server for Claude Code (and any MCP client).

Why this exists

Hosted Slack MCP connectors route your Slack message content through a third-party hosted MCP layer. If you care about where that data goes, that hop sits outside your control. This server avoids it:

It runs locally as a stdio subprocess that the MCP client launches.
It calls the Slack Web API directly with your own token.
Tool results flow only into your MCP client's context → whatever model endpoint you've configured (e.g. an org with zero data retention).

So the full path is: your machine → Slack API → your MCP client → your model endpoint. No third-party MCP intermediary. Data-retention guarantees are a property of the model endpoint you point the client at — this server doesn't change them, it only adds tools.

Note: Data that lives in Slack is governed by your Slack plan, not by this server. This server only governs the path between Slack and your client.

Related MCP server: Slack MCP Server

Tools (all read-only)

Tool	Purpose
`slack_list_channels`	List channels (id, name, topic, members)
`slack_channel_history`	Recent messages in a channel
`slack_thread_replies`	All replies in a thread
`slack_conversations_info`	Metadata for one channel
`slack_user_info`	Look up a user (email omitted)
`slack_list_users`	List workspace users (email omitted)
`slack_search_messages`	Search messages — requires a user token (see below)

Setup

1. Create a Slack app with read-only scopes

At https://api.slack.com/apps → Create New App → From a manifest, paste:

display_information:
  name: Claude Read-Only
oauth_config:
  scopes:
    bot:
      - channels:read
      - channels:history
      - groups:read
      - groups:history
      - im:read
      - im:history
      - mpim:read
      - mpim:history
      - users:read
    user:
      - search:read   # optional — only needed for slack_search_messages
settings:
  org_deploy_enabled: false
  socket_mode_enabled: false

Install it to the workspace, then copy the Bot User OAuth Token (xoxb-…). If you want search, also copy the User OAuth Token (xoxp-…). Invite the bot to any private channels you want it to read (/invite @Claude Read-Only).

2. Build

npm install
npm run build

3. Register with Claude Code

claude mcp add slack-readonly \
  --env SLACK_BOT_TOKEN=xoxb-your-token \
  -- node /path/to/slack-readonly-mcp/dist/index.js

Or, for a project-scoped .mcp.json (keep the token in your shell env, not in the file — Claude Code expands ${VAR}):

{
  "mcpServers": {
    "slack-readonly": {
      "command": "node",
      "args": ["/path/to/slack-readonly-mcp/dist/index.js"],
      "env": {
        "SLACK_BOT_TOKEN": "${SLACK_BOT_TOKEN}",
        "SLACK_USER_TOKEN": "${SLACK_USER_TOKEN}"
      }
    }
  }
}

Search caveat

Slack's search.messages endpoint cannot be called with a bot token — it requires a user token. Set SLACK_USER_TOKEN (xoxp-…, search:read) to enable slack_search_messages; without it, the other six tools work and search returns a clear error.

Notes

All logging goes to stderr; stdout is the JSON-RPC channel.
The server fails fast (exit 1) if SLACK_BOT_TOKEN is unset.
Read-only by design. Adding write tools (post/reply/react) means adding write scopes — a deliberately separate, larger-blast-radius change.

License

MIT

Available Tools

7 tools

slack_channel_historyA

Read recent messages from a Slack channel (read-only). Provide the channel id (e.g. C0123ABCD), not the name — resolve names via slack_list_channels first.

ParametersJSON Schema

Name	Required	Description
`channel`	Yes	Channel id, e.g. C0123ABCD.
`limit`	No	Number of messages (default 30).
`oldest`	No	Only messages at or after this Unix ts, e.g. 1700000000.000000.
`latest`	No	Only messages at or before this Unix ts.
`cursor`	No	Pagination cursor from a previous response.

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. It discloses the read-only nature and that it returns recent messages, but lacks details on response format, pagination behavior, rate limits, or what 'recent' means. The schema covers parameters, but the description adds no extra behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with an immediate follow-up instruction. It is front-loaded with the core purpose and presents the key usage tip without any superfluous words.

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

Completeness4/5

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

Given the tool's simplicity (5 parameters, 1 required, no output schema, no annotations), the description covers the essential usage context. It could mention result ordering or pagination, but the sibling list provides additional context, making it sufficient for an agent to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds value by clarifying the channel parameter must be an ID (not a name) and referencing slack_list_channels for resolution, but does not elaborate on other parameters beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's action ('Read recent messages') and resource ('from a Slack channel'), and notes it is read-only. It distinguishes itself from siblings by specifying that channel IDs (not names) are required and instructing to resolve names via slack_list_channels first.

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

Usage Guidelines4/5

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

The description explicitly advises to use slack_list_channels first to resolve channel names to IDs, providing clear prerequisite context. It implies the tool is for reading only, but does not explicitly list when not to use it or mention alternatives like slack_search_messages or slack_thread_replies.

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

slack_conversations_infoA

Get metadata for a single Slack channel by id (read-only): name, topic, purpose, member count, archived state.

ParametersJSON Schema

Name	Required	Description	Default
`channel`	Yes	Channel id, e.g. C0123ABCD.

TDQS

A4.3/5.0

Behavior4/5

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

Description discloses the read-only nature and lists returned metadata fields, which is good behavioral transparency. However, it does not mention potential errors (e.g., invalid channel id) or authentication requirements, but given no annotations, this is adequate for a simple read tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence that is front-loaded with the purpose and includes a colon to introduce the returned fields. No wasted words; efficiently conveys essential information.

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

Completeness5/5

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

The tool is simple with one parameter and no output schema. The description sufficiently covers the tool's purpose, input, and output (metadata fields). No missing critical information given the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already describes the 'channel' parameter (100% coverage). The description adds value by enumerating the metadata fields returned, which helps the agent understand what the tool provides beyond the parameter itself.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the verb 'Get metadata' and the resource 'single Slack channel by id', listing specific fields returned (name, topic, purpose, member count, archived state). It distinguishes from siblings like slack_list_channels (lists all) and slack_channel_history (history).

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

Usage Guidelines3/5

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

Description implies usage context (getting metadata for a specific channel by id) but does not explicitly provide when-to-use or when-not-to-use guidance, nor does it mention alternative sibling tools. The guidance is 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.

slack_list_channelsA

List Slack channels the bot can see (read-only). Returns each channel's id, name, topic, and member count. Use the returned id with slack_channel_history — most other tools take an id (C0123ABCD), not a name.

ParametersJSON Schema

Name	Required	Description
`types`	No	Comma-separated channel types: public_channel, private_channel, mpim, im. Default public_channel.
`limit`	No	Max channels to return (default 100).
`cursor`	No	Pagination cursor from a previous response's next_cursor.

TDQS

A4.2/5.0

Behavior3/5

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

No annotations provided, so the description carries the full burden. It declares the tool as read-only and lists return fields, but does not elaborate on pagination behavior, rate limits, scope requirements, or what happens with empty results. The schema describes the pagination cursor but the description does not mention it.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, each adding distinct value. Front-loaded with the main action and return type, followed by critical usage guidance. No wasted words.

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

Completeness4/5

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

For a simple listing tool with 3 optional parameters and no output schema or annotations, the description is mostly complete. It covers purpose, return fields, and usage context. Could mention pagination or default channel types more explicitly, but overall adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All three parameters (types, limit, cursor) are fully described in the schema (100% coverage). The description adds only minimal value beyond the schema by listing return fields but does not enrich parameter understanding. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'list' and resource 'Slack channels', specifies it is read-only, and mentions the returned fields (id, name, topic, member count). It distinguishes from siblings by noting that the returned id is used with slack_channel_history and that other tools require id, not name.

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

Usage Guidelines5/5

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

Explicitly states when to use this tool: to get channel ids for use with other tools like slack_channel_history. It provides a critical usage hint that most other tools take an id (C0123ABCD), not a name, which helps the agent select the correct tool and invoke it properly.

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

slack_list_usersA

List Slack workspace users (read-only). Returns id, name, real name, and bot flag. Email is intentionally omitted.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Max users to return (default 100).
`cursor`	No	Pagination cursor from a previous response.

TDQS

A4/5.0

Behavior3/5

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

The description declares the tool is read-only and notes the intentional omission of email, providing some behavioral context. However, without annotations, additional details like rate limits or pagination behavior are missing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no wasted words. Front-loaded with the core action and key constraints.

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

Completeness4/5

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

For a simple list tool with 2 parameters, the description covers the returned fields, omissions, and read-only nature. Lack of output schema is compensated by the explicit return field list.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but description adds value by stating the default limit of 100, which is not in the schema. It does not elaborate on cursor, but the schema description for cursor is already present.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (listing users), resource (Slack workspace users), and explicitly lists the returned fields (id, name, real name, bot flag). It distinguishes itself from sibling tools like slack_user_info by noting it returns a list.

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

Usage Guidelines3/5

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

No explicit guidance on when to use this tool over alternatives such as slack_user_info for a single user. Usage is implied but not differentiated.

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

slack_search_messagesA

Search messages across the workspace (read-only). Requires a user token (SLACK_USER_TOKEN with search:read) — bot tokens cannot search. Supports Slack search operators like in:#channel, from:@user, before:YYYY-MM-DD.

ParametersJSON Schema

Name	Required	Description
`query`	Yes	Search query, e.g. "deploy in:#general from:@someuser before:2026-01-01".
`count`	No	Results per page (default 20).
`page`	No	Page number (default 1).

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It discloses read-only behavior and auth requirements, but does not cover pagination behavior, rate limits, or error conditions. Adds moderate context beyond the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (3 sentences), front-loaded with purpose, and every sentence adds necessary information without waste.

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

Completeness3/5

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

Given no output schema, the description should explain return values or result behavior. It covers purpose, auth, and query format, but lacks details on response structure (e.g., timestamp, channel) or pagination handling, leaving some ambiguity for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description adds value by discussing Slack search operators, but the schema already provides examples for query and descriptions for count/page. The additional context is useful but not extensive.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool searches messages across the workspace and is read-only. It distinguishes itself from channel-specific siblings like slack_channel_history by the cross-workspace scope, though it does not explicitly name alternatives.

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

Usage Guidelines4/5

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

The description provides clear usage context: requires a user token with search:read scope, explicitly states bot tokens cannot search, and mentions Slack search operators. It does not, however, explicitly guide when to use this over sibling tools.

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

slack_thread_repliesA

Read all replies in a Slack thread (read-only). Provide the channel id and the parent message's ts (thread_ts).

ParametersJSON Schema

Name	Required	Description
`channel`	Yes	Channel id, e.g. C0123ABCD.
`ts`	Yes	Thread parent ts, e.g. 1700000000.000100.
`limit`	No	Max replies to return (default 50).
`cursor`	No	Pagination cursor from a previous response.

TDQS

A4/5.0

Behavior3/5

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

Description notes 'read-only', which is helpful. No annotations provided, so description carries full burden. Lacks mention of pagination (limit/cursor), default behavior, or error states.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single focused sentence with no unnecessary words, front-loading purpose and key arguments effectively.

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

Completeness4/5

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

Given low complexity (4 params, no output schema), description covers purpose and required args. Could mention pagination or response format but not critical.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so description adds no new meaning beyond what the schema already provides. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states verb 'Read' and resource 'replies in a Slack thread'. It distinguishes from siblings like slack_channel_history which reads all channel messages, not thread-specific.

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

Usage Guidelines4/5

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

Explicitly asks for channel and ts, providing clear required inputs. However, no explicit when-not-to-use compared to alternatives; sibling slack_channel_history is implied but not stated directly.

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

slack_user_infoA

Look up a Slack user by id (read-only). Returns display name, real name, and timezone. Email is intentionally omitted.

ParametersJSON Schema

Name	Required	Description	Default
`user`	Yes	User id, e.g. U0123ABCD.

TDQS

A4/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. Describes read-only behavior, return fields (display name, real name, timezone), and explicitly notes email omission. Does not cover rate limits or error states, but adequate for simple lookup.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two efficient sentences with no fluff. Front-loaded with purpose and key constraints.

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

Completeness4/5

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

Complete for a simple one-parameter lookup tool. Specifies output fields and intentional omission. Lacks details on missing user behavior, but acceptable without output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% (one parameter well-described). Description adds no additional parameter details beyond mentioning lookup by id, but baseline 3 is appropriate given complete schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clear verb 'look up' and resource 'Slack user by id'. Specifies returned fields and intentionally omitted email. Distinguishes from sibling tools like slack_list_users that list all users.

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

Usage Guidelines3/5

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

Implies usage for individual user lookup but no explicit guidance on when to use vs. slack_list_users (retrieve all users) or when not to use. No context on prerequisites or error handling.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

7 tool updatesv0.1.0Jun 25, 2026
- First observedslack_channel_history
- First observedslack_conversations_info
- First observedslack_list_channels
- First observedslack_list_users
- First observedslack_search_messages
- First observedslack_thread_replies
- First observedslack_user_info

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: listing vs single item, history vs search, threads vs general messages, users vs user info. No overlap.

Naming Consistency5/5

All tools follow the consistent 'slack_verb_noun' pattern (e.g., slack_list_channels, slack_user_info). Minor variation between 'channel_history' and 'conversations_info' but both are noun phrases in the same style.

Tool Count5/5

7 tools is well-scoped for a read-only Slack server, covering channel exploration, history, threads, user info, and search without being excessive.

Completeness4/5

Covers core read operations (channel list, history, threads, users, search). Minor gaps like reading pinned messages or files, but these are less critical for a read-only interface.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

thoughtsOAuth
ai.thoughtbox.api
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
Cloud Storage Finance
2
HubSpotOAuth
com.hubspot.app
The HubSpot MCP Server acts as a bridge that enables AI assistants and Large Language Models to securely interact with HubSpot CRM data through natural conversation, without requiring users to understand complex API structures. It provides read-only access to standard CRM objects (contacts, companies, deals, tickets, products, invoices, and more) and their associations, secured via OAuth 2.0, allowing AI agents to perform tasks like summarizing deals, fetching company updates, and looking up record changes.
Customer Data Platforms Databases Marketing
3
twitterapi-mcp-server A
io.github.kaitoInfra
Twitter/X read-only MCP server — 12 tools: search, users, tweets, followers, timelines, trends.
Social Media Search
121
The Quiet Protocol Growth Offense MCP A
com.thequietprotocol.www
Read-only MCP server for The Quiet Protocol's engines, benchmarks, proof, and business data.
Databases Research & Data Finance
292

Related MCP Servers

Slack MCP Server
aryahadii
A
license
Not graded
quality
D
maintenance
A Model Context Protocol server that provides read-only access to Slack data including messages, channels, and users through secure API endpoints.
Updated a year ago (2025-07-18 11:03 UTC)
MIT
Slack MCP Server
Communication Search
mynghn
A
license
Not graded
quality
D
maintenance
A read-only MCP server that enables AI assistants to access Slack workspace data, including channels, messages, threads, and user information.
Updated 8 months ago (2025-12-28 09:16 UTC)
24,316
3
MIT
slack-mcp
Communication Search
duolingo
A
license
Not graded
quality
B
maintenance
Read-only MCP server for Slack with OAuth 2.1 authentication, enabling message retrieval, thread replies, search, user and channel listing.
Updated a month ago (2026-07-23 21:09 UTC)
8
Apache 2.0
Slack MCP Server
Communication Workplace & Productivity
reazon-rudel
A
license
Not graded
quality
C
maintenance
Self-hosted MCP server for Slack using User OAuth Token, enabling message management, channel operations, and user interactions via natural language.
Updated 3 months ago (2026-06-21 09:05 UTC)
54
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/tomfunk/slack-readonly-mcp'

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