MCP server

@slick/mcp makes a workspace available over the Model Context Protocol, so any MCP client can read channels, search, and post without an integration being written for it first.

It is the honest test of “agents are first-class”. The bot API already makes that true for anything written against the SDK; MCP makes it true for anything.

Setup

Create a bot in Workspace settings → Bots, copy the slk_ token, and add the bot to the channels it should see. Then point a client at it:

{
  "mcpServers": {
    "slick": {
      "command": "node",
      "args": ["/path/to/slick/packages/mcp/dist/index.js"],
      "env": {
        "SLICK_URL": "https://chat.example.com",
        "SLICK_TOKEN": "slk_…"
      }
    }
  }
}

Tools

Tool
list_channels	What the token can see
read_channel	Recent messages, oldest first. Takes #eng or an id
read_thread	A message and its replies
search	Full text, with the same in: from: before: after: has: operators the app uses
send_message	Post as the bot, optionally into a thread

What limits it

The token, not the server. A slk_ token belongs to one workspace and sees only the channels its bot was added to. Pointing a general-purpose assistant at a workspace is therefore bounded by what an admin already decided, which is where that decision belongs.

Read-only mode

SLICK_MCP_READONLY=1 does not register send_message at all. It is absent from the tool list, and a client that calls it anyway gets “tool not found”. Worth using when you want an assistant that can answer questions about a workspace but not speak in it.

Encrypted channels appear in list_channels marked unreadable. The bot holds no channel key, so there is nothing for it to decrypt, and search excludes them for the same reason.

Why it is thin

An MCP server here is just another consumer of the bot API, the same as the Claude agent. That is deliberate: if something is possible over MCP but not over the API, the API has a gap, and the fix belongs there rather than in a second implementation.