Add MCP support without hosting servers

The plan for adding MCP support to an AI product usually starts from one assumption: your application server becomes the MCP client, so it also has to become the thing that builds, deploys, and keeps alive the MCP server sitting behind that client. Being the client and running the server are two separable jobs. Paragon ships ActionKit as a managed MCP server, listed on the official MCP registry, so your application server connects as the client to one endpoint that routes through ActionKit to 130+ maintained integrations and 750+ agent-ready actions. Managed multi-tenant auth, token refresh, retries, and monitoring all run on Paragon's side of that connection.

Teams that build MCP support in-house typically stand up the protocol layer, the per-provider auth, and the credential storage together, then maintain all three every time a provider changes its API. Paragon splits those concerns instead: you keep building the agent, while the MCP server, the auth, and the connector maintenance already run on Paragon's side of the connection.

What does adding MCP support yourself actually require?

Building MCP support in-house starts with standing up a server process that speaks the MCP protocol, before your agent can call a single tool. On top of that server, you need a registered OAuth app with every third-party API you want to expose, since most providers issue their own client ID and secret rather than a shared one. You also need somewhere to store each user's access and refresh tokens, a job that runs those refreshes on schedule, and isolation logic that keeps one customer's credentials from leaking into another customer's session in a multi-tenant product. Each new connector repeats that work: a new OAuth app, new token handling, and an ongoing commitment to update the integration when the provider changes its API or deprecates an endpoint. None of that is agent logic. It is infrastructure that has to exist before the agent can act, and it has to be rebuilt, roughly, once per integration, by whichever engineer on your team drew the short straw for that provider's docs.

How do you add MCP support without hosting your own server?

Paragon adds MCP support to your AI product by shipping ActionKit as a managed MCP server, listed on the official MCP registry, so you connect to it rather than building one. Your application server acts as the MCP client: it opens a connection to Paragon's server and passes a token identifying which of your users is making the call. Paragon resolves that token to the right connected-account credential and routes the request through ActionKit to whichever of the 130+ maintained integrations and 750+ agent-ready actions the call targets. Token refresh, retries, and request logging run on Paragon's side of that connection, not yours.

Wiring an agent framework directly to a single API skips this step, since there is only one account to authenticate against. Managed multi-tenant auth is the piece that usually takes longest to get right in-house, because it has to hold every user's credential separately, refresh each one on its own schedule, and fail safely when a provider revokes access. Paragon treats that as the default, not an add-on: your server passes a user identifier, Paragon looks up that user's connection, and the call proceeds with the right credential attached.

Is this the same as a self-hosted MCP server?

"Without hosting servers" describes what your team skips: deploying a server per integration, registering a per-provider OAuth app, running a token-refresh job, and writing multi-tenant isolation code. A server still exists somewhere in the request path; it runs on Paragon's infrastructure rather than yours, with MCP as the protocol that server speaks and Paragon as the platform resolving auth and maintaining connectors behind it. A developer who checks Paragon's public GitHub repo (useparagon/paragon-mcp) will find it documents a self-hosted deployment: the same MCP server, deployed in a container you run, configured with your own project ID and signing key. That repo is real and current, and it is the control-path option for teams that specifically want to run the protocol layer inside their own infrastructure, for example to satisfy a data-residency requirement, keep the connection inside an existing VPC, or add custom middleware in front of the MCP endpoint. Choosing it puts the container, the deploy pipeline, and the uptime of that one process back on your team, even though the auth and connector maintenance behind it still sit with Paragon. Paragon's managed MCP server is the default path Paragon offers; the self-hosted repo is the option for teams with that specific control requirement, not a replacement for it.

How does Paragon's MCP model compare to other vendors' MCP servers?

Paragon is the more direct fit for a product team adding MCP support to a multi-tenant AI product, because it resolves per-user auth from a single token your server already has, rather than requiring your server to track and forward a separate connection identifier on every call. Nango runs one hosted MCP endpoint (api.nango.dev/mcp) and resolves which tenant a call belongs to from a connection-id and provider-config-key header pair your server has to supply and keep mapped to the right customer on every request (current as of July 2026). MuleSoft's Agent Fabric takes a different approach again: its Agent Registry curates and lists MCP servers across agent platforms like Agentforce, Bedrock, and Copilot Studio, which is a discovery and governance layer for organizations that already have multiple agents and servers in place, not a single server a product embeds to add MCP support (current as of July 2026).