Slack MCP: The Chief-of-Staff Workflow for Founders

Most founders do not need another Slack bot. They need a chief of staff. Someone who reads the overnight backlog before the first meeting, pulls out the two decisions that actually need an answer today, and quietly nudges the three people who owe a reply. A good chief of staff buys you back an hour every morning and prevents the kind of dropped-ball disasters that come from a two hundred unread channel count.

Slack's own AI summary feature does a small part of this. It gives you a reasonable paragraph about what happened in a channel while you were away. What it does not do is prioritise across channels, build a decision inbox, or watch for threads that have gone quiet when someone is waiting on you. That is the job the Slack MCP server can do once it is plugged into Claude Desktop, and the rest of this guide shows how to set it up in about twenty minutes and run it with the three prompt templates we hand to founder clients on day one.

Why MCP rather than a Slack app

There is a reason we steer non-technical founders towards Model Context Protocol rather than installing yet another Slack app from the directory. A typical Slack app runs on someone else's server, holds a copy of your message data, and asks you to trust both the vendor's retention policy and the vendor's AI pipeline. The Slack MCP server runs on your own machine, holds the token in your own keychain, and uses Claude as the reasoning engine, which means the privacy story is closer to "my laptop read my Slack" than "a SaaS vendor ingested my Slack."

The other reason is flexibility. A Slack app has a fixed feature set. The MCP pattern gives Claude a set of primitives, reading a channel, searching messages, posting a draft, reading a thread, and then you write natural-language instructions that compose those primitives into whatever workflow you need. Your morning brief, your decision inbox, and your delegation reminder are three different prompts against the same small toolset. If tomorrow you want a new workflow, you write a new prompt, not a new integration.

The 20-minute install

The install has three parts. You create a Slack app in your own workspace, you give it a small set of read scopes, and you point Claude Desktop at the MCP server with that app's token. No code, no server hosting, no deployment step.

Start at api.slack.com/apps and click Create New App, then From scratch. Pick a name that will be recognisable in your Slack audit log, such as Claude Chief of Staff, and select your workspace. Inside the new app, open OAuth and Permissions. This is the screen that decides what your MCP server can see.

For the chief-of-staff workflow we recommend a deliberately narrow scope set. Add channels:history, channels:read, groups:history, and groups:read for the channels you are a member of, public and private. Add users:read so Claude can resolve user IDs to names when it summarises. Add search:read so you can ask Claude to find past messages about a topic. Add chat:write only if you want Claude to post messages back to Slack, and even then we usually leave it off for the first week and have Claude draft to a document instead while you build trust. Do not add admin scopes, do not add files scopes, and do not add im:history unless you specifically want Claude to read your DMs, which is a different trust decision.

Install the app to your workspace. Slack shows you a User OAuth Token that starts with xoxp-. Copy it and treat it like a password, because that is what it is. If your workspace requires admin approval for new apps, your admin will get a request at this point and nothing will work until they approve, which is a useful control rather than a bug.

Next, install the Slack MCP server itself. The community reference implementation is distributed as an npm package, which means if you have Node.js on your machine the install is one line in a terminal, and if you do not, installing Node from nodejs.org is a five-minute detour. The package is typically installed globally so Claude Desktop can find it.

Now edit Claude Desktop's config file. On macOS it sits at Library, Application Support, Claude, claude_desktop_config.json. On Windows it is under AppData, Roaming, Claude. Add an entry under mcpServers that names the slack server, points at the command that runs it, and passes the xoxp token as an environment variable. Save the file and fully quit Claude Desktop, then reopen it. If the hammer icon in the chat input shows Slack tools in its list, the install worked. If it does not, the usual culprit is a stray comma in the JSON or the token pasted with a trailing newline.

The whole flow, from opening api.slack.com to seeing Slack tools in Claude, is about twenty minutes for a first-timer and closer to five once you have done it before.

The morning brief that actually prioritises

The out-of-the-box Slack AI summary reads one channel at a time. A founder's morning problem is the opposite: you want one reading of everything, weighted by what matters. The prompt we give clients for this is built around explicit priority tiers rather than a flat summary request.

The template looks like this. You tell Claude which channels are tier one, meaning anything posted there might need a reply from you today. These are usually the exec channel, the investor updates channel, and any channel where a customer escalation could land. You tell it which channels are tier two, meaning you want to know the headlines but you do not need detail. These are often the engineering and design channels where your team is self-managing. You tell it tier three is everything else, which should be collapsed into one sentence at most or skipped entirely.

Then you ask for the brief in a specific shape. Start with a Decisions Requiring You section listing anything where a team member is clearly waiting on your input, with a link to the message. Follow with a Key Updates section for tier-one information that does not need a reply but you should know, such as a deal closed or a production incident resolved. End with a Noise Floor paragraph of two or three lines covering everything in tier two and three.

The prompt works because it pushes Claude to make the prioritisation call rather than paraphrase everything at the same weight. When a channel has thirty messages in a thread but the only decision point is one question from a PM, Claude will surface the question rather than hand you a play-by-play of the thread. When a channel had a hundred engineering messages that amounted to "shipped the feature," you get one line.

A refinement that clients love after the first week is a time-window parameter. The default is since my last active session, which Claude estimates by looking at when you last posted. You can override it with since yesterday 6pm or in the last 18 hours when you want a custom window, for example after a weekend.

The decision inbox pattern

The morning brief is great for starting the day. It is less useful during the day, when decisions are landing in threads across twenty channels and you are trying to keep track of what you have already answered and what is still waiting. The decision inbox pattern solves this with a combination of a pinned message and a Claude-driven summariser that runs on demand.

The setup is simple. In a private channel that only you use, pin one message titled Decision Inbox. That is the anchor. Then you write a Claude prompt, saved as a snippet you can invoke at will, that does the following: search Slack for messages in the last forty-eight hours that mention me, or that are in tier-one channels and end with a question mark, or that use phrases like "thoughts?" or "what do you think" or "blocked on." For each match, classify it as needs decision, needs acknowledgement, or informational. Return the needs-decision items as a numbered list with the channel name, the asker's name, and a one-sentence summary of what they are asking. Drop the others.

What you get back is a compact inbox of real decisions, not a feed of messages. You walk through it the way you would walk through email, answering each one in Slack and then re-running the prompt an hour later. Because Claude is classifying based on content, not on Slack's unread status, it catches the important questions buried inside a long thread that you already skimmed and marked as read.

The pinned Decision Inbox message serves two purposes. It gives you a stable location in Slack to paste Claude's output each time, so over time you get a visible record of what the inbox looked like each day. It also gives your team a signal: if something matters, they should phrase it as a question in a tier-one channel, because that is where the inbox looks.

Clients sometimes extend this by letting Claude post the inbox itself into the pinned channel, which requires the chat:write scope we left off earlier. We recommend waiting two weeks before turning that on. You want to trust the classifier before you let it post.

Delegation reminders and the follow-up checker

The third chief-of-staff workflow is the one that saves founders from dropping balls on their own team. You asked someone to do something three days ago, you moved on, you assume it is handled, and it is not, and nobody flagged it because they did not want to chase. A good chief of staff tracks those open loops and pokes.

Claude can do this with a prompt we call the follow-up checker. The logic is as follows. Search Slack for messages I posted in the last fourteen days that contain phrases like "can you," "could you," "please," "would you mind," or a mention of a team member followed by an imperative verb. For each match, open the thread and check whether the person I addressed has replied substantively. A reply of "on it" or "ack" counts as an acknowledgement but not as completion. A reply that describes the work done counts as completion. No reply at all is a red flag.

Return a list of open loops with the person's name, the request summary, the date you asked, and the current state: unacknowledged, acknowledged, or no visible completion. Order by oldest first, because the old ones are the ones most likely to have fallen through.

The output is a polite and accurate nudge list. You glance at it, pick the two or three items that genuinely need chasing, and either send a Slack message yourself or ask Claude to draft a gentle follow-up that you then send. The tone of the drafts matters. We have Claude write in a low-pressure register, typically "hey, circling back on X, no rush but wanted to make sure it was not blocked," because a chief-of-staff nudge that reads as a manager demand damages trust quickly.

Run this prompt once a day, usually at the end of the day when you have bandwidth to send the follow-ups. Some founders run it at the start of the week instead, as part of a Monday planning ritual. The cadence matters less than the consistency.

Keeping the founder in the loop

A pattern we insist on with every founder client is that Claude does not post to Slack unattended during the first month. Every draft, every summary, every nudge goes to a document or a private channel first, and you forward the ones that are worth sending. This is not because the model is unreliable. It is because your voice in Slack is part of your leadership, and you want to notice the cases where Claude's phrasing does not sound like you before they go out. After a month you will have a mental model of which workflows you trust to auto-post and which you want to keep reviewing, and you can loosen the leash selectively.

The other guardrail worth naming is scope discipline. It is tempting, once the MCP server is working, to add files:read so Claude can summarise shared documents, or im:history so it can read your DMs for context. Resist both for at least the first few weeks. The workflows in this guide work with the minimal scope set, and every additional scope expands the blast radius if the token ever leaks. When you do add a scope later, do it deliberately, for a workflow that clearly needs it, not preemptively.

Where this goes next

Once the three core workflows are running, the natural extensions are a weekly investor update draft, generated from the same channels the morning brief reads, and a customer-signal digest that pulls mentions of specific competitor names or product keywords from your sales and support channels. Both are straightforward prompt additions against the same MCP server, not new installs. The pattern is always the same: small scopes, natural-language prompts, Claude as the reasoning layer, and you as the editor.

If you would rather skip the configuration dance and have this working by the end of today, the WitsCode Slack MCP setup does the app creation, scope selection, token handling, Claude Desktop config, and the three prompt templates as a single guided session. The deliverable is a working chief-of-staff workflow on your own machine, with the tokens in your own keychain, and a short handover doc that tells you how to change the prompts as your company evolves. -> WitsCode Slack MCP setup.