So we built a custom MCP server that calls our existing backend and deployed it on Arcade.dev Cloud. Customers sign in with their normal Zenith login (we already use Clerk as an IdP), without creating an Arcade account. Every tool call reaches our API with an OAuth token delegated by that user, and the API applies the same workspace and plan checks it always uses for standard web or mobile users. The model never handles a token, and it doesn’t get to claim it’s user_123.

This post builds the same setup from scratch: a Python MCP server, a small reporting app standing in for your backend, OAuth wired through Clerk and Arcade, deployed to Arcade Cloud and connected to Claude. The demo also covers the shape most real backends have: long-running jobs. The agent starts a report, polls with the job ID, and retrieves the result, with workspace membership and plan tier re-checked on every call. The part that took us longest to untangle, and the part this post spends the most time on, is that “signing in” here means three separate credentials.

Download the complete example. It includes the Python MCP server, the web app, configuration templates, and tests, runnable with your own Clerk and Arcade developer accounts.

MCP Server Architecture: Gateway, Tools, and Backend API

Calling our existing backend lets agent requests use the application's access rules. The MCP server exposes operations to the agent, while the API decides whether the user can perform them. Keeping those checks in the backend avoids maintaining another set of membership and subscription rules in the MCP server.

Arcade Cloud runs the Python MCP server. The gateway identifies the user, and Arcade supplies the API access token when an authorized tool runs. A separate web application handles the reporting API, background jobs, browser sign-in, and custom user verifier. Clerk supplies identity and OAuth services.

The download includes that web application so you can follow along without an existing backend. Its synthetic reports and permissions stand in for your application's operations and access rules.

The client calls MCP tools through the gateway. Those tools then make ordinary HTTPS requests to the reporting API. You'll run the demo web application locally behind an ngrok HTTPS tunnel so Arcade Cloud can reach it. If your API and browser verifier already run on deployed HTTPS URLs, use those directly. You don't need a tunnel.

Why Not Just Run the MCP Server Yourself?

Fair question, and nothing in MCP forces a gateway: the protocol supports OAuth-protected remote servers. Implement that spec from scratch, and you’re building everything between “the user clicked authorize” and “the right token arrives in the right tool call”:

• Running the authorization-code flow against Clerk, with PKCE and consent, for every customer who connects an agent

• Storing each user’s delegated token, refreshing it via offline_access, and keeping it away from the model and the MCP client

• Matching an incoming tool call to that caller’s token at execution time

• Signing customers in through your existing IdP, so they connect with the login they already have instead of a new account

• Binding tool authorization to a real browser session, so one user can’t complete another user’s flow

In this tutorial, Arcade handles that list. Your API keeps what should never leave your code: deciding what the authenticated user can actually do.

There’s also a middle path, and since we already use Clerk, it deserves a straight answer. Clerk can act as the authorization server for an MCP server directly: it supports dynamic client registration and a consent screen, so an MCP client registers itself with Clerk, completes the flow there, and presents a token that your self-hosted server verifies. Your code never touches authorization codes. That architecture is genuinely simpler: one credential instead of three, no gateway sign-in, and no browser verifier, because there is no second flow to bind. The trade-off is that you host and operate the server yourself, and Clerk’s MCP helper library targets JavaScript frameworks such as Next.js and Hono while our tools are Python. If you’re exposing one TypeScript server from an application you already run, Clerk-direct is a reasonable choice.

We wanted the gateway anyway, and not only for the token plumbing. A gateway is a surface you can grow: it can federate tools from multiple MCP servers behind the same URL, so we can add more servers later, or prebuilt integrations and newly launched tool recommendations from from Arcade’s catalog, without customers reconfiguring their connector. As that catalog grows, Tool Recommendation matches each task to the few tools the agent needs, so it doesn’t carry every definition in context. It’s also a control point: you select exactly which tools each gateway exposes, with contextual access policies on top, so the gateway also governs what agents can reach. Here, that’s just the four reporting tools.

One constraint worth knowing during development: tools that declare requires_auth or requires_secrets need a verified caller identity before they run, and the SDK’s default local HTTP mode has none, so it rejects those tools while an unprotected greeting works fine. Arcade’s transport guidance documents this. Local stdio supports protected tools with configured developer credentials, and the server can also run outside Arcade Cloud behind additional resource-server authentication. This tutorial stays on Arcade Cloud throughout.

How MCP Gateway Authentication and API OAuth Fit Together

A user connecting Claude needs to sign into the gateway and authorize tools to call the application API on their behalf. Their browser also has an application sign-in session managed by Clerk. These connections use separate credentials:

Customers don't need Arcade accounts for this setup. A User Source lets them sign into the gateway using their existing application login, with Clerk as the identity provider. They don't need to become Arcade project members. You still need an Arcade account to create and deploy the server. Arcade documents the distinction between administrators and gateway users.

A custom OAuth provider tells Arcade how to obtain the user's authorization for your API. When the tool runs, Arcade supplies that API access token.

A custom user verifier confirms that the person completing tool authorization matches the application user who began the flow. The verifier runs in your browser application, where it can read the Clerk session. You still need this step after configuring the gateway's User Source. Arcade's production-auth guide covers this verification boundary.

The API identifies the user by verifying the OAuth access token, then checks the application's membership and plan rules for that user. The API doesn't trust a caller simply claiming to be user_123.

1. Set Up the Python MCP Server

You need Python 3.11–3.13, uv, Node.js 22–24, and npm. Python 3.12 and Node.js 22 work well. You also need a Clerk development instance, a separate Arcade demo project, and an MCP client with remote connector support. Any client that supports the Streamable HTTP transport can use the gateway URL, including Cursor, Claude Code, Codex, and custom agents. The steps below use Claude Desktop.

Python runs the MCP tools. Node.js runs the included API, browser sign-in, and verifier. You don't need an existing backend to follow along. For the local demo, you'll also need an ngrok account and CLI. We'll set those up in step 3.

Extract the download. Its two application directories:

report-mcp-demo/
  mcp/       Python MCP tools to deploy on Arcade Cloud
  web/       Application sign-in, user verifier, and reporting API

From the MCP directory, install the pinned dependencies:

cd report-mcp-demo/mcp
uv sync --locked --extra dev

Start with hello.py to see how a tool registers:

from typing import Annotated

from arcade_mcp_server import MCPApp

app = MCPApp(name="hello_demo", version="1.0.0")


@app.tool
def greet(name: Annotated[str, "Name to include in the greeting."]) -> str:
    """Return a greeting to verify that a client can call this local tool."""
    return f"Hello, {name}!"


if __name__ == "__main__":
    app.run(transport="stdio")

MCPApp owns the server. The decorator registers the function as a tool. Its docstring tells the client what the tool does, and the parameter annotation describes the input. Arcade's server guide explains this interface.

Optional: Try the Local Greeting

From the same mcp/ directory, run the included greeting test. The test starts the server, connects an MCP client, and calls greet with the name Reader:

uv run pytest tests/test_stdio.py::test_hello_tool_over_stdio -q

The test checks that the tool returns Hello, Reader!. Its summary should show 1 passed. The greeting gets checked internally rather than printed.

Checkpoint: Your local MCP server registered a tool and answered a real MCP call. This check needs no Clerk or Arcade account configuration. Next, you'll set up authentication for the reporting tools. Customers will use the hosted gateway without running a local MCP process.

2. Create Test Users and OAuth Applications in Clerk

Signing into the gateway identifies the user connecting their agent. Calling the backend requires a separate grant to act on the user's behalf. You'll configure an OAuth application for each connection in the same Clerk instance, using the user's existing identity for both.

In the Clerk dashboard, create an application and select its development instance. Enable email/password sign-in, then create three test users for the demo application: Alice, Bob, and Carol. Copy their Clerk user IDs from the Users page.

Each workspace in the demo represents a separate customer organization. Alice and Bob belong to team-red, on the Pro tier. Carol belongs to team-blue, on Basic. Alice and Bob demonstrate colleagues sharing access within one customer workspace. Carol lets you test the boundary between customers.

Basic permits basic reports. Pro also permits advanced reports. These simplified plans demonstrate that an agent can only create reports the customer's subscription allows. The demo treats reports as workspace resources, so Bob can retrieve a report Alice created in their shared workspace. The names, memberships, and tiers are fixtures in the application code. You don't need to configure Clerk Organizations or billing.

Zenith also supports internal staff with access across customer workspaces. To try that optional case, create a fourth test user in the same Clerk instance and keep its ID for DEMO_STAFF_USER_ID. The demo grants that account access to both workspaces while retaining their tier restrictions.

Create two OAuth applications in that same Clerk instance under Configure → Developers → OAuth Applications → Add OAuth application. Give them distinct names and leave Public off so they remain confidential clients:

Save each application's client ID and client secret. Keep PKCE enabled. The API application requests offline_access for refresh access and retains its consent screen. For the first-party gateway identity application, Arcade's Clerk guide describes disabling Clerk's additional consent screen. That setting doesn't disable the gateway's own consent screen.

Open the OAuth application's Discovery URL and copy the issuer, authorization_endpoint, and token_endpoint. Both apps use the same Clerk instance, but their client credentials and callbacks differ. Use the exact issuer value, without the /.well-known/openid-configuration suffix or an added trailing slash. Clerk User Source setup and Clerk's OAuth implementation document these settings.

Also copy the development instance's publishable key and backend secret key from Clerk's API keys page. The backend secret key differs from either OAuth application's client secret.

3. Run the Demo Backend with Clerk Sign-In

The included Next.js application supplies the backend for this example: browser sign-in, user verification, and the reporting API. The verifier lives alongside sign-in so it can identify the person completing authorization from their Clerk browser session.

Arcade Cloud can't reach the API on your computer's localhost:3000. Ngrok gives that local application a public HTTPS address. The same address serves browser sign-in and /auth/verify because this demo bundles them with the API.

If you're adapting an existing application, use its deployed HTTPS API origin and host the verifier alongside browser sign-in. Those can be separate origins. You can skip ngrok once both reach HTTPS.

Install the companion dependencies:

cd ../web
npm ci
cp .env.example .env.local

Create an ngrok account and install the CLI using its setup guide. On macOS with Homebrew:

brew install ngrok

Copy your authtoken from the ngrok dashboard. In another terminal, connect the CLI to your account and forward port 3000:

ngrok config add-authtoken "YOUR_NGROK_AUTHTOKEN"
ngrok http 3000

Copy the HTTPS forwarding origin printed by ngrok and keep this terminal open. The origin will reach the application once you start it below. Use the plain tunnel command shown here. Clerk handles browser and API authentication, so an additional ngrok login policy would interrupt the tool's API calls.

Fill in web/.env.local:

APP_URL=https://YOUR-NGROK-DOMAIN
NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY=YOUR_CLERK_DEVELOPMENT_PUBLISHABLE_KEY
CLERK_SECRET_KEY=YOUR_CLERK_DEVELOPMENT_SECRET_KEY
ARCADE_API_KEY=YOUR_ARCADE_DEMO_PROJECT_API_KEY
REPORTS_OAUTH_CLIENT_ID=YOUR_REPORT_DEMO_API_CLIENT_ID
DEMO_ALICE_USER_ID=YOUR_ALICE_CLERK_USER_ID
DEMO_BOB_USER_ID=YOUR_BOB_CLERK_USER_ID
DEMO_CAROL_USER_ID=YOUR_CAROL_CLERK_USER_ID
DEMO_STAFF_USER_ID=

Replace the entire https://YOUR-NGROK-DOMAIN placeholder with your actual HTTPS forwarding origin, without a trailing slash, and fill in the other values. Set REPORTS_OAUTH_CLIENT_ID to the API application's client ID. The API checks this value so it can reject tokens issued for the gateway application. Leave the staff user empty until you test staff access.

Start the app:

npm run dev

Open APP_URL in your browser. If ngrok shows its free-plan warning page, click Visit, then sign in as Alice. This browser warning doesn't affect programmatic API requests.

Checkpoint: The homepage recognizes Alice. Browser sign-in works. You'll test the API's separate OAuth grant after connecting Claude.

Use that public origin for the remaining steps. The app reads its allowed development hostname and browser origin from APP_URL. Switching to localhost during authorization can leave you in a different browser session.

Keep the app and ngrok running while testing. Ngrok reuses your account's assigned development domain. If you switch domains, update APP_URL, the Arcade verifier URL, and the hosted API base URL, then restart the app. The MCP server deploys separately to Arcade Cloud in step 8.

4. Configure the API OAuth Provider in Arcade

The MCP tool needs permission to call your API on the user's behalf. Configure an OAuth provider so Arcade can obtain that user's API access token.

In your Arcade demo project, open Connections → OAuth providers, add a Custom Provider, and configure:

Retain the normal authorization-code and refresh grant parameters. When using Basic client authentication, avoid also adding client credentials to the request body. Arcade's OAuth-provider reference describes those request settings.

Copy the provider's generated Redirect URI into the allowed redirects for Report demo API in Clerk. Copy it exactly. This callback differs from the gateway's intermediate_callback, and neither callback matches your browser application's /auth/verify route.

The Python server points to that provider with:

REPORT_AUTH = OAuth2(
    id="report-demo-clerk",
    scopes=["openid", "profile", "email", "offline_access"],
)

The ID must match the provider you configured. The scopes request identity and refresh access. Workspace membership and subscription permissions remain separate checks in your application.

5. Register the Browser User Verifier

The person completing API authorization needs to match the application user who started the flow. Your browser application can confirm that match using the signed-in user's verified Clerk browser session. Register its verifier route with Arcade to make that check part of tool authorization.

In Arcade Auth → Settings, select Custom verifier and enter your public application origin followed by /auth/verify:

https://YOUR-NGROK-DOMAIN/auth/verify

For the local demo, use the ngrok origin you set in APP_URL. For a deployed application, use its browser sign-in origin followed by /auth/verify. The companion includes this route. Here's what it does:

1. Receive the authorization flow's flow_id from Arcade.

2. Read the verified Clerk browser session. If the visitor signed out, preserve the flow's return path and send them through sign-in.

3. Confirm the session's user ID with Arcade from the server, using the project's API key.

4. Continue the authorization flow or show completion once finished. Report a mismatched or failed flow as an error.

The user ID comes from the verified session. The route never takes it from an MCP argument or browser query parameter, and the Arcade API key stays on the server. The implementation includes the sign-in redirect and failure handling.

For identity matching, keep both OAuth applications in the same Clerk instance and select sub as the User Source subject. Clerk documents this subject as the authenticated user's ID. Clerk's OIDC claims and Arcade's verifier contract describe the user ID Clerk supplies and the identity Arcade expects.

This was one detail we had to untangle. Connecting to the gateway doesn't give the MCP tool your application's browser session. The verifier uses that session in the browser application. The MCP tool sends the user's delegated OAuth access token to the API.

6. Configure Clerk Sign-In for the MCP Gateway

The User Source connects the gateway to Clerk, so users can sign in with the same login they use for the reporting application. Configure it with the separate gateway OAuth application you created in step 2.

In the Arcade demo project's User Sources, add:

Confirm that the Clerk gateway application's redirect list contains:

https://cloud.arcade.dev/oauth2/intermediate_callback

Gateway login uses the User Source. API access uses the OAuth provider. Tool authorization also uses the browser verifier. Keep their names and callback values separate when troubleshooting.

7. Add OAuth-Protected Tools to the MCP Server

The finished server lives in mcp/src/report_demo_mcp/server.py. It exposes four operations:

Start with get_current_user:

@app.tool(requires_auth=REPORT_AUTH, requires_secrets=[API_CONFIG_KEY])
async def get_current_user(context: Context) -> dict:
    """Get the API-verified user and their permitted workspaces.

    Call this to discover the workspace IDs available to the signed-in user.
    The API derives identity from the OAuth token; the model supplies no user ID.
    """
    return await _api_request(context, "GET", "/api/me", expected_statuses={200})

The shared _api_request helper calls context.get_auth_token_or_empty(), rejects an empty token, and sends it to the configured API in an Authorization: Bearer ... header. The helper limits request time and response size, disables redirects, and returns safe error messages. The download includes the full helper.

Arcade injects Context when the tool runs. The model supplies neither the token nor the destination URL. Each tool declares REPORT_API_BASE_URL as required configuration and reads it through context.get_secret(...). The origin isn't confidential. The secrets mechanism supplies it to the hosted tool.

On the API side, ask Clerk to verify an OAuth access token:

const identity = await auth({ acceptsToken: "oauth_token" });

The API checks the verified OAuth client ID against REPORTS_OAUTH_CLIENT_ID, then looks up the user's fixture membership. The API accepts OAuth access tokens issued for the Report demo API application and rejects gateway credentials and browser-session tokens. Clerk's helpers handle both JWT and opaque OAuth formats. Clerk's OAuth-token verification guide covers that boundary.

If a tool needs user details, it can call /api/me. You can also configure a provider user_info_request to put metadata in context.authorization.user_info. This example doesn't need it, and the API still must check access. The OAuth-provider reference describes that optional configuration.

8. Deploy the MCP Server to Arcade Cloud

Deploy the mcp/ project so customers can call its protected tools through an Arcade gateway. Keep the separate web/ application running at the HTTPS origin from step 3.

From report-mcp-demo/mcp:

uv run arcade login
uv run arcade project list
uv run arcade project set YOUR_DEMO_PROJECT_ID
uv run arcade deploy -e src/report_demo_mcp/server.py --secrets skip

Replace YOUR_DEMO_PROJECT_ID with the demo project's ID from the list. The CLI uses the saved project, so select the one containing your User Source, OAuth provider, and custom verifier.

--secrets skip tells the CLI not to upload local secret values. You'll configure the required API address after the server has been deployed, before calling any reporting tools.

The entrypoint defaults to stdio for local development. Arcade supplies the hosted execution settings during deployment. Run the deploy command from the directory containing pyproject.toml, as described in Arcade Deploy.

Wait for deployment to succeed and keep the returned server name. In the Arcade dashboard, open Servers, select that server, and open its secret configuration. Add the following key and replace the placeholder with your backend's public HTTPS origin:

REPORT_API_BASE_URL=https://YOUR-NGROK-DOMAIN

Use the demo's ngrok origin, or your deployed API's HTTPS origin, without /api or a trailing slash. Save the value before proceeding. This address may differ from the browser verifier's origin in an existing application. From Arcade Cloud, localhost doesn't point to your computer.

The configuration splits across four places:

Customers never receive your developer Arcade API key. Arcade supplies their API token to the tool after its authorization requirements are satisfied.

On the server's page, confirm that the deployment is healthy and has all four reporting tools. You can also inspect registered servers from this project with:

uv run arcade server list

The tools may appear with names such as ReportDemo_GetCurrentUser.

Checkpoint: The intended server is healthy, lists all four operations from step 7, and has REPORT_API_BASE_URL configured. Server health confirms that the deployment started; it doesn't verify backend access. Next, connect Claude and call get_current_user to check customer login, tool authorization, and backend access together.

9. Create an MCP Gateway and Connect Claude Desktop

The gateway gives Claude one URL for your tools and uses the User Source to sign customers in.

Create an MCP Gateway in that project. Select the four reporting tools from your deployment. Under Non-Arcade Users → User Source, choose Report demo Clerk. Copy the resulting gateway URL, which has this form:

https://api.arcade.dev/mcp/YOUR-GATEWAY-SLUG

In Claude Desktop, use Settings → Connectors → Add custom connector, enter that URL, and retain the detected OAuth settings and Claude's published client identity. Sign in with Alice's demo application account. Alice should not be an Arcade project member. Gateway configuration and Claude's Arcade connection guide describe these steps.

Ask:

Use the reporting tools to show my current user and available workspaces.

On the first call, follow any tool-authorization link the client presents. Complete API consent and browser verification, then call the tool again if the client hasn't resumed. Existing sessions can reduce the prompts. Gateway login and the API grant remain separate, and you don't need to paste a token into the conversation.

The response should identify Alice and include team-red. Expected response shape for the Alice fixture:

{
  "user_id": "user_ALICE_CLERK_ID",
  "workspaces": [
    {
      "workspace_id": "team-red",
      "name": "Team Red",
      "tier": "pro"
    }
  ]
}

user_ALICE_CLERK_ID stands for the Clerk user ID you configured for Alice. This illustrates the response, not a captured live result.

Checkpoint: The response identifies Alice and includes team-red. Gateway login, tool authorization, and the API now work together. You can use that workspace ID to request a report.

9.1 Start Reports, Check Status, and Retrieve Results

Some backend operations continue after the initial request returns. To expose that job workflow through MCP, the agent needs to start work, check progress, and collect the result. A job ID connects those calls. The synthetic report uses this pattern so you can apply it to an existing background workflow in your application.

start_report sends a request such as:

{
  "workspace_id": "team-red",
  "topic": "Onboarding",
  "report_type": "advanced"
}

The API returns HTTP 202 with a report_id, status, and poll_after_seconds. The job has been accepted. The report is still pending. The agent waits, checks status, and retrieves the result when the status becomes completed. The agent should stop on failed and limit the number of checks.

The web application runs the jobs and stores their state. Each MCP call on Arcade Cloud starts work or reads progress. The job continues in the backend between calls. The sample uses a small in-memory job store and synthetic records. Restarting the web process loses the jobs. Reports also expire after 15 minutes. A production application would use its existing durable job system.

If a POST times out, a report might already exist. The helper doesn't tell the model to submit again blindly. Retrying a read and retrying job creation carry different consequences.

Then ask:

Start an advanced report about onboarding in team-red. Keep its report ID, wait at least as long as the response requests between status checks, and retrieve the completed result. Stop after ten checks if still pending.

The agent can now find an accessible workspace, start a report, and retrieve the result.

10. Test Workspace Permissions and Subscription Tiers

Now check that agent access respects the SaaS rules we started with: colleagues can work within their shared workspace, customers remain separated, and report access respects the workspace's plan. The reporting API checks workspace access and the required tier on every report request.

Use separate browser/client profiles, or reconnect when switching identities, so a cached grant doesn't hide which user you're testing.

The status and result routes look up the report's workspace and check access again. Knowing a job ID doesn't grant access to its output. Apply the same check to a download endpoint as to the request that starts the job.

Use the optional staff account to check access to both workspaces and confirm Team Blue's Basic tier still blocks advanced report creation. The model can't grant staff access by setting an is_admin argument. For your application, use the roles and policies your server controls.

Run the included local checks:

# From web/
npm test
npm run typecheck

# From mcp/
uv run pytest

These checks cover the synthetic permissions and request behavior. Use the demo application accounts you created to test gateway login, tool consent, and browser verification. Start with the hosted get_current_user call before creating a report. A local greeting or healthy server alone won't test that flow.

Troubleshoot MCP Authentication and API Errors

We hit this during our integration: authentication worked, but the tool couldn't reach the backend. The problem was on our server. A successful login hadn't told us whether the API request would work.

Check the MCP deployment logs and the web application's logs separately. For the MCP logs, use the server name returned by deployment:

uv run arcade server logs YOUR-SERVER-NAME

Log a request outcome and safe error category. Avoid logging bearer tokens, full authorization context, or upstream response bodies that may contain customer data.

Connect MCP Tools to Your Existing Backend API

To connect your own application, replace the synthetic report API with an operation your backend already provides. Describe the tools precisely: which one starts work, which retrieves results, and which identifiers the agent needs to keep. Replace the fixtures with your existing membership, role, and entitlement checks.

Production Extensions: Tool Visibility, Permissions, and Durable Jobs

The example gives users the same four tools and enforces their permissions in the API. Further production work could include:

• Tool visibility based on permissions. Show clients tools appropriate to the user's role and plan, for example through Arcade's Contextual Access. Keep the API checks when tools execute. Here, basic and advanced reports share start_report. Hiding that tool from Basic users would also remove their permitted basic reports. The requested workspace and report type still need authorization.

• Changing memberships and plans. Read current access rules from your application instead of static fixtures. Define and test how membership revocation and plan downgrades affect new requests and existing jobs.

• Durable jobs and safe retries. Persist job state and make report creation idempotent, so retrying the same submission after a timeout returns its original job instead of creating a duplicate. This enables complex, multi-step workflows where a single timeout or API failure doesn't crash the entire agentic loop.

The MCP server gives the agent operations to call. Your API verifies the user's delegated credential and decides whether to allow the operation. Clerk supplies the identity. Arcade.dev runs the gateway and MCP tools and supplies the user's API token after authorization. You can expose more of your backend through the same pattern.

Full code: multi-tenant-mcp-server-oauth. Clone it, run the tests, swap in your API.

Frequently Asked Questions

Does MCP support OAuth?

Yes. The Model Context Protocol supports OAuth-protected remote servers, and clients like Claude and ChatGPT can complete that flow. This tutorial uses OAuth twice: once to sign the user into the Arcade.dev gateway, and once to obtain the delegated Clerk token that the tools send to the reporting API.

Why use an MCP gateway instead of exposing the MCP server directly?

A gateway, such as Arcade.dev, handles the plumbing you would otherwise build: sign-in through your existing identity provider, per-user token storage and refresh, and injecting the right user's token into the right tool call. It also gives customers one stable URL that can federate more MCP servers and enforce tool-level governance as you grow.

Why not use Clerk's MCP support instead of a gateway?

You can. Clerk can act as the authorization server for a self-hosted MCP server through dynamic client registration, which collapses this tutorial's three credentials into one. The trade-off: you host and operate the server yourself, and Clerk's MCP helpers target JavaScript frameworks while these tools are Python. Note that mcp.clerk.com is a different product: Clerk's own documentation server for AI coding agents.

Do customers need an Arcade.dev account to connect their agent?

No. The gateway's User Source lets customers sign in with their existing application login, with Clerk as the identity provider. Only the developer who deploys the MCP server needs an Arcade.dev account.

Does this work with ChatGPT or only Claude?

Any MCP client that supports the Streamable HTTP transport can use the same gateway URL. This tutorial connects Claude Desktop. For ChatGPT, add the gateway URL as a custom connector with OAuth, which requires developer mode and a plan that supports custom connectors.

How do you stop an AI agent from accessing another tenant's data?

Derive identity from the verified OAuth token and authorize in the API, never from arguments the model supplies. Here, the reporting API checks workspace membership and plan tier on every request, and lookups for a report the caller cannot access return the same response as an unknown ID, so report IDs grant nothing.

What's the difference between authentication and authorization in an MCP server?

Authentication proves who is calling; authorization decides what they may do. In this architecture, Clerk and the Arcade gateway handle authentication and token delegation, while authorization stays in the backend API, which applies the same workspace and tier rules it enforces for every other client.

I built this comparison from three evidence layers. Official documentation, Reddit reports (excluding disclosed vendor accounts and my own comments), and hands-on evaluations against a reusable gateway for an API-backed multitenant B2B application.

An MCP gateway is the control point between an agent client and one or more MCP servers. It can aggregate tools, authenticate connections, enforce policy, and record traffic.

That definition covers a wide range of products, from Docker's local container gateway to enterprise control planes and integration runtimes. Treating them as interchangeable is the first mistake most comparisons make.

Disclosure: My company, Zenith, provides content marketing services to Arcade.dev and previously worked with Composio. The testing and conclusions in this article are my own.

TL;DR: Best MCP gateways by use case

• Best for custom, multi-user B2B gateways: Arcade.dev. It was the only product in my ten-product evaluation that completed the target architecture, accepted a custom MCP server, and connected successfully from Claude Code within 60 minutes.

• Best-supported local option based on independent evidence: Docker MCP Gateway. Has the most user reports on local MCP management, with strengths in container isolation and multi-client convenience, and clear limits outside Docker Desktop.

• Best fit for existing AWS estates: Amazon Bedrock AgentCore. It brings Lambda functions, APIs, and remote MCP servers into the same IAM, CloudTrail, and CloudWatch control plane teams already operate.

• Best when source availability is mandatory for downstream OAuth: Nango. It handles provider OAuth, token refresh, and credential storage, but assumes inbound authorization and gateway policy exist elsewhere. Arcade covered the complete multitenant MCP path in the hands-on test.

• Best fit for existing Kong deployments: Kong AI Gateway. Relevant when an organization already operates Kong's licensed data plane. Too complex for a greenfield MCP-only deployment.

MCP gateway comparison: strengths, complaints, and test results

This comparison covers production-oriented, multi-user gateways that can expose custom applications and tools through MCP. I also included products built for narrower roles, like local development, downstream OAuth, integration catalogs, or security overlays, evaluating each of those against that standard rather than the full gateway job.

MCP gateway categories

These products serve different architectural roles, and lumping them together as direct competitors is misleading.

Application and authorization gateways. Arcade, Obot, IBM ContextForge, Amazon Bedrock AgentCore, TrueFoundry, MintMCP. These sit between MCP clients and servers, handling authentication, authorization, policy, and tool management.

Local MCP management. Docker MCP Gateway, Lunar MCPX. Focused on managing MCP servers on a developer workstation or local environment.

Integration and downstream-auth infrastructure. Composio, Nango, Merge. These handle connections to third-party services, OAuth token management, and integration catalogs.

Existing gateway extensions. Kong AI Gateway. MCP support added to an established enterprise API gateway platform.

How this MCP gateway comparison was researched

• Corpus: Research covering more than 300 relevant Reddit posts and comments.

• Period: September 2024 through July 21, 2026. Hands-on testing took place July 20 and 21, 2026.

• Sources: Reddit communities focused on MCP, LLM development, self-hosting, systems administration, SaaS, AWS, and Terraform.

• Searches: Each product was paired with terms covering OAuth, production use, self-hosting, pricing, outages, migration, security, policy, observability, alternatives, and reviews.

• Evidence weighting: I weighted technical claims by specificity, repetition, freshness, and agreement with documentation or testing. I didn't treat disclosed vendor accounts or my own comments as independent user evidence.

• Version handling: I’ve labeled older reports as historical. Fixed vulnerabilities aren't presented as current defects.

• Hands-on testing: Each product was tested against the same target: exposing an API-backed multitenant application through a reusable MCP gateway.

• Test conditions: macOS, Claude Code client, up to roughly one hour per product.

• Last updated: July 21, 2026.

The hands-on evaluations measured onboarding and architectural fit. Production load, failure recovery, token lifecycle, cost at scale, and security fell outside scope. The onboarding test favored products with a managed, self-service path. Products requiring local, containerized, or cloud infrastructure deployment were not attempted. Their out-of-scope status reflects the test design, not a product limitation.

Evidence confidence levels. Each product is rated across three dimensions.

• Hands-on testing (High/Medium/Low/Blocked/Out of scope) reflects the depth of the author's own evaluation.

• Documentation (High/Medium/Low) reflects how well vendor documentation supports the product's claims.

• Independent evidence volume (Deep/Moderate/Thin) measures how much verifiable, non-vendor evidence exists, not whether that evidence is favorable.

Deep means enough independent reports to assess the product clearly. Moderate means some independent data, limited in scope. Thin means the independent record is near-empty or predominantly vendor-authored.

How to evaluate an MCP gateway: 10 criteria

These criteria came from repeated Reddit themes, not vendor feature matrices.

Hands-on MCP gateway test results

A fast vendor demo isn't the same as exposing a custom multitenant application through a reusable MCP gateway. GitHub provided a common integration baseline, but the real pass condition was whether the product could support the broader B2B architecture.

The category boundary matters. Arcade behaved like a gateway and governed runtime for this test. Composio behaved like a managed SaaS-tool connection layer. Merge delivered a fast vendor-controlled playground path.

Nango addressed downstream authentication to third-party services, but my own MCP endpoint still needed its own inbound authorization layer. Kong's managed experience behaved first like an LLM router, and reaching the MCP path required data-plane setup in my test. Obot's test ended at identity-provider configuration before I could evaluate its gateway.

Arcade MCP Gateway: best overall for custom multitenant B2B applications

Bottom line: Arcade produced the strongest result in my ten-product evaluation. It was the only product that completed the target architecture.

Documentation and Reddit evidence

What the company claims: Arcade combines an MCP gateway with managed tool execution, user-scoped credentials, authorization policy, audit, and an agent-oriented integration catalog. The product is built around safely letting agents act on behalf of individual users.

What the cited Reddit reports consistently praise: Arcade's authorization controls, governance, and hook-level failure policies stand out.

A separate builder described access, pre-execution, and post-execution hooks with input modification, output filtering, dry-run testing, and per-hook fail-open or fail-closed behavior. Another commenter identified per-hook failure policy as the most useful production design choice because different tools carry different risks.

The report documents policy behavior but doesn't include uptime, latency, high-availability, or scale data.

What Reddit users complain about: Pricing clarity and category clarity are the blockers. One buyer questioned a reported 100-fold call-price gap. An earlier evaluator struggled to distinguish Arcade from MCP plus OAuth.

The Reddit corpus doesn't have data on uptime, latency, self-hosted operating burden, support quality, or production scale.

Hands-on evaluation

What I found when I tested it: Arcade was the only product that completed the full target architecture. Within 60 minutes, I connected GitHub, created the gateway through the web interface, added and removed tools, and attached a custom MCP server through either the web interface or command line.

The resulting URL connected successfully from Claude Code and supported MCP-native tool discovery. I also verified authentication at both boundaries, from Claude Code to the gateway and from the gateway to downstream tool calls.

Tool-level authentication worked after I hosted the tool on Arcade's runtime. The documentation didn't clearly state this requirement.

Recommendation

Who should choose this: Product teams building multi-user agents that take delegated actions in customer or employee accounts.

Who should avoid this: Teams that only need a protocol proxy, a local MCP catalog, or a generic API gateway they already operate.

Evidence confidence: Hands-on was high, since I completed the full target architecture in 60 minutes. Documentation was also high, covering authorization, governance, hook design, and deployment options. Independent evidence volume was thin, with no data on production adoption, reliability, self-hosted operations, or scale.

Docker MCP Gateway: best local open-source MCP setup

Bottom line: Docker is the best default for centralized local MCP servers, but it's not a remote multi-user control plane.

Documentation and Reddit evidence

What the company claims: Docker's Gateway and Toolkit containerize MCP servers, inject credentials, manage server lifecycle, and expose one shared catalog to compatible clients. The pitch is safer, simpler local MCP management through Docker's existing desktop and container model.

What Reddit users consistently praise: Users value one-time configuration, catalog convenience, and container isolation. The 15 to 18 independent firsthand users make this the strongest local-use corpus in my comparison. Developers also like reusing the same managed server set across multiple desktop clients instead of maintaining separate configuration files.

What Reddit users complain about: Tool-list inflation is the most measurable complaint. One report counted 70 tools consuming about 49,351 tokens. Another measured 13.3% context usage versus 0.1%. ARM64 compatibility, secret handling, and headless deployment create additional friction.

Hands-on evaluation

What I found when I tested it: Access required filling out a sales form. I decided not to proceed, so this assessment is based on product documentation and the cited user reports.

Recommendation

Who should choose this: Developers who already use Docker Desktop and want isolated local servers shared across multiple MCP clients.

Who should avoid this: Teams that need remote multi-user identity, delegated authorization, centralized enterprise policy, or a headless fleet control plane.

Evidence confidence: Hands-on was blocked, and no self-serve tier was available. Documentation was high, with a clear product scope and well-defined feature boundaries. Independent evidence volume was moderate. The 15 to 18 independent firsthand users make this the strongest local-use corpus in this comparison, but coverage stays limited to local development, which is why it’s moderate rather than deep. No data exists on production governance, scale, or remote multi-user use.

Amazon Bedrock AgentCore Gateway: AWS-native managed MCP infrastructure

Bottom line: AgentCore fits teams already standardized on AWS that want Lambda functions, APIs, and remote MCP servers behind an AWS-managed gateway. Its Runtime has limited but real production evidence. I found no independent production validation for Gateway, Identity, or Policy.

Documentation and Reddit evidence

What the company claims: Amazon Bedrock AgentCore Gateway composes Lambda functions, APIs, remote MCP servers, agent runtimes, and model providers behind one managed MCP endpoint. AWS documents protocol translation, inbound authorization, downstream credential exchange, tool filtering, semantic tool selection, policy, interceptors, and observability.

Gateway is one service in the wider AgentCore platform, alongside Runtime, Identity, Policy, Memory, and other agent infrastructure.

What Reddit users consistently praise: The strongest evidence is broader than Gateway but includes real MCP production use. One user said their company runs AgentCore in production for MCP deployments and agent sandboxes. They liked its cold starts and cost, and still noted Amazon-specific constraints around state and MCP usage.

A separate evaluator called AgentCore the easiest way to set up an agent proof of concept (POC) on AWS.

Gateway-specific reports support the architecture more than production maturity. One commenter identified Gateway with Lambda targets as the right fit for converting an existing backend into MCP tools. Another explained that Gateway becomes useful as one intermediary for many agents and remote MCP servers because it can centralize inbound and outbound identity and observability.

But that same discussion contains the opposing boundary. Adding a single remote MCP server as a Gateway target may be unnecessary over-engineering when the agent can call it directly.

What Reddit users complain about: The most concrete operational complaints concern AgentCore Runtime and the surrounding AWS platform, not Gateway itself. One evaluator reported Runtime sessions continuing toward the eight-hour maximum after StopRuntimeSession, creating a session-lifecycle and billing risk.

That's a Runtime issue, not a defect in AgentCore Memory or proof of a Gateway problem. Another user struggled to get container logs into CloudWatch because of execution-role permissions and unwieldy OpenTelemetry output.

A separate pricing-calculator error produced a $16 million estimate after confusing vCPU-hours with vCPU-seconds. That was a calculator defect, not an actual bill.

Infrastructure maturity and lock-in remain fit questions. A community member built a Terraform module after finding the workflow too CLI- and script-oriented.

That complaint is dated. AWS reports that its AgentCore CDK constructs became stable in May 2026. A comparative evaluator still praised Firecracker session isolation while criticizing AWS lock-in and the absence of on-premises deployment.

Hands-on evaluation

Hands-on status: Out of scope. Creating the required AWS account configuration, roles, targets, and related infrastructure was outside the timeboxed evaluation. This assessment is based on product documentation and the cited user reports.

Recommendation

Who should choose this: AWS-standardized teams already operating Lambda, API Gateway, Cognito or another compatible identity provider, IAM, CloudTrail, and CloudWatch that want MCP to live in the same control plane.

Who should avoid this: Teams that require cloud portability, on-premises deployment, a lightweight standalone gateway, simple cost attribution, or minimal AWS IAM and networking work.

Evidence confidence: Hands-on testing was out of scope, since creating the required AWS configuration fell outside the timeboxed evaluation. Documentation was high, with extensive AWS coverage across Gateway, Runtime, Identity, and Policy. Independent evidence volume was thin. One production account covers Runtime, and several implementation discussions exist, but I didn’t find any independent Gateway production report.

TrueFoundry MCP Gateway: Kubernetes-native enterprise governance

Bottom line: TrueFoundry fits regulated teams that want model, MCP, and agent governance inside their VPC. Gateway-only buyers inherit a larger platform than they need.

Documentation and Reddit evidence

What the company claims: TrueFoundry's federated architecture provides centralized auth, role-based access, audit, budgets, and policy while keeping runtime components within the customer's infrastructure. The MCP gateway sits inside a wider platform for governing models, agents, and AI workloads.

What Reddit users consistently praise: Governance, private deployment, RBAC, audit, and budgets drive positive evaluations. One established account called the platform excellent. A promotional-looking account reported working fallback chains, which is useful product evidence but isn't independent validation.

What Reddit users complain about: Routing configuration is the most specific repeated criticism. Two independent evaluators described fragmented routing configuration as less flexible than Portkey, a competing LLM proxy tool. Another reported dropped Google flags and incorrect token counts for virtual models.

Hands-on evaluation

What I found when I tested it: The basic GitHub integration test completed in about 10 minutes with no friction.

Setting up a custom external identity provider didn't work. The configuration kept returning errors when connecting the external provider. I gave up after about 30 minutes total. For a product whose positioning centers on enterprise governance, the identity layer is a core differentiator that I couldn't validate.

Recommendation

Who should choose this: Regulated organizations already standardized on Kubernetes that want one control plane for models, MCP servers, and agents.

Who should avoid this: Teams shopping for a thin MCP proxy, a low-operations managed integration layer, or a lightweight local tool.

Evidence confidence: Hands-on testing was medium. The basic GitHub test completed in 10 minutes, but identity provider setup failed with configuration errors after 30 minutes. Documentation was medium, with federated architecture, RBAC, audit, and budget controls. Independent evidence volume was also moderate. One established account praised it, and routing complaints come from independent evaluators, but I found no production-scale validation.

IBM ContextForge: open-source MCP gateway for enterprise federation

Bottom line: ContextForge has the broadest documented open-source enterprise feature set in this comparison. Before production, test high availability, latency, restart recovery, and operating burden.

Documentation and Reddit evidence

What the company claims: ContextForge federates MCP, A2A, REST, and gRPC services behind virtual servers, plugins, policy controls, identity features, and OpenTelemetry. The pitch is an enterprise control plane for mixed protocols and upstream services.

What Reddit users consistently praise: The strongest firsthand account covers virtual servers, SSO, and encrypted downstream personal access tokens. A separate user described header rewriting for Jira Data Center. Another company self-hosted ContextForge while evaluating Kong.

The real strength is federation with identity bridging, which goes beyond simple protocol proxying.

What Reddit users complain about: Operational complexity is the recurring cost. The strongest operator still considered consolidating components, and older production warnings show why version dates matter.

The cited reports cover IAM and federation, but leave out high availability, A2A traffic, or latency under load.

Hands-on evaluation

Hands-on status: Out of scope. ContextForge required deploying and managing the service either locally or on the cloud, which I kept out of scope for this test. This assessment is based on product documentation and the cited user reports.

Recommendation

Who should choose this: Enterprises that require a fully self-hosted control plane, mixed upstream protocols, and integration with existing IAM.

Who should avoid this: Small teams without clear ownership for deployment, databases, upgrades, observability, and incident response.

Evidence confidence: Hands-on testing was out of scope, since it required deployment infrastructure. Documentation was medium, with the broadest open-source feature set in this comparison, but I couldn’t verify this myself. Independent evidence volume was thin. The strongest account covers SSO, virtual servers, and header rewriting, but there’s no HA, A2A traffic, or latency data.

Nango MCP Auth: downstream OAuth infrastructure, not an inbound MCP gateway

Bottom line: Nango is a strong supporting component when your gateway needs to connect users to third-party APIs or MCP servers without owning provider-specific OAuth maintenance. It didn't replace the inbound authorization layer I needed to expose my own multitenant application through MCP.

Documentation and Reddit evidence

What the company claims: Nango provides managed OAuth, token refresh, credentials, and integration infrastructure, with support for exposing integrations to agents and MCP clients. It focuses on auth and integration maintenance instead of a full enterprise MCP control plane.

What Reddit users consistently praise: Independent builders often appreciate how Nango reduces provider-specific OAuth work. A QuickBooks builder recommended using Nango as the auth layer while the application requested a fresh access token per request.

A separate RAG builder used it to add Google Drive, Dropbox, and Notion, and a bootstrapped SaaS developer said Nango's local authentication did exactly what they needed. These reports validate setup convenience and reduced OAuth work, but none covers multi-month token refresh or production tenant isolation.

What Reddit users complain about: Self-hosting, documentation, regional hosting, and product boundaries recur as blockers. One self-hoster received HTML from an API call and couldn't progress. Another buyer wanted EU hosting and stronger token security. A bootstrapped developer liked Nango's authentication but found the unified API cost-prohibitive.

A 2023 evaluator found pagination, documentation, and data mapping outside Nango's useful scope at the time. That report applies to the 2023 release, so don’t treat it as current behavior.

A CRM developer used Nango to rapidly connect a fragmented set of CRMs for a partner-management product, but said they'd build that layer in-house today. That supports Nango as a way to ship faster early on. But it also shows Nango didn't remove the custom domain logic or the eventual build-versus-buy decision.

Hands-on evaluation

What I found when I tested it: Google SSO was easy, and Nango's Node.js and cURL examples worked without friction against GitHub. The architectural boundary became clear within 30 minutes.

Nango MCP Auth helps an application connect outward to third-party MCP servers and stores the resulting OAuth tokens. It didn't act as the inbound OAuth authorization server in front of my own multitenant MCP endpoint.

In my architecture, the identity provider and application gateway still had to handle client registration, user login, token issuance, audience restriction, and bearer-token verification. Nango only managed the downstream credentials.

I stopped because completing the target architecture required way more infrastructure than the test justified. The getting-started success action also centered on starring Nango's GitHub repository rather than proving the API-to-MCP path I was trying to build.

Recommendation

Who should choose this: Teams that already have an inbound gateway or authorization layer and want to own their integration logic while outsourcing downstream OAuth edge cases and ongoing provider maintenance.

Who should avoid this: Buyers expecting Nango alone to expose and authorize access to their own multitenant MCP service, normalized business objects, mature MCP policy, or a self-hosted product that requires little operational work. Teams using only client-credentials grants gain less from user-facing OAuth management. One developer described that exact architectural preference.

Evidence confidence: Hands-on testing was medium. I tested for 30 minutes, and the Node.js and cURL examples worked, but then I stopped when the architectural boundary became clear. Documentation was also medium. The OAuth setup path was clearly laid out, but self-hosting docs drew complaints. Independent evidence volume was moderate. Multiple independent builders praise OAuth abstraction, but there’s no multi-month refresh data, and self-hosting reports are mostly negative.

Kong AI Gateway: MCP support for existing Kong deployments

Bottom line: Kong is the incumbent-extension choice for organizations already governing APIs through Kong. It's a weak greenfield recommendation for teams that only need MCP.

Documentation and Reddit evidence

What the company claims: Kong AI Gateway extends Kong's traffic management, plugins, security, and observability model to AI and MCP traffic. The pitch is to govern MCP through the same gateway platform you already use for APIs.

What Reddit users consistently praise: Kong's mature gateway controls carry real weight. Users respect its PII controls and semantic routing. The real positive is practical. Kong reuses infrastructure, skills, plugins, and procurement that already exist.

What Reddit users complain about: As one Redditor put it, Kong is "Powerful if you are already a Kong shop". One team spent two weeks implementing per-agent identity in Lua before choosing Gravitee. I found almost no independent production use of Kong's MCP and A2A-specific plugins.

Hands-on evaluation

What I found when I tested it: Google SSO was straightforward, and creating an AI Gateway was easy. Kong's managed demo worked within five minutes, but the experience initially felt more like an LLM router than an MCP gateway.

The GitHub MCP path stopped at Kong data-plane setup. The next documented stage required a Kong data plane and applicable licensing. Because the evaluation excluded deploying an existing enterprise gateway stack, I stopped at that point. This reinforced Kong's fit as an extension for existing Kong customers.

Recommendation

Who should choose this: Organizations with an established Kong platform team that want MCP policy and traffic to live in the same operational control plane.

Who should avoid this: Greenfield teams that would be adopting Kong solely for MCP or that need delegated integration auth out of the box.

Evidence confidence: Hands-on testing was low. In 10 minutes, I only reached a managed demo before stopping at the licensed data-plane setup requirement. Documentation was medium, since Kong is a mature platform with well-covered infrastructure. Independent evidence volume was thin. Kong is respected among existing Kong shops, but I didn’t find any MCP-specific production evidence to back it up.

Obot MCP Gateway: open-source hosting, registry, and access

Bottom line: Obot combines hosting, registry, access, and client delivery in one open-source platform. The independent evidence amounts to one Kubernetes deployment and one shorter "works well" report.

Documentation and Reddit evidence

What the company claims: Obot combines MCP hosting, a registry, OAuth, access rules, audit, and a client in one self-hostable platform. It covers the full path from server deployment to governed end-user access.

What Reddit users consistently praise: The strongest case is a six-node Kubernetes environment using Obot to organize several MCP services. Another user simply said it works well. These reports support the value of putting hosting, access, discovery, and client access in one system.

What Reddit users complain about: In the direct comparison I found, one evaluator preferred TrueFoundry for registry, RBAC, OAuth, and observability. Obot's own DevRel acknowledged that the quick Docker examples were minimal and that production requires persistent infrastructure. Both disclosed security issues were fixed, so it’s worth verifying you're running the patched version during deployment.

Hands-on evaluation

What I found when I tested it: Obot's cloud signup started by provisioning an instance. I spent about 15 minutes on the test, most of it waiting for that instance to become available.

Continuing required configuring a separate supported identity provider. Because that dependency was outside my test setup, I stopped before evaluating the gateway. I didn't reach Obot's gateway, registry, access-control, or runtime capabilities.

Recommendation

Who should choose this: Teams that want one open-source system for MCP hosting, registry, access, and client delivery.

Who should avoid this: Buyers who require a long production track record, externally validated HA characteristics, or the deepest enterprise governance today.

Evidence confidence: Hands-on testing was low. I spent 15 minutes on the test and got blocked at OAuth-provider setup before reaching the gateway. Documentation was medium. Hosting, registry, access, and OAuth are all covered. Independent evidence volume was thin. It comes down to one Kubernetes deployment and one shorter positive report.

Composio MCP Gateway: managed toolkit integration layer

Bottom line: Composio is one of the fastest ways to give an agent access to many SaaS products, and I found its initial SaaS-tool onboarding fast in my own testing. But independent reports and a confirmed 2026 security incident raise questions that high-risk teams should investigate before production use.

Documentation and Reddit evidence

What the company claims: Composio Sessions provides per-user endpoints, managed authentication, tool allowlists, routing, and a broad integration catalog. The pitch is fast access to many SaaS tools without building each OAuth and execution layer yourself.

What Reddit users consistently praise: The cited reports like the setup speed, integration breadth, and Tool Router's context reduction. One user said the Tool Router worked well and reduced context bloat. An n8n builder also reported getting a social automation workflow working through Composio's MCP layer.

What Reddit users complain about: The strongest recurring negative is poor LLM-oriented tool design, including excessive parameters, thin API wrappers, missing-parameter failures, and agents that fail to complete actions. The original evaluator later said the same problem caused them to abandon Composio. A separate firsthand report said multi-tenancy “doesn’t seem to scale well” and some tools “feel like placeholders”.

Users also report a four-day outage, a GitHub connection that remained active but returned 401 Bad Credentials, opaque charges, and risk from bearer-like hosted URLs. In a separate report, another user said they couldn't connect to MCP.

Verified incident history: Composio's official incident report confirms unauthorized access, 5,001 compromised GitHub connections, roughly 0.3 percent of active connections leaked, and 5,241 API keys in a cache the attacker likely accessed. These are first-party confirmed incident facts, separate from the Reddit reliability reports.

Hands-on evaluation

What I found when I tested it: Signup through Google SSO was easy, and I had the starter running in roughly 15 to 20 minutes after fixing a minor missing environment-loading step.

The initial success was misleading for my target architecture. The example used my local GitHub CLI rather than Composio's GitHub toolkit. After I explicitly instructed the agent to use Composio MCP, I had to connect GitHub to a user and discover that the request also needed that connected user's user_id. The getting-started path didn't explain this clearly.

Logs didn't appear in the web console, and the terminal output was highly verbose. The getting-started success action also centered on starring Composio's GitHub repository rather than proving the API-to-MCP path I was trying to build.

After about 70 minutes, I still hadn't created a reusable gateway where different users could authenticate. The toolkit endpoint generated in my test was user-specific, and I couldn't find a supported path for attaching my own remote MCP server or having Composio host it. For this test, Composio behaved more like a managed SaaS-tool connection layer than an organizational MCP gateway.

I used Claude for troubleshooting. It resolved most setup questions, but didn't close the authentication gap.

Recommendation

Who should choose this: Teams optimizing for prototype speed and broad SaaS coverage that can independently test critical integrations.

Who should avoid this: High-risk teams should avoid Composio when failed actions, credential exposure, poor LLM-oriented tool design, or a prolonged outage could create material business or compliance impact. The most credible escape path in the Reddit evidence is direct provider APIs or small in-house integrations. That reduces middleware blast radius but transfers OAuth, API drift, and maintenance back to your team.

Evidence confidence: Hands-on testing was medium. The starter worked in 70 minutes, but I never reached the target architecture, and the getting-started path was misleading. Documentation was medium. Sessions and tool routing were documented, but getting started didn't surface the user_id requirement. Independent evidence volume was deep, with enough independent praise, detailed criticism, outage reports, and a confirmed security incident to support clear conclusions.

Merge Agent Handler: B2B integrations for AI agents

Bottom line: Merge Unified's track record doesn't validate Agent Handler. I found zero independent reports of connecting an MCP client, executing a tool, or testing its DLP, audit, or observability controls.

Documentation and Reddit evidence

What the company claims: Merge offers unified APIs and agent-facing integration infrastructure intended to normalize access across many B2B systems. Agent Handler extends that integration foundation into tools that agents can discover and execute.

What Reddit users consistently praise: Merge Unified, not Agent Handler, has the positive track record. One firsthand user called an ATS deployment solid but warned against using Merge for CRM. An HRIS evaluator said Merge was worth considering for normalized access across multiple providers.

That supports standardized category coverage and maintenance reduction, not deep provider-specific behavior.

What Reddit users complain about: Deep CRM, semantic normalization, pricing, and migration are the failure boundaries. A Salesforce team burned a quarter trying to make custom objects work before switching to a CRM-specific provider. An HRIS evaluator found that Merge normalizes structure but not business meaning, leaving customers to reconcile concepts like multiple definitions of an active employee.

Another user warned that pricing can rise sharply once Merge is embedded and migration costs create sunk-cost pressure.

A customer with several hundred linked accounts said migration would require asking those customers to reauthenticate. A Merge employee responded that credentials can be exported, but OAuth tokens remain tied to the application that issued them. That's partly an OAuth-provider constraint, not something unique to Merge, but the customer migration cost remains real.

A production Workday deployment also reported polling timeouts. The thread didn't isolate the cause. It identified Workday API limits, request breadth, batching and pagination, and timeout configuration as contributing factors.

Hands-on evaluation

What I found when I tested it: Merge delivered the fastest guided first success. Google SSO, connecting GitHub, and executing a request in the web playground took about five minutes.

That success stayed inside Merge's playground. The toolkit URL generated in my test was user-specific, and progressing toward my multitenant gateway required several additional components. I couldn't find a path to one reusable endpoint where different users could authenticate and use the configured tools.

I stopped after 15 minutes because the product wasn't converging on the gateway architecture I was testing.

Recommendation

Who should choose this: Choose Merge Unified when standardized HRIS, ATS, payroll, or similar category coverage matters more than provider-specific depth. Validate Agent Handler separately. Merge Unified's integration record doesn't carry over to it.

Who should avoid this: Teams that require deep provider-specific objects, semantic normalization, predictable pricing at scale, or migration without widespread customer reauthentication. Avoid treating Agent Handler as proven when independent MCP production evidence is a requirement.

Evidence confidence: Hands-on testing was low. In 15 minutes, I could only reach the playground, with no gateway-path convergence. Documentation was medium. The Unified API was well-covered, though Agent Handler’s material was thinner. Independent evidence volume was moderate, with concrete normalization, CRM-depth, pricing, and migration reports for Unified. But I didn’t find an independent Agent Handler deployment report.

Lunar MCPX: open-source MCP gateway that requires hardening

Bottom line: Lunar MCPX has the right open-source primitives for centralized MCP governance, but the available independent reports describe a product that still needs hardening.

Documentation and Reddit evidence

What the company claims: MCPX provides a registry, tool groups, access policy, audit, and a self-hosted gateway for managing multiple MCP servers through one endpoint. It focuses on centralized visibility and selective tool exposure.

What Reddit users consistently praise: The only positive production claim comes from Lunar's co-founder. The independent reports describe setup failures, lost configuration, restarts, and migration away from MCPX.

What Reddit users complain about: The pattern from independent users is setup and stability friction. Reports describe a UI that could not connect to MCPX’s webserver, a container that required constant restarts, and one user who switched to AgentGateway after finding MCPX unstable.

Hands-on evaluation

What I found when I tested it: The identity provider was gated behind an enterprise plan and a sales call. Lunar does offer a locally deployable server that serves as a downstream auth manager, but I couldn't evaluate the full gateway without access to the identity layer.

Recommendation

Who should choose this: Open-source teams willing to test, patch, and operate an early gateway in exchange for control over deployment and policy.

Who should avoid this: Teams that need reliable defaults, mature documentation, or proven production resilience now.

Evidence confidence: Hands-on testing was blocked, since the identity provider was gated behind the enterprise plan. Documentation was low, described as weak by independent users. Independent evidence volume was thin. The sample is small and predominantly negative, and the only positive production claim is founder-authored.

MintMCP: compliance-focused MCP gateway with limited independent evidence

Bottom line: MintMCP has strong compliance positioning and the weakest independent validation in this comparison. Don't shortlist it without customer references and a structured proof of concept.

Documentation and Reddit evidence

What the company claims: MintMCP targets enterprise MCP hosting with SSO, RBAC, virtual servers, monitoring, policy, and audit controls. It's aimed at organizations that need compliance and centralized administration around MCP access.

What Reddit users consistently praise: There's no recurring independent praise pattern. The best independent signal is a sysadmin who built a Cloud Run proxy and said MintMCP would now tempt them. That's purchase consideration, not a deployment result.

What Reddit users complain about: A smaller-team evaluator called it too complex. More important than that single criticism, at least 109 of 112 threads in our research were affiliated or company-authored. The corpus contains zero verified independent deployments, performance tests, or procurement accounts.

Hands-on evaluation

What I found when I tested it: The basic GitHub setup worked end-to-end in about 20 minutes. The onboarding path was straightforward enough to complete without friction.

I couldn't test the identity features (SSO, RBAC, and related controls) because they're behind the Enterprise plan. For a product whose primary positioning is compliance and centralized administration, the core differentiators weren't accessible during evaluation.

Recommendation

Who should choose this: Compliance-focused buyers prepared to run a structured proof of concept and validate claims with customer references.

Who should avoid this: Teams that require community-proven operations, transparent independent benchmarks, or a lightweight deployment.

Evidence confidence: Hands-on testing was medium. The basic GitHub setup was completed in 20 minutes, but the Enterprise pricing tier blocked identity features. Documentation was medium. Product capabilities are covered, but core differentiators are gated by plan. Independent evidence volume was thin. 109 of 112 threads were affiliated or company-authored, with zero verified independent deployments, performance tests, or procurement accounts.

Where MCP gateway claims differ from user experience

Which MCP gateway should you choose for each failure mode?

What Reddit evidence says about MCP gateways

Reddit provides implementation reports, not a reliable measure of independent community sentiment. Disclosed founders, employees, and affiliates can be identified, but undisclosed commercial relationships can't.

Vendor participation is common across this category. Composio has company-authored posts alongside community accusations of stealth marketing. Nango's founder participates frequently in discussions about Nango's product boundaries and MCP's production readiness.

Founder participation isn't inherently misleading, and affiliated posts can contain accurate technical information. But they don't establish independent adoption or satisfaction.

Reports carry the most weight when they describe a concrete architecture, configuration, error, workload, or operational outcome. Repeated patterns, current versions, documentation, and hands-on results increase confidence. Unsupported recommendations and sentiment-only comments carry little weight.

Version and product boundaries change several conclusions:

First, older ContextForge warnings describing it as alpha or unsupported don't represent the current post-1.0 project. Its documented feature set has expanded substantially. No cited report covers current high availability, performance, or operating burden.

Second, AgentCore Gateway isn't interchangeable with AgentCore Runtime, Memory, Policy, Identity, or the older Bedrock Agents product. The reported AgentCore "memory leak" concerns Runtime session lifecycle and billing behavior, not the AgentCore Memory service. One company's use of AgentCore for MCP deployments and agent sandboxes validates a narrow production use case, not every AgentCore service.

Third, the Obot gateway authorization bypass and OAuth metadata SSRF were fixed. Use patched versions and test API authorization and outbound network controls.

Fourth, the Composio security incident isn't Reddit speculation. Composio confirms unauthorized access, 5,001 compromised GitHub connections, about 0.3 percent of active connections leaked, and 5,241 API keys sitting in an auxiliary cache the attacker likely accessed. These incident facts come from Composio's official report.

Fifth, Reddit discussions frequently collapse Kong's traditional API gateway, AI Gateway, and MCP-specific plugins into a single product reputation. The corpus contains no MCP-specific production validation.

Finally, open source doesn't mean operationally free. ContextForge, Obot, Lunar MCPX, Docker's headless gateway, and self-hosted Nango still require some combination of databases, Kubernetes, upgrades, monitoring, security hardening, and incident ownership. No software-license fee doesn't mean no platform-engineering cost.

Common mistakes when choosing an MCP gateway

• Choosing integration count instead of measuring whether an agent can actually use the tool schema reliably.

• Treating server authentication as if it solved downstream per-user authorization.

• Selecting a desktop abstraction for a remote, multi-user production topology.

• Assuming open source removes database, Kubernetes, upgrade, and incident ownership.

• Waiting until security review to add credential isolation, tool-level policy, and attributable audit logs.

• Ignoring migration until hundreds of customers must reconnect OAuth accounts.

• Accepting vendor latency, token, or detection benchmarks without reproducing the workload.

• Buying an integrated agent platform when a direct MCP connection or a single-purpose gateway would solve the problem with fewer IAM, networking, observability, and billing surfaces.

• Treating apparently unaffiliated Reddit comments as verified independent evidence.

MCP gateway research limitations and disclosures

Reddit overrepresents failures and underrepresents quiet enterprise deployments. Search coverage is incomplete, and names like Lunar, Merge, and ContextForge generate false positives.

The ten hands-on evaluations measured onboarding and architectural fit, not production load, failover, token expiry, revocation, cost at scale, audit completeness, or security. Of the ten, only Arcade actually connected to Claude Code. I stopped Merge, Nango, Kong, and Obot when their setup or architecture diverged from the target, while TrueFoundry's identity provider setup failed with configuration errors after the basic test completed. Enterprise pricing tiers gated MintMCP's and Lunar MCPX's identity features, and Docker required a sales form to access. AgentCore and ContextForge fell outside the test’s scope, since they required setting up infrastructure on AWS and self-hosted deployments, respectively.

Commercial disclosure: My company, Zenith, provides content marketing services to Arcade and previously worked with Composio. The product testing, Reddit research, comparisons, and conclusions are my own.

I'll update this article as products change and as more reproducible hands-on and production results become available. If you've run one of these gateways in production, share the topology, version, traffic level, failure mode, and migration outcome in the comments. That's the evidence this category needs.

Frequently asked questions about MCP gateways

What is an MCP gateway?

An MCP gateway is a control layer between MCP clients and one or more MCP servers. It centralizes routing, authentication, tool permissions, credentials, observability, and audit logs.

What is the difference between an MCP gateway and an MCP server?

An MCP server exposes tools, resources, and prompts to AI applications. An MCP gateway sits between clients and servers to aggregate connections, authenticate users, enforce policy, and record activity.

Do I need an MCP gateway?

Use an MCP gateway when multiple users, agents, clients, or servers require shared authentication, permissions, and auditing. A direct MCP server connection is enough for a single-user local workflow.

What is the best MCP gateway in 2026?

Arcade is the best MCP gateway for custom, multitenant B2B applications in this comparison. Docker MCP Gateway is the best local development option, while Amazon Bedrock AgentCore fits teams already operating on AWS.

What is the best open-source MCP gateway?

Docker MCP Gateway is the best open-source option for local development and shared desktop clients. IBM ContextForge targets self-hosted enterprise federation but requires more infrastructure and platform ownership.

What is the best MCP gateway for enterprise AI agents?

Arcade is the strongest fit for delegated authentication, tool-level policy, custom MCP servers, self-hosting, and air-gapped deployment. Amazon Bedrock AgentCore fits enterprises standardized on AWS IAM, CloudTrail, CloudWatch, and Lambda.

How does an MCP gateway improve security?

An MCP gateway centralizes user authentication, credential isolation, tool permissions, rate limits, and audit logs. It limits which users and agents can call each tool, but it does not make an insecure MCP server safe.

Can an MCP gateway be self-hosted?

Yes. Arcade supports self-hosted and air-gapped deployments. IBM ContextForge, Docker MCP Gateway, Obot, and Lunar MCPX also provide self-hosted options, with different requirements for identity, policy, monitoring, and maintenance.