Until now, Arcade.dev has been a product for admins. A platform operator configures an MCP gateway, picks the tools, sets up authorization, and hands that gateway to employees inside Claude, Cursor, or whichever client they use. From the employee’s side, the gateway is a black box. They can’t see which tools they have, which ones need a login, or how to ask for the one that’s missing.
The need was obvious from the first day I joined Arcade after it acquired Smithery. I remember early on when even our CEO, Alex Salazar, had to ask in Slack whether our gateway included Granola. The fact that he had to ask, and couldn’t just look, is the problem the Private Registry solves.
The same gap opens for customers the moment a pilot grows. Many of our enterprise customers start with a small group of users, then quickly scale toward hundreds. At that size, nobody can walk each new employee through which tools exist, which need a login, and who to ask for more. Employees need to see it for themselves.
The Private Registry is the first thing we’ve built for the people using agents rather than the people configuring them. It’s live now on Arcade gateways, with no feature flag and nothing to turn on.
Your gateway URL is now a web page
Paste your MCP gateway URL into a browser and you get a web app that asks you to sign in the same way Claude or Cursor would, through whatever authentication your platform operator attached to the gateway.
Once you’re in, you see every tool in the gateway grouped by app, with search across all of them. Each app shows how many of its tools you’ve connected. You can authorize all of Gmail in one click, or connect a single tool that asks only for the access it needs. You can also open any tool and run it from the browser to see exactly what it returns before you ask an agent to use it.
MCP inspectors already exist, but they’re built for developers debugging servers. The Private Registry is built for someone in marketing or finance who wants to know what their agent can do for them today.
The entire backend is MCP
We usually take human experiences and reshape them for agents. This time we took something only agents used, an MCP gateway, and opened it up to the people those agents work for.
The Registry has no backend of its own. Most software starts as a web app and later adds an API so machines can use it. Arcade has always worked in the other direction, starting from programmatic access for agents and avoiding a UI wherever we could. The Registry takes that to its conclusion.
When you open the page, your browser becomes an MCP client. Signing in runs the standard MCP authorization flow and gives the browser a short-lived access token. Listing tools, running a tool, submitting a request, and supporting a colleague’s request are all MCP tool calls against the gateway. We didn’t build an end-user API because we didn’t need one.
That design means anything you can do in the browser, your agent can do in chat. Ask Claude whether you have access to Granola and, if the answer is no, ask it to request access for you. The agent calls the same tools the web page calls, so you never have to open a browser at all.
It also means the Registry doesn’t hold on to your credentials. Tokens live only in the browser session and aren’t persisted, so you sign in each time you visit. For a page most people open to answer a quick question, that’s the right tradeoff, and it lets header auth and OAuth work the same way on any gateway.
Employees ask for what’s missing in plain language
If the tool you need isn’t there, you ask for it however you’d naturally describe it. “I want to list my Granola meetings” works. So does “Cloudflare” or a server URL.
Before you submit, the Registry shows similar requests from colleagues on the same gateway, so you can support an existing one instead of filing a duplicate.
You can track your own requests and see when one is resolved, along with a note from your platform operator.
For platform operators, this replaces a trickle of emails and Slack DMs. Requests from every gateway in a project arrive in a single inbox, ranked by how many people support them, so the Cloudflare request with five supporters rises above the one-off.
Resolving a request never changes a gateway on its own. Enablement stays a deliberate step that operators take through the controls they already use.
Peers don’t see who made a request by default, and Arcade records who acted on each one, when, and on which gateway.
Getting started takes one link
If you run an Arcade gateway, open its URL in a browser, then share that same URL with your team. Employees sign in with the identity they already use for the gateway in their agent, and they see the tools that gateway exposes to them.
This first release is scoped to a single gateway. Next, we’re extending the Registry so employees can see what their broader organization offers and request access to it, and adding baseline auth and MCP spec checks so operators can screen remote servers before rolling them out across the company.
Ultimately, an agent rollout only pays off when the people using it know what their agents can do. The Private Registry gives every employee on an Arcade gateway a way to find out for themselves, and it gives platform operators a ranked record of what their teams want next.
The next time someone wonders whether your gateway includes Granola, they can open a link and check, or ask their agent to check for them.
