Skip to main content

Multiple Accounts, One MCP URL

· 7 min read
MCPBundles

This is one of the most requested things we've shipped in a while: attach more than one account for the same service to a single MCP server. It's live. Same URL in Cursor or Claude. Every account you attach. Your AI routes each call to the right one.

If you've ever maintained three QuickBooks companies, two Shopify stores, or a work inbox and a personal one, you know the old pattern: duplicate the MCP server, duplicate the URL, duplicate the mental overhead. That ends here.

Why we built this​

The feedback was blunt and consistent. Bookkeepers said they were tired of swapping MCP entries between client companies. Agency folks wanted one "finance" server that could see every Stripe or QBO account they manage. Store owners with a second brand didn't want a second integration just to ask a question about the other shop.

The product already let you save multiple connections per provider in your workspace. What was missing was the obvious next step: attach several of them to the same MCP server and teach the model how to pick.

That's what this release is. Not a workaround. Not "clone your bundle five times." One server, one URL, N accounts — with the platform wiring the disambiguation so your prompts stay human ("for Acme's books…") instead of architectural ("switch to server 4…").

What changes for you day to day​

Before: one attached account per provider on a server, or multiple servers if you needed multiple accounts.

Now: open Connection on any MCP server, use Accounts on this server, and attach as many saved connections as you need. Name them when you connect. Keep one MCP URL in your client.

When you talk to your assistant:

  • Name the client, company, store, or mailbox in plain language.
  • Ask it to list what's attached if you're unsure.
  • Run multi-step work across accounts in one thread — overdue invoices for client A, then client B, then a summary — without touching MCP settings.

Remove from server only detaches from that MCP server. Your saved connection stays in the workspace for reuse elsewhere.

How to set it up (two minutes)​

  1. Open the MCP server you already use — QuickBooks, Gmail, Stripe, Etsy, whatever.
  2. Scroll to Connection → Accounts on this server.
  3. Attach a connection you've already saved, or Connect a different account to sign in or add a key.
  4. Repeat for the second, third, or Nth account.
  5. Leave your MCP URL alone in Cursor, Claude, or your other client.

That's it. No new URL. No re-import of tools unless your client caches aggressively (in which case a refresh of MCP tools is enough).

Under the hood: dynamic, not duplicated servers​

We didn't solve multi-account by minting a new MCP endpoint per company. The same bundle URL stays canonical. When you attach a second account, MCPBundles updates what your client sees — schemas, tools, and instructions — so the model can't silently guess wrong.

On the wire (tools/list and tool calls)​

When any provider on that server has more than one attached account:

  1. mcpbundles_list_connections — a bundle-level tool listing every attached account (id, label, provider, verification status). Use it when you or the model need to see what's in scope on this server.
  2. mcpbundles_connection on provider tools — for tools whose provider has two or more attachments, the input schema gains a required mcpbundles_connection field (your connection label or credential id). The platform strips that field before the upstream API runs and routes the call to the right saved connection.

With one account attached for a provider, those extras don't appear — behavior matches what you had before.

In the skill (MCP initialize and get_skill)​

Static catalog skills still describe how to use each integration. When you attach multiple accounts, MCPBundles appends a runtime supplement to that skill:

  • On MCP connect (initialize), the server instructions your client receives include the multi-account section — which accounts are attached, and how to use mcpbundles_list_connections plus mcpbundles_connection.
  • On get_skill, the same supplement is merged in, so refreshes and hosts that pull skills explicitly get the live account list.

You don't paste anything. Attach accounts in the UI; the next initialize or skill fetch carries the appendix. (Other runtime supplements — like Zotero scope mode or webhook-ingest setup — still merge the same way when they apply.)

For example: QuickBooks​

Bookkeepers and agencies pushed hardest here — several QuickBooks Online companies on one server:

See what's on the server

"Which QuickBooks companies are connected on this MCP server?"

→ The assistant lists the companies you attached, so you both agree on which books are in play.

Two clients in one session

"For Acme Consulting's QuickBooks, list invoices more than 45 days overdue. Then do the same for Bright Labs."

→ Two passes on the same URL, each one aimed at the right company. No tab switching, no second server.

Month-end without the URL hopping

"Pull this month's Profit and Loss for Acme Consulting and for Bright Labs. Flag any line that moved more than 25% from last month."

→ Both reports in one thread, with the big movers called out for each company.

Cross-check before you send

"Compare total AR on Acme vs Bright Labs and tell me which client has more overdue over 60 days."

→ One conversation, two ledgers, zero MCP reconfiguration.

Month-end used to mean a lot of switching between servers. Now it can be one conversation — and the platform keeps the routing honest even when you're moving fast.

Same idea, other stacks​

QuickBooks is the poster child, but the mechanism is provider-agnostic:

  • Stripe — separate connected accounts for different clients or products on one "payments" server.
  • Gmail / Microsoft mail — work and shared inboxes where you're allowed to attach both.
  • Etsy / Shopify — two shops, one URL, named connections per store.
  • Any API provider on MCPBundles where you legitimately have multiple saved connections.

If the service is on your server and you've attached more than one account for it, the list tool, connection parameter, and skill supplement show up together.

Want one URL per client instead?​

Sometimes you want a URL that only ever talks to one client. That's what dedicated servers are for: their own MCP server, name, URL, and attachments. They don't inherit accounts from the parent server — only what you attach to them.

Both models are first-class:

  • One server, many accounts — great when your mental model is "my finance stack" or "all my client books."
  • Dedicated server per client — great when you share a URL with a client or want hard isolation.

The accounts and dedicated servers section of our docs walks through the tradeoffs.

Get started​

Open your server, attach the accounts you need, then talk to your AI like you always do — just name which account when you have more than one.

Step-by-step: setting up credentials, especially managing multiple credentials.

If your setup doesn't fit any of this, I want to hear about it. This is the kind of feature we ship because people use the product hard and tell us exactly where the friction is — and this one was at the top of the list for a reason.