MCP gateway: connect once, scope every agent

An MCP gateway sits between AI clients and external tools, bringing connections, authentication and access rules into one place. AIPx is a hosted MCP gateway for an individual developer: connect service accounts once, then give each agent its own scoped URL. Free supports three accounts and one agent; Pro costs $3 per month without running gateway infrastructure yourself.

What is an MCP gateway

A gateway presents tools from connected systems through an endpoint that an MCP client can use. It can decide which upstream connection receives a call and which operations the authenticated agent may discover or execute. The client still drives the conversation, and each upstream service still enforces its own account permissions.

Consider a bug-fix workflow involving a tracker, GitHub and an error system. Without a shared connection layer, each coding client needs its own server configuration and authentication setup. A gateway can keep the account connections together and expose a narrower tool set to the coding agent. Another agent can use those accounts with different rules.

The useful boundary is not “all my services in one URL.” It is “the right account operations for this task.” A general-purpose endpoint that exposes every operation creates a larger review burden. Decide the permission set first, then configure the client to use it.

MCP gateway vs MCP server

A server implements MCP capabilities and exposes operations. A gateway adds a connection and policy layer over one or more upstream systems, while presenting a server interface to the client. Those roles can overlap in one implementation.

Question	Individual MCP server	MCP gateway
What does the client see?	The server’s capabilities and tools	A permitted collection of upstream tools
Where does a call execute?	In the server or the service it wraps	In the selected upstream integration
What is configured?	That server’s endpoint or launch command	Connections, routing and access policy
Account separation	Depends on the server	Can be managed across connected accounts
Best fit	One service or a custom local tool	Several systems with shared access rules

A gateway does not automatically support every protocol extension of an upstream server. AIPx exposes its supported tool interface and currently implements MCP wire versions 2026-07-28 and legacy 2025-06-18. It does not request sampling or elicitation. Evaluate the capabilities your client and workflow require rather than assuming a completely transparent bridge.

For the server’s role, read what an MCP server is. For hosting choices, see remote MCP servers.

MCP gateway vs MCP proxy, hub and router

These terms often describe overlapping product features, rather than separate normative network roles in the MCP specification. Read what the implementation does instead of treating its name as a capability guarantee.

Term	Usual emphasis	Question to ask
MCP proxy	Forwarding calls between endpoints	Does it also filter tools and enforce policy?
MCP hub	Collecting connections or discovery	Is it a directory, a runtime, or both?
MCP router	Choosing an upstream destination	How does routing preserve account identity?
MCP gateway	A shared connection and policy boundary	Which authentication and permission controls exist?

A proxy that forwards a token unchanged is not the same as a gateway that authenticates the client and separately authorizes upstream connections. A directory may help find servers without handling any calls. A router may select an endpoint without asking whether the agent should be able to use its destructive operations.

For AIPx, the product boundary is connected accounts, agent-specific endpoints, per-tool permissions and a shared audit. It is not a claim to replace every API platform feature. In particular, adding an existing public MCP server differs from uploading an arbitrary API specification; the API-to-MCP guide explains the available routes.

Open-source vs hosted MCP gateways

The deployment choice depends on where the tools live and who should operate the gateway. A developer working with private local files has different needs from an organization already routing APIs through an enterprise platform.

Option	Deployment and emphasis	When it fits	Cost boundary
Docker MCP Gateway	Local container-based server runtime and connection management	You want control over local server execution and isolation	Runtime, infrastructure and service costs remain yours
Kong AI MCP Proxy	Gateway policy and managed HTTP/MCP integration	Your APIs already run through a Kong platform	Product edition and infrastructure determine cost
Microsoft Azure API Management	Managed REST-to-MCP and existing MCP exposure	Your organization already operates APIM	Azure resources and configuration apply
AIPx	Hosted service accounts and agent-level tool rules	One developer wants multiple accounts without managing a gateway	Free or $3/month, plus upstream service costs

Docker’s MCP Gateway documentation explains its local container approach. Kong documents its AI MCP Proxy, and Microsoft describes MCP server support in API Management. Compare those documented deployment models, rather than assuming their product names mean the same thing.

Choose a self-managed or privately deployed gateway when network placement, infrastructure control or organizational policy requires it. Choose an existing API platform when your team already depends on its operational controls. AIPx is not a Kubernetes policy platform and does not promise enterprise compliance, an SLA or a private deployment option.

If your task is building integrations into a product rather than connecting your own accounts, compare Composio. If your priority is workflow automation in a broader app ecosystem, compare Zapier MCP. The right choice starts with that operating model, not with a tool-count comparison.

Per-tool permissions, multiple accounts and an audit log

AIPx applies Allow, Confirm and Hide to a tool, connected account and agent. Allow and Confirm communicate execution hints, with Confirm requesting client approval. Actual review depends on the client; Hide is enforced server-side and withholds access. Two accounts of the same service can have different rules, and another agent can receive a different view of those same accounts.

For example, let a development agent read the work tracker, confirm issue updates and hide the personal mailbox. Treat read access as a confidentiality decision: private documents can be disclosed even when no data is modified. Client permission prompts remain an additional layer.

The audit records the agent, tool, account, parameters, result and time. It helps answer which connection supplied information or executed a change across clients. It is not a promise of unlimited retention, SIEM export or transaction rollback. The MCP access-control guide provides the detailed matrix and review process.

How AIPx works

1. Connect the service accounts

Choose an integration from the supported catalog and complete its documented connection method. Depending on the service, that can involve OAuth, an API credential or a specific account setup. Connect separate work and personal accounts separately so the permission layer can distinguish them.

AIPx also accepts the public URL of an existing custom MCP server. That server must already exist and be reachable. This is not hosting for a local stdio process, a Docker image or arbitrary source code.

2. Create an agent and review its tools

Create an agent around a task or project. Review the discovered operations and decide which accounts it needs. Keep writes on Confirm initially, hide unrelated capabilities, and inspect sensitive reads instead of accepting every default.

Free provides one agent; Pro supports separate agents for separate workflows. Using distinct agents is particularly useful when the coding assistant and personal planning assistant should not receive the same account information.

3. Add the endpoint to the client

Copy the URL shown for the agent:

https://dash.aipx.run/mcp/AGENT_ID

Authenticate the client through OAuth. The endpoint identifier is not an access token; the client authorization and upstream account authorizations are separate. The MCP OAuth guide explains that distinction.

Follow the client’s actual setup: Claude’s connector interface, Claude Code’s HTTP command, Codex’s TOML configuration or Cursor’s JSON configuration. Run a narrow read and inspect the audit before trying a write. The server selection guide helps choose the first useful services.

MCP gateway pricing

AIPx plan	Connected accounts	Agents	Price
Free	Up to 3	1	$0
Pro	Unlimited	Unlimited	$3/month

Pro also includes Pro integrations. These limits describe AIPx accounts and agents; they do not promise unlimited upstream API requests or include subscriptions to the connected services. Check the pricing page for current plan details and billing information.

For a developer using one coding client with a tracker, GitHub and Sentry, Free can cover a useful initial boundary. When work and personal workflows need distinct agents or more connected accounts, Pro removes those limits. The price is for the gateway layer rather than for the upstream products.

When a gateway adds little value

A single direct vendor server may be enough when you use one account in one client. Local tools are a better fit when the server must inspect files or a system only reachable from your private environment. AIPx adds another operator to trust and depends on network and provider availability.

Use the gateway when shared account connections and differing agent permissions solve an actual configuration problem. Begin with a tool set you can explain, then widen it after reviewing real calls. Connect free.