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.

If your company uses AI tools seriously, someone — probably a developer who never asked for the job — is now responsible for how the whole team connects its AI tools to the outside world.

That person deals with three problems every week:

API keys pasted into random config files on a dozen laptops. No way to see what the team's AI tools are actually touching. And every new hire means another afternoon walking someone through MCP setup by hand.

The tools built to solve this are built for enterprises: gateways you deploy on Kubernetes, platforms that assume an identity provider, products whose pricing page is a "Talk to sales" button. If you're a 20-person company, you're not the customer — you're just told to become one.

What Bloque does​

Bloque is a hosted MCP gateway. One admin sets up the servers; everyone else just points their MCP client at one endpoint. Behind that endpoint:

Approved servers, shared by the team. You pick which MCP servers your company uses. Everyone gets them — nobody configures anything locally.

Credentials stored once, encrypted. Connect your GitHub org, your Slack workspace, your shared database once. Keys never live in anyone's local config again.

A key per member. Someone leaves? Revoke their key. Nothing else changes.

Who-called-what logs. Not enterprise audit machinery — just an answer to "what did our AI touch today?"

Plus a playground for testing servers and debug logs for when things break.

Where Bloque comes from​

Bloque started as a fork of the open-source Plugged.in, an AI content platform with MCP management as one of its features. We wanted only that one feature — so we kept the MCP server management core, removed everything else, and rebuilt it as a hosted, multi-tenant gateway: one router, isolated runners, per-member keys, team billing. The fork is a statement of focus, not a shortcut — and credit to the Plugged.in team for the foundation. If you'd rather self-host a broader platform, their project is worth your time.

What the beta is (and isn't)​

We're launching as a paid public beta. Beta means we're honest about scope: shared servers currently use a shared upstream identity — per-member keys and logs live on Bloque's side. That makes today's Bloque great for team resources (GitHub org, shared Slack connection, shared DB) and not yet the right tool for personal accounts.

The GA release, roughly 8 weeks out, ships per-user OAuth: every member acts as themselves in every tool. In the enterprise-gateway world, getting there means plans that start around $499/mo for 10 users. On Bloque, the same 10-person team pays $101/mo at GA — $85/mo locked for a year if you join during the beta. A price a small team can expense without asking anyone.

Beta customers lock in beta pricing for 12 months — Team at $29/mo + $7/seat (seats rise to $9 at GA). There's a free tier if you just want to try the playground.

Start free → · See pricing →