OpenClaw’s Slack MCP Bridge Turns a Documented Skill Into a Callable Tool Surface

OpenClaw PR #86246 looks like a Slack integration patch. It is really a permissions-design patch. The difference matters because agent platforms are entering the phase where “documented capability” and “callable tool surface” have to become the same thing — without turning every plugin into an unbounded pile of authority.

The PR adds a Slack bridge to the OpenClaw-tools MCP server so Claude Code and other MCP-only harnesses can invoke Slack actions through mcp__openclaw__slack. Until now, OpenClaw could document Slack actions in skills/slack/SKILL.md, and the Slack channel plugin could implement them, but harnesses constrained to the mcp__openclaw__* tool namespace had no callable Slack tool. The agent could know what it should do and still be unable to do it through the permissions surface it was actually allowed to use.

That is not merely inconvenient. That is how permission systems decay.

Documentation is not a tool grant

The PR was created on May 25 at 2026-05-25T00:53:35Z. At research time it was open, non-draft, marked mergeable_state: unstable, and labeled agents, size: L, and triage: needs-real-behavior-proof. The patch is substantial but contained: 6 files changed, 696 additions and 1 deletion. The implementation adds src/agents/tools/slack-tool.ts, mapping a typed action enum and parameters into callGatewayTool("message.action", ...) with channel: "slack". The MCP server then registers createSlackTool() next to createCronTool() in resolveOpenClawToolsForMcp().

The covered actions are normal channel operations: react, reactions, sendMessage, editMessage, deleteMessage, readMessages, pinMessage, unpinMessage, listPins, memberInfo, emojiList, uploadFile, and downloadFile. The PR explicitly does not add Slack admin operations such as conversations.create, users.lookupByEmail, or apps.manifest.create. That restraint is the important part.

OpenClaw’s Slack channel is registered through defineBundledChannelEntry, which means it does not automatically enter the bundle/MCP tool catalog. Claude Code launches with an allowed-tools pattern that can include OpenClaw MCP tools, but not the raw channel plugin. Issue #74757 called out the footgun: the skill tells the agent Slack actions exist, but the harness has no reachable MCP tool for them. Operators then face two bad options. Either the workflow stays broken, or they loosen tool permissions until the harness can reach more than it should.

A typed bridge is the cleaner design. It creates one MCP catalog entry with a narrow action list, while preserving the existing Slack channel plugin’s account scoping, credentials, dispatch path, and message-action semantics. The bridge does not invent a second Slack integration. It exposes the existing one through the constrained surface the harness is allowed to call.

The admin APIs staying out is the feature

The temptation with bridges like this is to make them comprehensive. If Slack has an API, surely the agent should be able to call it. That instinct is how agent platforms end up with permission surfaces that look tidy in demos and terrifying in audits. Reacting to a message and creating a Slack channel are not the same class of authority. Reading recent messages and looking up users by email are not the same privacy boundary. Uploading a file and managing an app manifest do not belong under the same casual “Slack tool” umbrella.

PR #86246’s decision to leave admin operations out of scope is good permission design. Admin APIs require different token scopes, different operator intent, and likely a separate opt-in story. They also require different audit language. “Agent pinned a message” is a channel action. “Agent created a workspace channel” is administration. The bridge should not collapse those categories just because both are Slack-shaped.

The test payload is also worth noting. The PR includes src/agents/tools/slack-tool.test.ts and src/mcp/openclaw-tools-serve.test.ts, with 40 tests passing across 3 files. Existing Slack channel suites — 155 tests across 6 files — also passed. For a bridge that is mostly glue, that is the right proof shape: verify the new mapping and make sure the old channel behavior did not regress.

MCP governance is about enabling the right tools, not just blocking the wrong ones

The fashionable security conversation around MCP focuses on dangerous tools: shell access, filesystem writes, browser automation, secret reads. That conversation is necessary, but incomplete. A permission system also fails when legitimate work is unavailable through the approved path. If the agent is supposed to operate in Slack, and the safe harness policy only permits mcp__openclaw__*, then Slack actions must exist inside that surface or users will route around the policy.

This is the boring way permission systems rot. Not through a villain demanding root access. Through papercuts. The documented workflow does not work, so someone expands allowedTools. The bridge is missing one action, so someone grants access to the whole plugin. A narrow task needs one capability, so the platform hands over five. Six months later, the audit says the agent had more authority than anyone intended, and everyone acts surprised.

For practitioners, the takeaway is to audit the gap between skill documentation and callable tools. If your OpenClaw harness is MCP-constrained, ask whether every documented workflow has a matching MCP surface. Then ask whether that surface is narrower than the underlying plugin. The ideal shape is exactly what #86246 attempts: a typed bridge over existing gateway policy, an explicit action enum, no admin spillover, and tests proving the bridge maps to the channel contract rather than bypassing it.

This is also a useful comparison point for Claude Code, Codex, Gemini CLI, and other coding-agent harnesses. The winner will not simply be the runtime with the most integrations. It will be the runtime that turns integrations into auditable, least-privilege tools without making operators choose between broken workflows and blanket access. Slack reactions and pins are one permission class. Slack administration is another. The bridge gets that right.

Sources: OpenClaw PR #86246, OpenClaw issue #74757, OpenClaw Slack skill, Model Context Protocol