A Slack MCP server with no bot token, because there is no Slack API call

An MCP server is a local program that exposes tools an AI coding assistant (Claude Code, Cursor, VS Code, Windsurf) can call over the Model Context Protocol. A Slack MCP server is one that makes Slack itself one of those tools. Every popular Slack MCP server today (Slack's own reference implementation, korotovsky/slack-mcp-server, the Workato connector, the PulseMCP listing) is a wrapper around Slack's Web API: you install a Slack app with a bot user, grant it OAuth scopes, and the server translates LLM tool calls into chat.postMessage, conversations.history, and similar HTTP requests. Terminator is a different shape of Slack MCP server: it is a general desktop automation MCP server that already knows how to drive any application, and Slack is one of those applications. The Slack surface comes for free with process:Slack selectors.

Four concrete reasons. First, many corporate and regulated Slack workspaces do not let you install arbitrary bot apps, so the bot-token route is a dead end before you start. Second, bots only see what they have been explicitly invited to; a desktop-driven agent sees every channel and DM the human is signed in to, which is usually the point. Third, Slack ships UI faster than API. Huddles, canvases, lists, and new reaction interactions show up in the client months before, and sometimes without ever, getting a first-class Web API endpoint. Fourth, you do not need to manage yet another token or workspace approval, because you are not installing anything into Slack. You are using the client a human is already using.

Through the same accessibility APIs a screen reader uses. On Windows that is UI Automation (UIA); on macOS it is the Accessibility API (AX). Slack's desktop client is Electron, and well-behaved Electron apps expose a usable accessibility tree. Terminator's selector engine matches strings like process:Slack >> role:Edit && name:Message against the nodes in that tree, then performs the action (click, type, invoke, press key) through the OS input pipeline. There is no HTTP call to slack.com in any of it. The MCP agent crate in the repo does not import a Slack SDK; a grep for xoxb, api.slack, chat.postMessage, or bot_token inside crates/terminator-mcp-agent/src returns zero matches.

Open crates/terminator-mcp-agent/src/prompt.rs. Lines 61-67 are a list of common process names, one of which is Slack. That block is pasted verbatim into the system prompt the MCP server announces at initialize time. It is the only place the string "Slack" appears in the MCP agent. The SDK list in llms.txt repeats the same entry on line 234. The benchmarks file references Slack only as a browser benchmark URL (slack.com/signin), not as an integration. That is the whole surface area of Slack knowledge the codebase has, and it is all accessibility-driven.

Both, with caveats. The Terminator core is cross-platform Rust, with platform adapters for Windows UI Automation and macOS AX. Coverage is best on Windows because UIA is the richer accessibility API and the MCP agent ships a Windows binary first. macOS works and is actively used, but depends on the app under automation exposing a clean AX tree. In practice Slack on both platforms is usable; if you hit a subtree the agent cannot match, you can fall back to coordinate-based clicks or OCR. Linux is best-effort via AT-SPI.

Those approaches take a screenshot, send it to a vision model, have the model decide where to click in pixel coordinates, and then the runtime issues a system-level click at those coordinates. That is one round-trip to an LLM per action and one loss-of-context per screenshot. Terminator uses structured accessibility data instead of pixels, so the LLM sees a tree of typed elements (role:Button, role:Edit, name:Send now) the same way Playwright lets it see a DOM. Actions happen at CPU speed, not LLM-inference speed. Vision is available as a fallback (there is a gemini_computer_use tool) but it is not the main path.

Yes, the same way you can: by focusing Slack, clicking into a DM, and reading the message text out of the accessibility tree. That is a strong capability and a strong responsibility. The agent runs on your endpoint under your user account, with whatever network identity you have. Anything it does in Slack is attributable to you, not to a bot. If you are building a Slack MCP workflow that reads DMs, make sure your policy is comfortable with that posture. The tradeoff is exactly the one you get by giving any local automation tool your logged-in session.

Slack's Web API has tier-based rate limits; chat.postMessage, for instance, is roughly one per second per channel, and the more expensive endpoints (conversations.history, search.messages) are tighter. Because Terminator does not hit the Web API, those limits do not apply. The effective limit is how fast the Slack client can update its UI and how fast the accessibility tree rebuilds. In practice this is fast enough for interactive agent use. If you are doing bulk data movement (exporting years of channel history) you should still use the Slack Export API or a proper dump tool; accessibility-driven scraping is the wrong shape for that.

claude mcp add terminator "npx -y terminator-mcp-agent@latest" -s user for Claude Code. For Cursor and VS Code there are deep-link install buttons in the Terminator MCP Agent README. The agent is published as an npm package that wraps a Rust binary; the editor spawns it as a child process over stdio by default, or over HTTP if you pass -t http. Once the server is attached, ask the LLM to do anything involving Slack, and it will pick process:Slack selectors on its own because the system prompt lists Slack as a known process.

Two places. First, when Slack renders a subtree as custom-painted pixels with no accessibility nodes underneath, selectors cannot match it and you fall back to coordinate clicks or vision. The Slack desktop client is mostly well-behaved about this but not universally. Second, when you need truly headless, server-side execution at scale with no human machine in the loop, accessibility-driven automation is not the right tool; you want the Slack Web API for that. Terminator is built for the case where there is a logged-in human and an agent is acting on their behalf, on their machine, inside the apps they already have open.