How to connect Slack to Hermes Agent

Pairing is a two-step handshake: run hermes clawlink begin, approve the link in your browser, then run hermes clawlink finish. If you ran finish before approving, or the approval link expired, run hermes clawlink begin again to get a fresh link. Confirm the plugin was installed with --enable, then verify with hermes clawlink test.

Reconnect Slack from the dashboard, then start a fresh chat if the runtime still has the old tool catalog loaded.

Slack tool schemas load on demand the first time a tool runs and are cached after that, so this error usually clears on its own: wait a few seconds and retry the same request. If every Slack call keeps failing with it in a fresh chat, reconnect from the dashboard, and contact support if it still persists — that pattern points to a configuration problem on our side, not something you can fix by reconnecting again.

Two usual causes. The connected account may not have access to the specific workspace, inbox, store, or project in the request — check that first. If access looks right, the agent may have sent a placeholder value (like "YOUR_ID" or an example id from documentation) instead of a real one: ask it to run a list or search tool first, then retry the action with a real id from those results. Most failures at this stage are one of these two, not ClawLink bugs.

The AI Overview's fix for this error is to add scopes, reinstall the app, and verify channel membership. Reinstallation does not exist in a hosted flow, because the scopes are fixed at consent and the app is not yours to reinstall. Two causes cover the hosted case. The connected account may lack access to the specific channel or workspace in the request; check with slack_list_all_channels or slack_fetch_conversation_history first. Or the agent sent a placeholder id like YOUR_ID instead of a real channel id; Slack display names are not unique, so a name that looks right can still fail. Run a list tool, take a real id from the result, and retry.

Ask the agent to diagnose it:

List the Slack channels I have access to and identify which channel the failing call targets. Then retry with the exact channel id from that list.

This error phrase comes from the self-hosted world, where you paste SLACK_BOT_TOKEN into an env file and discover the token's scopes are too narrow. There is no bot token here, so there is no scope list to edit. The connection carries the user scopes approved at consent, including channels:history, chat:write, and search:read. When a tool call fails on permissions, the cause is the account's own access inside the workspace, not a token scope. Reconnecting does not change what the account can reach.

Ask the agent to diagnose it:

Tell me which Slack tool failed and what action it needed. Then run slack_list_all_channels and slack_fetch_conversation_history on the target channel and tell me what you can actually read.

Slack rate limits are per app, and the app behind this connection is the one ClawLink runs, not a token you manage. The response to a limit carries a retry-after value; honoring it is the fix, and pacing bursty calls (a prompt that fires many message sends at once) prevents most occurrences. No specific number is claimed here because the limits depend on the backend app's distribution, which is not published on this page. If the agent hits the limit repeatedly, the shape of the work is the cause, not the connection.

Ask the agent to diagnose it:

Report the exact status and any retry-after value from the failed Slack call. Do not retry until that interval has passed.

The results for this phrase assume a local MCP setup: SLACK_BOT_TOKEN and SLACK_TEAM_ID env vars, a claude_desktop_config.json entry, or a Dynamic Client Registration bug. None of those exist in a hosted connection. Here a tool-not-found response means the tool name was wrong or the schema catalog had not loaded when the call went out. Schemas load on demand, so one retry clears the second case; for the first, the error message lists the closest real tool names, and retrying with one of those works.

Ask the agent to diagnose it:

List the Slack tools you actually have access to, then use the exact name for what I asked.

Try reconnecting Slack and complete the consent flow in the same browser session. Partial OAuth approvals or switching accounts mid-flow can leave the connection incomplete.

Yes. ClawLink is the fastest way to connect Hermes to Slack: link your Slack account once in the browser and Hermes Agent can call the Slack API through 145 ready-made tools — no custom code or token handling.

Install the plugin with hermes plugins install ClawLink-HQ/hermes-plugin --enable, then pair once: run hermes clawlink begin, approve the link in your browser, and run hermes clawlink finish. Connect Slack in the dashboard and Hermes can use it from the next message — no config files or API keys to manage.

About two minutes. Sign in, click Connect next to Slack in the dashboard, authenticate, and Hermes Agent can use it from the next chat message.

The alternative to ClawLink is usually manual OAuth app setup plus your own token handling, permission troubleshooting, and tool plumbing for Hermes Agent. That is fine if you want to build and maintain the integration yourself. Most teams just want Slack working from chat.

Search results answer this in two camps: forum threads warning that blind whole-workspace access is dangerous, and agent docs that treat access as solved. Both are half right. The risk is not the connection, it is the blast radius of what the agent can touch. This connection uses user-scope OAuth, so the agent reaches what your Slack account can reach inside the workspace you approve, and the scopes (channels:history, chat:write, search:read, and the rest) are listed before you click allow. You can start read-only by using only the search and history tools, keep the agent out of channels you do not name for it, and revoke the connection from the ClawLink dashboard at any time. The harder risk is prompt injection: a message or file written by another person can carry instructions aimed at the agent. Treat channel content as untrusted input, and require confirmation before any write action.

No. The connection is user-scope OAuth against the Slack app ClawLink runs. You see Slack's consent screen, click allow, and the connection exists. There is no api.slack.com/apps registration, no manifest, no Socket Mode, and no xoxb- or xapp- token. The AI Overview's phrase about Slack agents fundamentally requiring authentication tokens is true for a self-hosted bot and false here; the only authorization step is the consent screen itself.

The Overview describes the manual hermes-agent path: write a manifest, register a Slack app, enable Socket Mode, copy tokens, run hermes gateway setup. That flow works, and the runtime it pairs is the same Nous Research hermes-agent this page connects. What differs is who owns the app and where the tokens live. ClawLink runs the Slack app and stores the OAuth grant server-side; the agent calls the 145 tools over MCP without you creating or maintaining an app. If you are mid-way through the manual flow, the connected account is a separate grant and the two can run side by side.

All 145, subject to the scopes approved at consent and to your account's own permissions in the workspace. The agent can read and write what you can: send messages, search, schedule, pin, archive, and manage channels. Tools that need admin rights fail the way you would fail when you call them yourself. One tool is the exception to the acts-as-you rule: slack_get_bot_user fetches a specified bot user in the workspace and does not work for regular accounts, which the schema states.

Pairing is a two-step handshake: run hermes clawlink begin, approve the link in your browser, then run hermes clawlink finish. If you ran finish before approving, or the approval link expired, run hermes clawlink begin again to get a fresh link. Confirm the plugin was installed with --enable, then verify with hermes clawlink test.