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.

【新製品】情シス部門のない中小企業向けMCPゲートウェイ「Bloque」β版を提供開始—MCPサーバーの設定・認証情報・実行環境・利用ログを一元管理 | 株式会社もばらぶのプレスリリース

情シス部門がない中小企業での AI 活用の実態​

AI を活用している中小企業の場合、AI に詳しい人・興味のある人が経営層から旗振り役を任されることがよくあると思いますが、その人がチーム全体の AI ツールを外部と接続する仕組みの責任者になっているはずです。

その人は、次のような問題に直面しています。

• API キーが、チームメンバー十数台のノート PC の設定ファイルに散らばっている
• チームの AI ツールが実際に何に触れているのか、把握する手段がない
• 新しい人が入るたびに、MCP のセットアップを教えたり自分自身で設定したりして、時間が取られる

こうした問題を解決するために作られたツールは沢山ありますが、どれも大企業向けです。

• Kubernetes 上にデプロイするゲートウェイ
• ID プロバイダーの存在を前提としたプラットフォーム
• 料金ページが「営業に問い合わせる」ボタンだけの製品

20人規模の会社であれば、あなたは「顧客」ではありません。

Bloque がすること​

Bloque は、ホスト型の MCP ゲートウェイです。管理者一人が MCP サーバーをセットアップすれば、あとは全員が一つのエンドポイントに MCP クライアントを向けるだけです。そのエンドポイントの裏側では以下のような事が出来ます。

• 承認済みサーバーをチームで共有
  • 自社で使う MCP サーバーを選べば、全員がそれを利用できます。ローカルで何かを設定する必要はありません。
• 認証情報は一度だけ、暗号化して保存
  • GitHub 組織、Slack ワークスペース、共有データベースを一度接続すれば、キーが誰かのローカル設定に残ることはありません。
• メンバーごとのキー
  • 誰かが退職したらそのキーを無効化するだけです。他は何も変わりません。
• 「誰が何を呼び出したか」のログ
  • エンタープライズ向けの大がかりな監査機構ではなく、「今日、うちのAIは何に触れたのか」という問いに答えられる程度のもの。

それ以外に、サーバーをテストするためのプレイグラウンドと、不具合発生時のデバッグログも用意しています。

Bloque の生い立ち​

Bloqueは、オープンソースの Plugged.in のフォークとして始まりました。

Plugged.in は MCP 管理機能を持つ AI コンテンツプラットフォームですが、必要なのは MCP 関連機能だけでした。そこで MCP サーバー管理のコア部分だけを残し、それ以外はすべて取り除いた上で、ホスト型・マルチテナントのゲートウェイとして作り直しました。1つのルーター、テナント毎の分離された実行環境、チーム単位の課金という形です。

今回のベータ版でできること・できないこと​

今回は有料の公開ベータとしてローンチします。 ベータですので、対応範囲・制限事項について少し記載します。

基本的には全ての機能は動作します。

現状、設定された MCP サーバーは共有の（MCP サーバーを設定した管理者の）アップストリーム認証情報を使用し、メンバーごとのキーやログは Bloque 側で管理されています。例えば Slack MCP サーバーを使う場合、どのユーザーがどのツールを使ったかのログは Bloque 側に残りますが、Slack MCP 経由で Slack に投稿すると、Slack 上では管理者が投稿をする形になります。そのため、現在の Bloque はチーム共有リソース(共有DBなど)には非常に適していますが、個人アカウント用としてはまだ最適なツールとは言えません。

正式リリース(GA、おおよそ8週間後)では、ユーザーごとの OAuth に対応する予定です。各メンバーが、それぞれのツールで「自分自身として」操作できるようになります。

エンタープライズ向けゲートウェイの世界でこれを実現しようとすると、10ユーザーで月額499ドル前後からのプランが必要になります。一方 Bloque なら、同じ10人チームでもGA時点で月額101ドル、ベータ期間中に登録すれば1年間は月額85ドルです。役員にお伺いを立てることもなく経費申請できる価格かと思います。

ベータのお客様は、12か月間ベータ価格が固定されます。Teamプランは月額29ドル+シートあたり7ドル(GA後はシートあたり9ドル)。基本機能を試すだけであれば、無料プランもご用意しています。

始める → · 価格を見る →