On September 11, SberTech described MCP Gateway, a centralized gateway intended to connect enterprise AI agents to approved tools, resources and existing APIs. The proposed architecture targets organizations seeking common access policies, agent activity auditing and automated configuration through Platform V Synapse products.
The design has three main elements. MCP Gateway gives agents one entry point and an aggregated list of permitted tools and resources. According to SberTech, deploying it within gateways managed by Synapse Service Mesh provides decentralization, scalability, management and observability. Synapse API Mesh automates gateway configuration according to an organization’s processes and registries.
Clients send MCP requests to a single endpoint over an agreed port and the standard /mcp path. The gateway identifies the requested tool or resource, applies configured authorization policies, routes execution to the relevant external system and returns the result. Its external interface is a standard MCP server supporting tools and resources; SberTech selected HTTP Streamable for remote client communication.
The gateway can virtualize corporate interfaces by exposing a REST API as an MCP tool and translating requests and responses between REST and MCP. SberTech says the same approach can cover gRPC when messages can be translated unambiguously. A large API may also be presented as several specialized tools, each with its own description and reduced request and response schemas.
MCP Gateway functionality is built into Envoy proxy and enabled only by specific settings, which the company says leaves other traffic processing unaffected. Management through Synapse Service Mesh adds mutual TLS, JWT validation, external authorization and policies down to individual tools, resources and MCP JSON-RPC methods. Envoy also supplies rate limiting and Secret Discovery Service, while logs, metrics and Jaeger or Zipkin distributed tracing support observability.
Automatic OpenAPI translation has limitations. An MCP tool output schema cannot represent multiple response variants in the same way as a REST API, so developers must select one schema or expose one API as multiple tools. OpenAPI examples also lack a direct MCP field: they can be added to the description or placed in _meta, but the latter requires extending the MCP client library.
Practical context: In practice, this structure can move routing, access policies, secrets and telemetry out of individual agent code and into the infrastructure layer. Organizations assessing it should separately test their APIs’ compatibility, schema quality and policy behavior under production workloads, because the stated architectural benefits are presented by the solution’s developer.
| Requirement | Practical meaning | Example risk |
|---|---|---|
| Descriptions of methods and required parameters | Specify each field’s purpose, format and permitted values | The model selects the wrong language or parameter format |
| Response size limits | Add filters, sorting and result limits | Excess data displaces useful context |
| Simplified data schema | Reduce structures and split complex operations into sequences | The model struggles with oneOf, allOf and technical identifiers |
| Current specification | Keep the API description synchronized with the actual contract | A call fails because a required parameter is absent from the schema |
MCP Gateway deployment options
SberTech describes three options: an edge gateway in the AI agent’s namespace, a separate centralized installation, or deployment as a DaemonSet. Envoy with MCP Gateway functionality is managed through Platform V Synapse Service Mesh.
Scaling and resilience mechanisms
The company links horizontal scaling to placing MCP Gateway inside the proxy. Envoy provides circuit breaking, retry policies and timeouts to prevent cascading failures.
Sources
Event date: 2026-09-11. Primary source date: 2026-09-11.
