You have an MCP server you want your agents to use. Maybe it’s a server from a vendor. Notion has one. Databricks runs a dedicated server for Vector Search. Render, Exa, and Clay all publish their own. Maybe your own team built one for an internal system. Either way, you want agents in production to perform useful actions.
The obvious move is to point your agent’s MCP client straight at the server’s endpoint. That works right up until production, where a few questions consistently come up.
- Who authenticated to that server, and as whom? When your agent serves multiple users of its own, it needs to keep each user’s auth, to each server, separate and private.
- If you want to connect your agent to 10 or 25 or 50 MCP servers, does the agent code need to handle each one of those connections separately? Are all of those separate connections from your agent backend to each server?
- When an auditor asks what an agent did on behalf of a specific person, where is that record?
There’s a better path.
Whether a vendor hosts it, a partner ships it, or your own team runs it, you can register that remote MCP server with Arcade.dev and govern its tools from one control plane, right beside the tools Arcade builds.
Bringing your own third-party server to Arcade has been possible for a while, and it reflects our core belief in avoiding vendor lock-in. Your agents should not be boxed into one company’s tools, one model, or one client. We build a lot of high-quality tools, and we are just as glad to run the ones you bring.
But we’ve come to realize we’ve done a poor job of letting people know that we welcome third-party servers. So let’s fix that.
What registering the server changes
Arcade treats a remote MCP server you add as a first-class source of tools, right alongside the ones Arcade builds. You register the server once, at either the project level or the organization level, and its tools become available across every gateway, the Arcade Playground, and the SDKs in that project or org.
In the Servers dashboard you choose Add Server, select Remote MCP, and give it an ID and the URI where it is reachable. Arcade connects, discovers the server’s tools, and lists them in your catalog.
From there you create or edit an MCP gateway, filter to your server, and pick the tools you want to expose while hiding the rest. Your own agent reaches that one gateway through the Arcade SDK, and any off-the-shelf MCP client your team runs, like Claude, Cursor, or Copilot, can point at the same gateway. Either way, the third-party server’s tools show up as if they had always been part of Arcade.
The detail that makes this more than a passthrough is how authentication works.
Every user authenticates as themselves
When you register the server, you authenticate once as an admin. That login exists solely to let Arcade discover the full tool catalog so you can curate it. Authorize as an admin with the broadest tool access, because discovery only sees the tools your account can reach.
At runtime, every end user authenticates individually. The first time a user’s agent calls a tool on that server, Arcade runs the MCP server’s authorization flow against the remote server for that specific person and stores their token separately. That way a shared admin credential never becomes the way 200 people all act as one account. Each person acts as themselves, and each action carries their identity. It is the same authorization model Arcade enforces on its native tools, now extended to a server you did not build.
That is the primary benefit of bringing the server inside. You keep the vendor’s tools and you gain Arcade’s enforcement, governance, and audit on top.
What to know before you start
A few practical constraints to keep in mind. The remote server needs to speak the Streamable HTTP transport and be reachable from Arcade, since a server that goes offline will fail gateway and SDK calls until it comes back. Arcade supports the server’s tools today, but prompts, resources, and sampling are not supported yet.
Calling a remote tool from an SDK looks like calling any other tool. You reference it by server ID and tool name together, for example render-mcp-server.get_key_value, and pass the user you are acting for.
One gateway for the tools you build and the tools you bring
The ecosystem is filling up with MCP servers, and more arrive every week from vendors, partners, and internal teams. You should not have to choose between using them and governing them. Registering a remote server in Arcade means one gateway covers both the tools Arcade builds and the tools you bring, one authorization model applies to every action, and one control plane shows you what is running.
If you already have a server in mind, the setup is simple. Just log in to your Arcade account, click Servers on the left panel, and you’ll be up and running (safely) in minutes.
