The MCP Stack We Install for Every Small Business

Every small business we onboard to Claude ends up with roughly the same five MCP servers connected. Not because we are lazy, but because these five cover the surface area where the actual work happens. Email lands. Meetings are booked. Customers are tracked. Team chatter happens in channels. Code and docs live in repos. Everything else a business cares about is either downstream of these or not safe to hand an agent yet.

This article walks through the exact stack, the order we install it in, the scopes we grant each server, and the single rule that keeps the whole thing from turning into a security incident. It is the same checklist a WitsCode engineer uses on day one of an install.

Why a stack, not a server list

If you search for MCP servers you will find indexes with fifty or a hundred entries. That is useful as a catalogue and useless as a starting point. Small businesses do not need a hundred integrations. They need five, chosen so that a single prompt like "summarise the three threads from the sales channel this morning, update the HubSpot record for the deal mentioned, and draft a reply to the client" actually executes end to end.

A stack is different from a list because each server in the stack assumes the ones before it. Slack is more useful when Claude already has calendar context. HubSpot updates are more useful when Claude already knows what was said in Slack about the customer. GitHub matters last because most small businesses only touch repos for the product side, not for the day to day operations. Installing in the wrong order produces an agent that can read a repo but cannot tell you whether the meeting about that repo happened.

Install order and why sequencing matters

The order is Google Workspace first, Slack second, records system third, GitHub last. We have tried reordering this and it always produces worse outcomes in the first two weeks.

Workspace goes first because inbox and calendar are where a business owner spends their actual time. If Claude can read this morning's email and see today's calendar, it already replaces roughly a third of the manual copy paste work most owners do before lunch. Second, Slack, because comms context is the glue between inbox intent and team action. Third, the records layer, either HubSpot or Notion depending on whether the business is sales led or operations led. Last, GitHub, and only if the business ships code or keeps docs in repos. If the business is a bakery with no GitHub, skip it. There is no points prize for installing more servers.

Sequencing also matters because each install should be verified before the next one goes in. Verification is a thirty second thing. Ask Claude "list the calendar events you can see for tomorrow" after the Workspace install. Ask "list the public channels you can see" after Slack. If the answer is wrong, fix the scope before you stack another server on top of it.

Google Workspace, the inbox layer

Workspace covers Gmail, Calendar, Drive and Docs. This is the first install because it is the layer with the highest daily touch and the lowest risk if scoped correctly.

The scope rule here is read-only unless writing calendar. Gmail should be gmail.readonly. Drive should be drive.readonly. Calendar is the exception because the primary useful action, booking a meeting, requires write, so grant calendar.events. Do not grant gmail.modify or gmail.send on day one. The cost of Claude drafting a reply as a draft and you clicking send is negligible. The cost of Claude sending a wrong email to a customer is not.

A minimal server configuration for Claude Desktop looks like this:

{
  "mcpServers": {
    "google-workspace": {
      "command": "npx",
      "args": ["-y", "@google/workspace-mcp"],
      "env": {
        "GOOGLE_OAUTH_SCOPES": "gmail.readonly,calendar.events,drive.readonly"
      }
    }
  }
}

Authenticate with a user OAuth token tied to the founder's account, not a service account with domain-wide delegation. Domain-wide delegation is the fast way to hand Claude every inbox in the company, which is also the fast way to regret it.

Slack, the comms layer

Slack sits second because it is where the team narrates the work that Workspace surfaces. The scope we use is channels:read, channels:history, chat:write, and users:read. That is enough to read public channels, read message history, post replies, and resolve names to people.

What we do not grant is admin.*, groups:* for private channels, or im:history for DMs. Private channels and DMs are where the sensitive conversation happens, and an agent has no business reading them by default. If a particular workflow needs access to one private channel, invite the Slack app into that single channel. Slack respects that as a scoping mechanism and you get the benefit without the blast radius.

The installation is a Slack app, not a user token. Create a new workspace app called something like "Claude Ops", set the scopes, install to the workspace, and use the bot token in the server config:

"slack": {
  "command": "npx",
  "args": ["-y", "@modelcontextprotocol/server-slack"],
  "env": {
    "SLACK_BOT_TOKEN": "xoxb-...",
    "SLACK_TEAM_ID": "T0123456"
  }
}

After install, verify by asking Claude to list channels and read the last five messages from one of them. If you see messages from a channel the bot has not been invited to, something is wrong with your scopes and you should rotate the token.

HubSpot and Notion, the records layer

The records layer is where customer and knowledge state lives. For sales led businesses, that is HubSpot. For ops led businesses, that is Notion. Most businesses that grow past ten people end up running both, with HubSpot holding customer records and Notion holding internal knowledge. Install whichever matches the larger daily use first, then add the second if needed.

HubSpot scopes should be contacts, deals, companies, and engagements. That is enough for Claude to read the CRM, update a contact's notes, move a deal stage, and log an email engagement. Do not grant account-info.admin or automation write access. Automations are the thing that fire email sequences at thousands of people. An agent that fires the wrong sequence is a full day of cleanup and an apology email.

"hubspot": {
  "command": "npx",
  "args": ["-y", "@hubspot/mcp-server"],
  "env": {
    "HUBSPOT_ACCESS_TOKEN": "pat-...",
    "HUBSPOT_SCOPES": "crm.objects.contacts.write,crm.objects.deals.write,crm.objects.companies.write"
  }
}

Notion is different because its permission model is per page rather than per scope. Create an internal integration in the Notion settings, give it a name like "Claude Ops", and then explicitly share the pages and databases you want Claude to reach. Do not share the whole workspace. The default instinct is to share the top level page because that feels convenient; the correct move is to share only the CRM database, the meeting notes database, and the SOP page you want drafted from.

"notion": {
  "command": "npx",
  "args": ["-y", "@notionhq/notion-mcp-server"],
  "env": {
    "NOTION_API_KEY": "secret_..."
  }
}

Verify by asking Claude to fetch one page and update a test entry. If Claude can see a page you did not intend to share, revoke the integration from that page in the Notion share menu.

GitHub, the operations layer

GitHub comes last because for most small businesses it is optional. If the business ships software, or if the team keeps runbooks and design docs in a repo, it earns a place in the stack. Otherwise skip it.

Use a fine-grained personal access token, not a classic token and not an OAuth app with org admin. Fine-grained tokens let you pick exactly which repositories the token can touch and which permissions it carries inside those repos. The minimum useful set is contents:read for reading code and docs and issues:write for filing and updating issues. Pull request write is the next step up and should only be granted when a specific review workflow is in place.

"github": {
  "command": "npx",
  "args": ["-y", "@modelcontextprotocol/server-github"],
  "env": {
    "GITHUB_PERSONAL_ACCESS_TOKEN": "github_pat_..."
  }
}

The token should never be scoped to the whole organisation. Pick the two or three repos that matter and list them explicitly in the token's repository access field. If the business ever onboards a new repo, rotate the token with the new repo included rather than leaving a broader token in place.

The scope rules that keep this safe

One rule ties the whole stack together: do not grant org admin to Claude. Not to the Slack workspace, not to the Google domain, not to the HubSpot portal, not to the GitHub organisation. Every one of these platforms offers a path to "just give this app admin and move on". That path is how small businesses end up with an agent that can DM the entire company or delete a production repo.

A second rule that helps in practice: prefer read-only until a specific write workflow is defined. Write access should follow a named use case. "Claude drafts calendar invites for sales calls" is a named use case and earns calendar write. "Claude might need to edit things sometimes" is not a use case and earns nothing.

A third rule: rotate tokens on a schedule, and always rotate after any employee with access to the setup leaves. Every MCP server config above uses an environment variable for the token, which means rotation is a config change and a restart, not a rewrite. Treat these tokens like production secrets because that is effectively what they are.

What we deliberately leave out

The stack above is five servers. Requests for a sixth come up often and we usually say no for the first month. Finance tools like Stripe and QuickBooks are the most common ask, and they are also the most dangerous. An agent that moves a record in HubSpot can be corrected with an undo. An agent that refunds the wrong invoice or issues a chargeback costs real money and customer trust. We wait until there is a named workflow with explicit human review, then we connect finance with read-only scopes first.

HR tools are the second common ask. Payroll, benefits, and employee records carry legal exposure that small businesses rarely appreciate until something goes wrong. We leave these out of the default stack entirely and handle them through dedicated, audited processes instead.

Production infrastructure, meaning servers, cloud accounts, and deployment pipelines, is the third. GitHub is the boundary of what we connect. Anything downstream of a deploy, including AWS, Vercel, or a database, stays behind the engineering team's own tooling. An agent pausing a production instance at the wrong time is an outage, not a workflow improvement.

The pattern across all three holdouts is the same. If the blast radius of a single wrong tool call is larger than a five minute cleanup, it does not belong in the default stack. It belongs in a second, more carefully scoped setup that we layer on only after the first five servers are stable and the team has a feel for how the agent behaves.

A 30 minute install plan

For a new client we block thirty minutes and install the stack live. Workspace takes about eight minutes including the OAuth consent and a verification prompt. Slack takes six, mostly spent creating the app and inviting it to the right channels. HubSpot or Notion takes another six. GitHub, if the business needs it, is the fastest at roughly four minutes with a pre-scoped token. The last six minutes are spent running one end to end prompt that touches all five servers, so the founder sees the stack working as a stack rather than as a pile of integrations.

The end to end prompt we use is deliberately mundane. Something like "read the last hour of the sales channel, find the customer name, pull their HubSpot record, check my calendar for the next open slot tomorrow, draft a reply in Gmail suggesting that slot, and log the engagement in HubSpot". Every server participates. If any link in the chain fails, the prompt surfaces it immediately and we fix scopes before we leave.

That is the whole stack. Five servers, installed in order, scoped narrowly, verified out loud, and rotated on a schedule. It covers most of what a small business does in a day, and it does so without handing an agent keys to anything it does not need. Once the stack is live and the team has used it for a couple of weeks, we come back and look at which scopes have been exercised and which ones have sat idle. Idle scopes are the first thing to trim, because an unused permission is all downside and no upside. The stack stays small on purpose, and so does the surface area of trust you extend to it.

->

If you want the same stack installed, scoped, and verified in one session, the WitsCode team does this as a fixed engagement. We bring the config templates, the scope checklist, and the verification prompts, and we leave you with a working stack rather than a folder of API keys. Book an install and we will have you running end to end workflows the same day.