MCP Router

What the Router Does

MCP Router is a gateway that sits in front of your MCP servers. Everyone connects once, to the router, and the router decides which tools each person can reach.

It is hosted, so there is nothing for you to run, patch, or monitor. Provider credentials stay on the server and are never handed to the people using the tools. That is the difference between granting somebody access and giving somebody a key.

The Problem It Solves

MCP connects an assistant to a real system: a CRM, a site, a database, a ticket queue. On its own that is a point to point link. One person, one client, one server, and one credential pasted into a config file on their machine.

Add a second person and a second server and the pairings multiply. Four people and four servers make sixteen configurations, sixteen places a secret has been pasted, and sixteen edits when a key rotates. Nobody plans that. It builds up one connector at a time, and by the time it hurts, nobody can say with confidence who can reach what.

A gateway brings it back to one connection per person, with access decided centrally. The connectors themselves do not change. What moves is where the credential lives and who decides what is reachable.

One Endpoint, Every Connector

Attach as many connectors as you need and they all arrive through a single connection. There is no cap on the number. A person points their client at one endpoint and sees everything they are entitled to.

Local and remote providers sit side by side. A connector running inside your own instance and one reachable over HTTPS somewhere else attach the same way, and the assistant sees a single list without caring where any of it runs.

Tools stay namespaced. Each tool arrives tagged with the connector it came from, so two providers that both offer a tool called search do not collide, and nobody has to guess which system they are about to query.

Live connection reporting shows what is actually up. Ask the router and it answers with the client identity it sees, every active integration with its address, and the total number of tools currently exposed to you. Without it, a provider that is quietly down looks like an assistant giving a wrong answer, when the real fault is an outage.

Access per Person, per Tool

This is the capability that cannot exist without a gateway, and for most teams it is the reason to have one.

Without it, access is all or nothing. A credential to a system carries everything that credential can do, destructive parts included, because the connector draws no distinction. With per tool grants, one person gets the read tools and another gets the write tools on the same provider, and neither holds a secret.

You can grant a whole provider when the entire system is fine for somebody, or single tools when it is not. Two people can point at the same gateway and see different tool lists, with no configuration on either side and no way to tell the other list exists.

Named client identity means activity through the router is attributable to a named individual, not to one shared anonymous key. You learn who did something, not only that it happened. It is also why we treat this as part of how we protect provider credentials rather than as a convenience.

How the Credential Is Protected

Provider keys are held by the router and never copied into anybody’s assistant configuration. Rotating one is a single edit on the server, and every connected person keeps working because none of them held it.

Downstream connectors can be locked to the router. A token authenticated connector accepts traffic only when it carries the shared secret the router holds, so a connector on a public domain still rejects anything that did not come through the gateway. Most connectors do sit on a public domain, which is why this matters.

Provider addresses, credentials, and settings live in one place, not in every assistant that needs them, where they drift apart over the following year. Our privacy policy states that provider credentials supplied to the router are encrypted at rest and cannot be decrypted or retrieved in plaintext by us.

Changing Access Costs Nothing

Access changes take effect without anyone reconnecting or editing a file. Add a provider once and it appears for everyone entitled to it. Revoke in one place and it is gone everywhere, immediately.

Consider the alternative. If revoking access means asking somebody to delete a line from a config file on their laptop, you have made a request, not a revocation. Central revocation is what turns a policy you can state into one you can enforce, and it is usually the first thing people ask about when AI work touches a system that matters.

Where the Router Fits

A Team Sharing One Set of Tools

Take six people who all need the same four systems. Wired directly, that is twenty four separate setups and twenty four places a key has been pasted, and a new hire spends the first morning on configuration instead of work.

With a router, the new hire connects to one endpoint and is granted what the role needs. When they change roles, you change the grant. Nobody walks them through reconfiguring anything.

Billing follows the same shape. You pay per user, not per connector, so attaching a tenth provider costs exactly what attaching a second one did. Adding a seventh person is what changes the number.

A Worked Example, Five People and Four Providers

Here is a small one with real numbers. Five people, four providers. Wired directly, that is twenty configurations, and in practice it is never quite twenty, because two people never got around to the database and one of them still holds a key that was rotated in March.

Through the router it is four provider attachments and five grants. The marketing person gets the WordPress connector and nothing else. The developer gets the database read tools and, deliberately, not the write tools, because schema changes go through review rather than through an assistant.

Nobody on that list holds a credential. When the marketing person leaves in June, one grant is removed and the access is gone, instead of surviving on a laptop that went home with them. When the database credential rotates, it is edited once and the developer never notices.

None of those permissions is unusual. Each is what you would have written down if somebody had asked in advance. The difficulty with direct connections was never deciding the policy. It was that there was nowhere to put it. And because the arrangement survives a change of staff without anybody rebuilding anything, it does not quietly decay six months later.

The setup takes an afternoon, and most of that afternoon is the conversation about who should be able to write to what. That conversation is the real work. The router is what makes the answer enforceable afterward.

An Agency Working Across Client Systems

Different staff work on different accounts, and access has to end cleanly when an engagement does. Here central revocation stops being a convenience and becomes an obligation, because you are holding access to somebody else’s business.

It also lets you show offboarding rather than assert it. If you deliver work under a white label arrangement, a record of who had access and when it ended is worth having before anyone asks.

The same holds under a reseller arrangement. Keep every client’s connectors attached in one place, give each person only the ones they work on, and nobody carries credentials for accounts they have no business reaching. Moving somebody onto a new client becomes a permission change, not a setup job.

Anyone Running Several MCP Servers

Past about three servers, the tool list itself becomes the problem. Namespacing keeps it legible, and one connection means you stop maintaining the same list of endpoints in several clients on several machines.

Our own connectors are natural candidates. The WordPress MCP Connector can edit a live site, so it is exactly the kind of provider you want granted tool by tool rather than handed over whole. For many teams that is the strongest single argument for a gateway.

Whoever Is Accountable for Access

Somebody in your business has to be able to answer who can reach the billing system. If the honest answer depends on what is sitting in various config files, that is not an answer.

Per user and per tool grants, plus named client identity, turn that from a guess into a record. It is the same reason you would not run production database access through a shared login, applied to a newer kind of tool that most access policies have not caught up with.

Reviewing the grant list is the step people skip. Grants pile up, because widening one is a small favor and narrowing one is a conversation. Read the list once a quarter and you will usually find someone who kept access after a role change that nobody meant them to keep.

Automation That Runs Against Real Systems

Once assistants do work instead of answering questions, scoping matters more. A process that reads from three systems and writes to one should have exactly that access and nothing more.

Designing that scope is part of our business process automation work, and keeping it correct as systems change is part of automation maintenance. The router is the enforcement point for both.

There is a practical benefit too. An automation that connects through the router holds no credentials of its own, so decommissioning it later means removing a grant, not searching for wherever the key ended up.

What You Need, and When to Skip It

What You Need

An account and an MCP client that can hold a remote connector entry. That is the whole list. There is no package to install, no container to run, and no certificate to manage.

For each provider you attach, you need its address and a credential that already works. The router does not create access you did not have. It holds and scopes access you already hold. If a connector fails when you point a client straight at it, attaching it to the router will not fix that, and diagnosing it directly first will save you an hour.

If a connector runs on a public domain, decide before you attach it whether it should accept traffic from anywhere or only from the router. Token authentication turns that intention into a boundary.

You also need somebody willing to own the grant list. This prerequisite has no technical side and it matters most. A router with one administrator who reviews access is a control. A router where everybody can grant everything is a tidier version of the problem you started with.

Setting It Up

Three steps. Create your gateway. Attach the providers you want, local or remote. Grant people the tools they need.

Nothing is installed on anybody’s machine beyond pointing their client at one endpoint, and that endpoint does not change when you add or remove providers. You attach a provider once, centrally, with the credential entered on the server rather than distributed.

The order that goes wrong least often: attach one provider, grant yourself one read tool from it, and confirm the tool appears in your client and returns real data. Only then attach the rest. If the first one works, the pattern works, and everything after it is repetition rather than discovery.

How to Think About Granting

Start narrower than feels comfortable. Widening a grant when somebody asks is easy. Narrowing one after they have used it for a month is awkward.

A useful default: read tools go to anyone whose job touches the system, and write tools go to the smaller group accountable for what is in it. Grant by provider where the whole system is genuinely fine for that person. Drop to individual tools where it is not, instead of granting a whole provider because picking tools felt tedious.

Watch the destructive tools in particular. Most connectors expose a handful that delete or overwrite. Grant those by name to named people, so they do not arrive quietly inside a provider wide grant that nobody read to the bottom.

Operating It

Two habits pay off. Read the connection report now and then, not only when something is wrong, because a provider that has been down for a week produces confidently incomplete answers rather than errors. And review grants when people change roles, not only when they leave, since role changes are where quiet privilege builds up.

If a tool call fails, check in this order. First, is the provider connected at all? The connection report answers that in one question and rules out the most common cause. Second, has that person been granted that specific tool, rather than only the provider it belongs to? Third, is the underlying credential still valid? That case looks like a router fault and is not one.

Fourth, if the tool is present and the call is refused rather than absent, the refusal comes from the system downstream, and the answer lives in that system’s own permissions.

What It Is Not

It is not an MCP server. It exposes no tools of its own beyond the connection report. Everything you reach through it comes from a provider you attached, and if a system has no MCP server, the router cannot give it one.

It does not replace the permissions in the systems behind it. A grant decides what a person can call. What that call is then allowed to do is decided by the credential the provider holds, and a router grant cannot exceed it. Both layers matter, and neither replaces the other.

It is not self hosted. It runs on our infrastructure, which is the point of it being managed, and that is a trade worth making deliberately. If the gateway itself has to sit inside your own perimeter, this is not that product. You can still run connectors yourself and attach them: the WordPress MCP Connector, for one, is a free plugin you host on your own site.

And it is not an approval workflow. Nothing queues a tool call for a human to authorize. Access is decided in advance by the grant, and after that the assistant proceeds. If you need a person in the loop on every write, design that into the process, because the router will not supply it.

When You Do Not Need One

If you are one person with two MCP servers, you do not need this, and we would rather say so than sell it to you. Wiring two connectors by hand takes ten minutes, you are the only one holding the keys, and there is nobody to offboard. A gateway there is overhead with no return.

It starts to pay at one of three moments. When people multiplied by servers stops being a small number. When somebody other than you has to be able to answer who can reach what. Or when access has to end cleanly and provably, which usually means the first time you work inside somebody else’s systems.

If none of those apply yet, come back when one does. Adding a router later is a straightforward move, and nothing is wasted by waiting.

Where to Go Next

The full capability list and the questions people ask before signing up are on the MCP Router product page. If the point of all this is automation rather than exploration, the scoping conversation is usually the more useful half of that work.

Questions and Answers

How Is MCP Router Billed?

You pay per person, per month, for the people who actually use it. Connectors and assistants are unlimited, so adding another tool or another agent never changes the bill. Adding a person does.

How Many Connectors Can I Attach?

There is no limit. Every connector joins the same endpoint, and its tools appear alongside everything already connected, tagged with the connector they came from.

Can two people on one router see different tools?

Yes. Both connect to the same endpoint with the same steps, and each sees only the tools you granted. Their assistants show different lists without either person configuring anything differently.

Do I Need to Install or Host Anything?

No. You create a gateway, attach your providers, and point each person’s client at one endpoint. The connectors behind the router can be ones we host or ones you already run yourself.

Can I Use It with Claude Desktop?

Yes. Add the router as a connector in your client and it appears as one entry exposing every tool you have been granted. It works the same way in any MCP compatible client.

How Do I Remove Someone’s Access?

In one place. Everyone connects through the same endpoint instead of holding direct connections, so revoking a person is a single action, not a hunt through client configurations.

How Do I See What Is Connected?

Ask the router. It reports the client identity it sees, every active integration with its address, and the total number of tools currently exposed to you. Use it to confirm a new provider attached correctly.