MCP setup for a 15-person team: what breaks

Fifteen people. No IT department. Just a developer who was the first to get Claude and other AI tools talking to the team's actual work — Slack, the accounting app, the CRM, GitHub, the shared drive.

It works great for about six weeks. Then it starts breaking in ways nobody planned for.

It starts with one connection

Someone wants Claude to read invoices from Xero. There's a community MCP server for Xero, and it gives you two ways to connect: a full OAuth flow, or a simpler bearer token you generate once in Xero's own settings and paste into the server's configuration. Bearer token, obviously — why do the OAuth dance for an internal tool.

Except "paste into the server's configuration" means: install Node.js if it isn't already on this machine, edit a JSON file by hand, and launch the server with npx. None of that has anything to do with the credential. It's just what running a local MCP server looks like, and it's the same set of unfamiliar steps whether the app behind it needs a token or not.

The developer does this in ten minutes without thinking about it. Then a non-technical coworker tries to do the same thing for their own laptop, and the ten minutes turns into a screen-share.

Not every server works this way

Here's the part that makes this harder to reason about, not easier: half the team's other apps don't use a config file at all. HubSpot and Zoho, for instance, connect over OAuth — no token to paste anywhere, just a browser popup and a "click to authorize" screen the first time you use the tool.

So "setting up MCP" isn't one repeatable process. It's two different processes that happen to look similar from the outside, and which one you get depends on which app you're connecting that week.

The multiplication nobody notices

Neither path stays a one-person problem for long.

The token-and-config-file apps accumulate the obvious way: the same bearer token, copied into a plain text file on every laptop that needs it. Five apps like that across fifteen laptops isn't fifteen files — it's a matrix, and every cell is a credential nothing is watching.

The OAuth apps are better in one real sense: nobody's sharing a token, everyone authorizes as themselves. But someone still has to make that possible in the first place. A few services support Dynamic Client Registration, where the AI client can register itself and a person just clicks "Authorize" — genuinely no setup. Most of the everyday SME apps don't support it yet, though, which means before anyone can click anything, someone has to go into that vendor's developer portal, register an OAuth application, and hand-configure a client ID, a client secret, and a list of scopes. That's real, unfamiliar work, and unlike the token sprawl, it doesn't scale with headcount — it scales with the number of apps. Every new app the team connects is another one-time setup task that only one person knows how to do.

Nobody sat down and designed either pattern. They're just what happens, once per app for the OAuth apps, once per app per laptop for the token apps, until both piles are real.

The questions you can't answer

Once both patterns exist, some ordinary questions stop having answers:

• Which of these tokens still work? For the bearer-token apps, nobody's sure if three people are sharing one token or holding three separate ones.
• Which tools even got called? Most of these setups can't say which MCP tools were invoked last week, on which app, by whom — not the data behind them, just the fact that something ran — without asking each person directly.
• Which apps did we ever wire up OAuth for, and how? The OAuth app's own admin panel will happily show connected users once you're looking at it — the problem is remembering which of the team's apps have one, and where the client ID and secret for each one are even stored.
• Who set this up, again? One developer has all of it — which apps use tokens, which use OAuth, which laptops have Node.js — in their head. If they're out sick, the next hire's setup depends on someone reconstructing it from scratch.

Onboarding is fine. Offboarding is the problem.

Adding a new person is a known quantity: hand them the bearer-token apps' config, point them at the OAuth apps' login button, maybe walk through the Node.js install once. It's the reverse that has no playbook.

When someone leaves, "cut their access" isn't one action, it's two kinds of cleanup in different places: rotate the Xero token they had, and log into HubSpot's admin settings, and Zoho's, to find and revoke their individual grant — a different console for each one. Both chores land on the same one person, and neither shows up on a checklist because nobody wrote the checklist.

Multiply that by however many people cycle through a growing team over a year, and the setup that took ten minutes six weeks ago is now a standing chore with no owner.

Why this doesn't show up on anyone's radar

This isn't a security incident. Nothing gets breached. That's exactly why it survives so long — there's no single moment that forces anyone to fix it. It's just a slow accumulation of plain text files, unrevoked OAuth grants, and one person's memory as the only record of how the team's AI tools are actually wired together.

The team that outgrows this fastest is the one that took AI seriously earliest — the same one now discovering that "one developer configures it by hand" was never a real system, just the thing that happened before anyone needed one.