On Page Navigation
On Page Navigation
Updated August 19, 2026
MCP Router is a gateway that sits in front of your MCP servers. Instead of every person connecting to every server separately, everyone connects once to the router, and the router decides which tools each of them can reach.
It is hosted, so there is nothing for you to run, patch or monitor. Provider credentials are held server side and are never handed to the people using the tools, which is the difference between granting somebody access and giving somebody a key.
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 connection. One person, one client, one server, one credential pasted into a config file on their machine.
That works until there are two of anything. Four people and four servers is sixteen configurations, sixteen places a secret has been pasted, and sixteen things to update when a key rotates. Nobody set out to build that. It accumulates one connector at a time, and by the time it is a problem, nobody can say with confidence who can reach what.
A gateway collapses that back to one connection per person, with access decided centrally. The arithmetic stops being multiplication.
It is worth being precise about what moves and what does not. The connectors themselves are unchanged. A site running the WordPress MCP Connector is still a site running that plugin, and an instance running the Frappe MCP Connector is unchanged too. What moves is where the credential lives and who decides what is reachable.
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 everything they are entitled to appears.
Local and remote providers sit side by side. A connector running inside your own instance and a connector reachable over HTTPS somewhere else both attach the same way, and the assistant sees one list without caring where any of it lives.
Tools stay namespaced. Every 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. Anyone who has attached three servers and watched an ambiguous tool list appear will recognise why this is listed as a feature rather than assumed.
Live connection reporting tells you what is actually up. Ask the router and it answers with the client identity it sees, every active integration along with its address, and the total number of tools currently exposed to you. That sounds mundane until a provider is quietly down and the assistant behaves as though the data does not exist, which reads as a wrong answer rather than an outage.
This is the capability that does not exist without a gateway, and it is the reason most teams end up needing one.
Without it, access is all or nothing. Handing somebody a credential to a system gives them everything that credential can do, including the destructive parts, because the connector does not distinguish. With per tool grants you give one person the read tools and another the write tools on the same provider, and neither of them holds a secret at any point.
You can grant by provider when the whole system is fine for somebody, or by individual tool when it is not. Two people can point at the same gateway and see completely different tool lists, without either of them configuring anything and without either one knowing the other list exists.
Named client identity means activity through the router is attributable to a named individual rather than to one shared anonymous key. That is the difference between knowing something happened and knowing who did it, and it is why we treat this as part of how we handle access to your systems rather than as a convenience feature.
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 were holding it in the first place.
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 that is publicly reachable still rejects anything that did not arrive through the gateway. That matters most for connectors sitting on a public domain, which is most of them.
Provider addresses, credentials and settings all live in one place, rather than being copied into every assistant that needs them and drifting apart over the following year.
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.
That last one is worth sitting with. If revoking access means asking somebody to delete a line from a config file on their laptop, you have not revoked anything. You have made a request. Central revocation is the difference between a policy you can state and a policy you can enforce, and it is usually the first thing anybody asks about when managed AI work touches a system that matters.
Six people who all need the same four systems. Without a gateway that is twenty four separate setups and twenty four places a key has been pasted, and a new hire spends their first morning on configuration instead of work.
With one, the new hire connects to a single endpoint and is granted what their role needs. When they change roles, you change the grant rather than walking them through reconfiguring anything.
The pricing follows the same shape, which is worth knowing before you plan around it. Billing is per user rather than per connector, so attaching a tenth provider costs exactly what attaching a second one did. Adding a seventh person is the thing that changes the number.
It helps to see the shape with real numbers, so here is a small one.
Five people. An ERPNext instance, a WordPress site, a support inbox and an internal database. Wired directly, that is twenty configurations, and in practice it is never actually twenty, because two people never got around to the database and one of them is still holding a key that was rotated in March.
Through the gateway it is four provider attachments and five grants. The finance lead gets the ERPNext connector whole, because everything in it is her job anyway. The two support staff get read tools on ERPNext plus the whole support inbox connector, so they can look an order up without being able to change one. 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 genuinely gone, rather than surviving on a laptop that went home with them. When the database credential rotates, it is edited once and the developer never notices.
Two things about that arrangement are worth noticing. The first is that none of those permissions is unusual. Every one of them is what you would have written down if somebody had asked you in advance. The difficulty with direct connections was never deciding the policy, it was that there was nowhere to put it. The second is that the whole arrangement survives a change of staff without anybody rebuilding anything, which is the property that stops it quietly decaying six months later.
The setup itself 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 gateway is what makes the answer enforceable afterwards.
Different staff on different accounts, and access that has to end cleanly when an engagement does. This is the case where central revocation stops being a convenience and becomes an obligation, because you are holding access to somebody else's business.
It also makes offboarding a client something you can demonstrate rather than assert. If you deliver work under a white label arrangement, being able to show exactly who had access and when it ended is worth having before anyone asks.
The same reasoning holds under a reseller arrangement. Keep every client's connectors attached in one place, hand each person only the ones they actually work on, and nobody carries credentials for accounts they have no business reaching. Moving somebody onto a new client becomes a permission change rather than a setup job.
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 and on several machines.
If those servers include ours, the router is where they belong. The WordPress MCP Connector and the Frappe MCP Connector both attach as providers, and neither needs anything done to it first beyond existing.
The Frappe case is the one that surprises people. An ERPNext instance holds finance, stock and customer records in one place, and its connector reaches all of them. That is exactly the provider you want granted tool by tool rather than handed over whole, and it is usually the strongest single argument for a gateway if you have been putting the decision off.
Somebody in your business has to be able to answer who can reach the billing system. If the honest answer is that it depends what is 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 category of tool that most access policies have not caught up with yet.
Reviewing the grant list is the part people skip. Grants accumulate, because widening one is a small favour and narrowing one is a conversation. Read the list once a quarter and you will usually find at least one person who kept something after a role change that nobody meant them to keep.
Once assistants are doing work rather than answering questions, scoping matters more, not less. 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 the work in business process automation, and keeping it correct as systems change is what automation maintenance covers. The router is the enforcement point for both.
There is a practical benefit as well. An automation that connects through the gateway holds no credentials of its own, so decommissioning it later is a grant removal rather than a search for wherever the key ended up.
An account, which is free for one user, 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 it did not have. It holds and scopes access you already hold. If a connector is failing when you point a client straight at it, attaching it to a gateway will not fix that, and diagnosing it there 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 is what turns that from an intention into a boundary.
And you need somebody willing to own the grant list. This is the prerequisite with no technical component and it matters most. A gateway with one administrator who reviews access is a control. A gateway where everybody can grant everything is a tidier version of the problem you started with.
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 later. Attaching a provider is done once, centrally, with the credential entered on the server rather than distributed.
The order that goes wrong least often is this. Attach one provider. Grant yourself one read tool from it. 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.
Start narrower than feels comfortable. It is easy to widen a grant when somebody asks and awkward to narrow one after they have been using it for a month.
A useful default is that read tools go to anyone whose job touches the system, and write tools go to the smaller group who are accountable for what is in it. Grant by provider where the whole system is genuinely fine for that person, and drop to individual tools where it is not, rather than granting a whole provider because picking tools felt tedious.
Watch the destructive tools specifically. Most connectors expose a handful that delete or overwrite, and those deserve to be granted by name to named people rather than arriving quietly inside a provider wide grant that nobody read to the bottom of.
Two habits are worth building. Read the connection report occasionally rather than 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 accumulation happens.
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 the provider it belongs to. Third, is the underlying credential still valid, which is the case that 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 is coming from the system downstream and the answer lives in that system's own permissions. The WordPress connector documentation and the Frappe connector documentation both set out that last layer for our own providers.
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 is not a substitute for 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 whole point of it being managed, and that is a trade worth making deliberately rather than by default. If the gateway itself has to sit inside your own perimeter, this is not that product. The individual connectors are free and open source and you can run those yourself.
And it is not an approval workflow. Nothing queues a tool call for a human to authorise. 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, that has to be designed into the process rather than expected from the gateway.
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. Adding a gateway to that is overhead with no return.
A gateway earns its place 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 are working inside somebody else's systems.
If none of those apply yet, come back when one of them does. It is a straightforward move at that point and nothing is wasted by waiting.
The full capability list and the pricing are on the MCP Router product page.
If the point of all this is automation rather than exploration, we design the processes too, and the scoping conversation is usually the more useful half of that engagement.
And once several providers are attached and several people are granted, keeping the grant list honest as systems change is what automation maintenance is for.