“MCP gateway” is now used for products that solve different problems. Treating them as interchangeable leads to bad architecture decisions and misleading comparisons.
The useful split is:
- Integration gateway — a catalog of managed SaaS connectors, often with third-party OAuth brokerage.
- Aggregation gateway — one stable MCP endpoint that combines tools from several MCP servers.
- Hosting/runtime platform — the infrastructure that runs each MCP server process.
MCPLambda provides the second and third layers: deploy and operate your servers, then optionally combine selected deployments behind an MCPLambda Gateway.
The three-layer map
AI host (Claude, Cursor, VS Code, custom agent)
│
├─► Aggregation Gateway ─► hosted MCP server A ─► your systems
│ ├► hosted MCP server B ─► your systems
│ └► hosted MCP server C ─► your systems
│
└─► Integration gateway ─► managed SaaS connectors ─► Slack, CRM, emailMCP itself defines hosts, clients, servers, and transports (architecture). It does not require a catalog, aggregation layer, or hosting PaaS. Those are product capabilities built around the protocol.
1. What an integration gateway optimizes
An integration gateway reduces the work of connecting agents to many commodity SaaS products. Capabilities vary, but this product class often includes:
- A large catalog of prebuilt SaaS actions
- Managed OAuth and token refresh for third-party products
- Organization policies for connector access
- Central audit of calls across managed connectors
You usually do not build and operate the Slack, Gmail, or CRM server yourself. The product’s leverage is the connector catalog and credential lifecycle.
That leverage also creates an important security boundary. If a gateway acts as an OAuth proxy to third parties, MCP Security Best Practices describe confused-deputy risks and require careful consent, redirect URI validation, and state handling. Token passthrough is also forbidden: a token must be issued for the audience that receives it.
Use this layer when the hard problem is maintaining many third-party integrations, not running your own server code.
2. What an aggregation gateway optimizes
An aggregation gateway solves client configuration sprawl. Without one, every agent or developer may need a separate URL and access setup for repository tools, internal search, ticketing, deployments, and other MCP servers.
An aggregation gateway presents those servers through one MCP endpoint. The benefits are operational:
- One URL in each client configuration
- One access policy at the combined endpoint
- A centrally managed tool surface
- Member changes without changing the client-facing URL
- A clear place to prevent tool-name collisions
The aggregation layer does not automatically create SaaS integrations or manage the credentials an underlying server needs. If a member deployment calls Slack, that deployment still needs the appropriate Slack authorization unless another product layer provides it.
How MCPLambda Gateway behaves
MCPLambda Gateway combines tools from up to 20 running deployments in the same project behind one stable URL.
- Choose OAuth, an expiring API key, or public access for the Gateway.
- Add or remove member deployments without changing the URL.
- Tool names are automatically prefixed by deployment to avoid collisions.
- Membership updates briefly reconnect the Gateway, so clients may need to refresh tool discovery.
- Stopping or deleting the Gateway does not stop or delete its member deployments.
- Each deployment remains independently manageable, with its own logs, analytics, secrets, scaling, and direct endpoint.
Gateway OAuth authenticates the MCP client to MCPLambda. It is not third-party SaaS OAuth brokerage. That distinction is essential when evaluating MCPLambda against connector-catalog products.
3. What hosting optimizes
Hosting is the runtime layer for server code you own or choose to deploy:
- Deploy a Git repository, Docker image, or package
- Isolate the runtime and inject secrets
- Stream logs and monitor health
- Inspect tool usage and latency
- Version, scale, stop, and replace each server independently
You implement tools, resources, and prompts according to MCP server concepts and apply the security considerations for tools.
For remote servers, current MCP transports define Streamable HTTP; legacy HTTP+SSE may still matter for compatibility (transports).
Use hosting when your product logic, private APIs, data boundaries, or release process are the hard part.
Decision table
| Bottleneck | Prefer |
|---|---|
| “We need managed Gmail, Slack, and CRM actions tomorrow” | Integration gateway |
| “Every client has six MCP URLs and credentials” | Aggregation gateway |
| “Our product logic is the tool” | Hosting/runtime platform |
| “Third-party OAuth for dozens of vendors is the project” | Integration gateway |
| “We need one governed endpoint for selected internal tools” | Aggregation gateway |
| “We need Git deploys, logs, analytics, and lifecycle control for our code” | Hosting/runtime platform |
| “We need all three outcomes” | Use the layers together with explicit ownership |
Worked scenario: one agent, three ownership models
An engineering assistant needs to:
- Read issues from a commodity SaaS tracker.
- Query a proprietary billing database through company-owned logic.
- Trigger an internal deployment workflow.
The SaaS tracker may come from an integration gateway that owns the vendor OAuth lifecycle. The billing and deployment tools are hosted MCP servers because the company owns their code and data boundaries. An aggregation gateway can then expose the two hosted deployments through one stable endpoint for the engineering assistant.
The important work is not choosing one vendor label. It is assigning ownership:
- Who refreshes the SaaS token?
- Who deploys and rolls back the billing server?
- Who controls which hosted deployments enter the combined endpoint?
- Which logs answer whether a failure came from the client, Gateway, member deployment, or upstream API?
Those answers turn a pile of “MCP tools” into an operable system.
Architecture checklist
- Classify each requirement as managed integration, aggregation, or runtime hosting
- Use an integration gateway when third-party connector and OAuth maintenance is the bottleneck
- Host custom MCP servers for proprietary logic and private APIs
- Use an aggregation Gateway when clients need one stable, governed endpoint
- Document whether auth protects the Gateway, the member server, or an upstream SaaS API
- Give each tool one primary implementation path and owner
- Decide where operators look first for tool, runtime, and upstream failures
- Keep the combined toolset focused enough for clients and users to understand
Failure modes
| Failure | Likely cause | Fix |
|---|---|---|
| Rebuilding Gmail OAuth internally | DIY commodity integration | Use a managed integration connector |
| Six MCP entries in every developer client | No aggregation layer | Put the relevant servers behind one Gateway |
| Proprietary logic trapped in brittle connector glue | Wrong ownership layer | Host a custom MCP server |
| “OAuth enabled” but upstream SaaS still fails | Gateway auth confused with SaaS auth | Configure both boundaries explicitly |
| Duplicate tools with different behavior | Two layers own the same capability | Choose one primary path and deprecate the other |
| Nobody knows where to debug a failed call | Layer boundaries are undocumented | Define logs, alerts, and owners per layer |
MCPLambda and integration-gateway products
MCPLambda is a hosting and aggregation control plane: run MCP servers, operate them independently, and combine selected deployments behind one Gateway URL.
Composio-class products are primarily integration control planes: their differentiator is a catalog of managed app connections and authentication. See MCPLambda vs Composio for that product-level comparison.
Many teams can use both. A managed integration product can cover commodity SaaS actions while MCPLambda hosts proprietary servers and aggregates the deployments that should appear together. Do not force one layer to imitate another; make the boundary explicit.
Takeaways
- “Gateway” is not a sufficient architecture description. Ask whether the product manages SaaS integrations, aggregates MCP servers, hosts server runtimes, or combines those capabilities.
- MCPLambda Gateway is an aggregation layer. It gives clients one stable URL and Gateway-wide access control for multiple MCPLambda deployments.
- Authentication exists at multiple boundaries. Client-to-Gateway OAuth is different from the credentials a member server uses for an upstream SaaS API.
- The layers work well together when ownership is explicit. Pick the right owner for connectors, server code, aggregation, and incidents.
Sources
- Architecture overview
- Security Best Practices — confused deputy and token passthrough
- Authorization — 2025-11-25
- Transports — 2025-11-25
- Server concepts
- Tools security considerations
Next steps
Explore MCPLambda Gateway · Catalog vs BYO · Internal tools · Managed vs build-your-own
