One endpoint holds every MCP server and account you use, and picks the correct one for whatever project you're in.
Pick a project, then make a call. The resolution below is the same order the gateway runs: explicit override first, then project config, then git remote, then your active profile.
Production writes get held for confirmation instead of guessed. Try supabase.execute_sql from the work project.
Every AI client keeps its own list of servers, and every second account means another round of config edits. Distributor holds all of it in one place.
A small file in your repo, or just its git remote, decides the profile. The same tool call lands on the right workspace in every project.
Setup is minutes. After that your tools just call, and the right account answers.
Run dstb connect with a server URL and sign in through your browser. Do it again for the second account, and both stay.
Name a profile for each context, like work or personal, and map providers to the accounts that context should use.
Add the one endpoint to Claude, Cursor, Codex, or anything else that speaks MCP. Changes happen in Distributor from then on.
Anything with an MCP URL connects. These are the usual suspects.
The questions people ask before adding it.
One entry: the Distributor endpoint, or a local command if you'd rather stay on your machine. That's the last time you touch those configs. Servers and accounts get managed in one place afterward.
Each workspace is its own connection with its own name. Profiles map a project to the accounts it should use, so inside a repo the same tool call lands on the right workspace without renaming anything. You can always override by hand.
Connections carry an environment tag. When it can't tell which account you meant and one of the options is production, it stops and asks instead of guessing. Writes against production can also require a confirmation before they run.
A documented API or a published dataset, like an hourly CSV export. Distributor reads what the owner intended to share and exposes it as read-only tools. It doesn't scrape webpages and it can't write to a wrapped source.
It runs hosted or fully local. The CLI serves the same catalog over stdio, so a host that launches local servers works the same way as one pointing at a URL.
Your connections, your tool list, and an audit trail of calls: which tool, which account, why, how long it took. Tool results pass through to your client and are not kept.