Plexara
What gateways do well
MCP gateway products solve real infrastructure problems. They provide authentication and authorization for MCP traffic, routing tool calls to the correct backend server, rate limiting to prevent abuse, and observability into what agents are doing. Several well-funded startups have raised significant seed rounds building gateway products, and some have signed major enterprise accounts within months.
The narrative is compelling and simple: gateways are "the Okta for AI agents." Enterprises need a control plane for MCP traffic, and gateways provide it. SOC 2 Type II certification, enterprise SSO integration, and usage dashboards make the products easy to evaluate and procure.
These are legitimate capabilities. Every enterprise deploying MCP agents at scale needs authentication, routing, and observability. The question is not whether gateways are useful but whether they are sufficient.
Layers of the stack
Layer 03
L7 / intelligence
Context enrichment
Reads the content of tool responses, correlates across services, enriches with business meaning
Layer 02
L7 / intelligence
Session awareness
Knows which entities have been discussed, dedupes metadata, tracks workflow compliance
Layer 01
L4 / transport
Gateway (auth, routing, rate limit, obs)
Sees payloads as opaque. Knows the tool was called. Cannot know what the data means.
What gateways cannot do
A gateway sees tool calls as opaque payloads. It knows that an agent called a tool named "describe_table" with a parameter "table_name." It authenticated the request, routed it to the correct MCP server, and logged the result. It does not know what the table contains, who owns it, whether it is deprecated, or how it connects to other datasets.
A gateway cannot enrich the response with business context. When an agent queries a table through a gateway, the gateway passes the request through and returns the response unchanged. The agent still has no idea what the columns mean, whether the data is PII-classified, or what glossary terms apply. The response is as context-free leaving the gateway as it was entering.
A gateway cannot correlate across services. It routes to the query engine or the catalog independently. It does not know that the table being queried in one call is the same entity being described in another. Cross-service correlation, the foundation of semantic enrichment, is architecturally impossible at the gateway layer.
What the gateway sees
Gateway view
POST /mcp HTTP/1.1
Authorization: Bearer ***
X-Persona: analyst
{"tool": "describe_table",
"params": {"table": "txn_detail"}}
... opaque bytes ...routed · authenticated · logged
Plexara view
- txn_detail is PII-classified; analyst persona may read
- amt column is cents, deprecated for net_amt
- Quality score 0.94; last refresh 2 hours ago
- Dedup: full context sent once per session
Infrastructure layer, not data intelligence layer
The distinction matters because the problems enterprises face with AI data access are not routing problems. They are context problems. An agent that can authenticate and reach a database but cannot understand what the data means will generate inaccurate queries. No amount of gateway sophistication changes this.
Gateways operate at the transport layer. They manage connections, credentials, and traffic. Semantic enrichment operates at the application layer. It understands the content of tool responses and augments them with business meaning. These are different layers of the stack, and conflating them leads to architectures that are well-plumbed but contextually impoverished.
This is not a criticism of gateway products. It is a clarification of scope. A gateway is to MCP what a load balancer is to HTTP: necessary infrastructure that does not replace the application logic behind it.
A gateway is to MCP what a load balancer is to HTTP: necessary infrastructure that does not replace the application logic behind it.
The commoditization trajectory
Gateway features are commoditizing rapidly. Every major cloud provider is adding MCP routing and authentication to their existing API gateway products. Enterprise identity platforms are extending their agent governance features to cover MCP traffic. The standalone gateway category will face the same competitive pressure that standalone API gateways faced a decade ago.
SOC 2 Type II certification, once a differentiator, is becoming table stakes. Enterprise SSO integration is a feature, not a product. Rate limiting and observability are infrastructure capabilities that cloud platforms absorb naturally. The competitive moat around gateway features is shallow and getting shallower.
Context enrichment, by contrast, requires deep integration between query engines, metadata catalogs, and enrichment pipelines. It cannot be bolted on at the transport layer. The competitive moat around context is architectural: it requires controlling both the execution and the metadata, which gateway-only products do not.
Commoditization trajectory
Gateway moat depth: heading to zero
Where the layers meet
Plexara and MCP gateways operate at different layers of the stack. A gateway manages MCP traffic. Plexara enriches it with business context. In theory, they are complementary. In practice, most gateway value is subsumed by a platform that already handles authentication, authorization, audit logging, and routing internally.
An enterprise deploying Plexara gets gateway-level capabilities (authentication, persona-based access control, audit logging, connection routing) as built-in features of the platform. Adding a separate gateway in front of Plexara adds infrastructure complexity without adding context. The gateway sees Plexara as another MCP server to route to, unaware of the enrichment happening inside.
The strategic question for enterprises is whether to invest in infrastructure that routes context-free traffic or in a platform that enriches every response with business meaning. Gateways solve the plumbing. The question is whether your AI agents need plumbing or intelligence.