MCP без хаоса: как мы создали в корпоративном ландшафте централизованный шлюз для ИИ‑агентов

Привет, Хабр! Меня зовут Анастасия Трегубова, я архитектор продукта Platform V Synapse API Mesh в СберТехе. Хочу поделиться идеями по работе с агентскими инструментами и внедрением протокола МСР в корпоративном ландшафте. Расскажу, как мы обеспечиваем централизацию, но обходим узкие места, и как линейка продуктов платформы Synapse сокращает этот путь. Надеюсь, что вы сможете почерпнуть из статье идеи для решения аналогичных задач.

MCP: почему мы выбрали этот протокол

Протокол МСР сейчас (в 2026 году) де факто является отраслевым стандартом для подключения внешних агентских инструментов. Широкое распространение и зрелость протокола подтверждаются успешным развёртыванием тысяч серверов и его глубокой интеграцией в SDK и инструменты разработчиков.

Ключевым событием, укрепившим позиции MCP, стала передача проекта в руки некоммерческого сообщества: 9 декабря 2025 года компания Anthropic передала его в Agentic AI Foundation (AAIF) под эгидой Linux Foundation. Несмотря на слухи и спекуляции о том, что «MCP мёртв», после появления подхода с поддержкой навыков (skills) от того же Anthropic протокол остаётся на пике популярности. С появлением поддержки задач (tasks) он даже ставит под сомнение необходимость использования межагентcкого протокола A2A для большинства сценариев.

Три главных боли при работе с агентскими инструментами

ИИ‑агент в корпоративном ландшафте не может использовать любой МСР‑сервер или внешний инструмент по своему выбору. Нужен контроль используемых инструментов, а также подключение к корпоративным процессам выдачи прав доступа и авторизации.

1. Важно обеспечивать наблюдаемость агентской активности, в том числе связанной с вызываемыми инструментами, чтобы предотвратить возможный взлом, галлюцинации или неправомерные действия агента.

   Это особенно важно для критичных агентов, когда в случае инцидента, например, финансовой ошибки, компания может понести материальные и репутационные убытки. Наблюдаемость позволяет восстановить всю цепочку событий: каким был исходный запрос пользователя, какое решение принял агент и какие инструменты, параметры или ответы использовал.

2. Сложность внедрения новых инструментов:

• ИИ‑агент имеет только те инструменты, которые ему заложили при создании, и не может подключить новые на лету. Автономным агентам нужно динамически обнаруживать (discovery) новые разрешённые инструменты и подключать их без полноценного релиза.

• В большой компании разные отделы могут создавать инструменты с одинаковыми названиями, но разной логикой, из‑за чего возникают конфликты имён, которые важно уметь разрешать.

• Разные МСР‑серверы или внешние инструменты используют разные средства авторизации, поэтому нужен контроль за используемыми секретами.

• ИИ‑агенты требуют отдельного подключения к каждому MCP‑серверу, поэтому нужна конфигурация каждого нового подключения и кодинга агента.

• Если делать единый реестр инструментов, к которому при выполнении будут обращаться агенты, то возникает единая точка отказа. Если реестр выйдет из строя, работа всех агентов в компании будет парализована. Нужна сложная схема отказоустойчивости.

  3. Создание MCP‑сервера для каждого инструмента удорожает внедрение ИИ‑агентов в ИТ‑ландшафт.

  Нужна возможность подключать существующие API в качестве инструментов ИИ‑агента.

Наше решение: MCP Gateway

Чтобы упростить ИИ‑агентам подключение инструментов, мы решили предложить подход с MCP Gateway. Мы не первые, кто его реализует на рынке, но одни из первых, кто делает это в интеграции с Service Mesh и с автоматизацией настройки.

У решения три основных составляющих:

1. Функциональность самого MCP Gateway, который должен обеспечить ИИ‑агентам единую точку входа для всех MCP‑взаимодействий, поставляя агрегированный список всех разрешённых к использованию инструментов (tools) и ресурсов (resources).

2. Развёртывание MCP Gateway в составе шлюзов под управлением Service Mesh. Это даёт децентрализацию и масштабируемость, а ещё — автоматически — все возможности управляемости и наблюдаемости от Service Mesh.

3. Автоматизация конфигураций через Synapse API Mesh, которая поможет настроить подобные шлюзы для всех ИИ‑агентов в организации согласно процессам и реестрам.

Архитектура MCP Gateway: маршрутизация и виртуализация

MCP Gateway — это шлюз с реестром для управления доступом ИИ‑агентов к инструментам и ресурсам (данным). Он обеспечивает безопасное, масштабируемое и управляемое взаимодействие между ИИ‑агентами и корпоративными системами.

Преимущества связки MCP Gateway + Service Mesh

Единый доступ и маршрутизация

Шлюз выступает единой точкой входа для всех МСР‑взаимодействий, обеспечивая динамическую маршрутизацию запросов.

Клиенты отправляют запросы MCP на единый endpoint — например, адрес своего граничного шлюза — по заранее оговоренному порту и стандартному пути — «/mcp». Шлюз анализирует вызов инструмента или ресурса в запросе и авторизует его согласно переданным ему политикам. Далее, основываясь на определении инструмента или ресурса, шлюз перенаправляет выполнение на соответствующую внешнюю систему, которая его реализует. Результаты возвращаются через шлюз обратно клиенту.

Виртуализация инструментов

MCP Gateway позволяет преобразовывать REST API в MCP‑совместимые инструменты, выставлять их в списке инструментов и преобразовывать запросы и ответы REST <-> MCP при вызове. Можно использовать и другой прикладной протокол, например, gRPC, формат сообщений которого можно однозначно транслировать в МСР.

Для сложных преобразований можно брать специальные адаптеры, которые должны быть представлены соответствующими МСР‑серверами.

Также важна возможность в зависимости от сценария выставить один API как разные инструменты с опцией дополнительного описания и урезания схемы запросаи ответа под каждый вариант использования. Это даёт конкретные инструменты для вызова LLM и уменьшает галлюцинации по сравнению с тем, как если бы в качестве инструмента был выставлен один большой универсальный API.

Пример трансляции OpenAPI в описание МСР‑инструмента:

openapi: 3.0.3
info:
  title: Weather Forecast API
  version: 1.0.0
paths:
  /forecast:
    get:
      summary: Получить прогноз погоды
      parameters:
	    - name: requestUuid
          in: header
          description: Уникальный идентификатор запроса
          required: true
          schema:
            type: string
            format: uuid
          example: "e1fe1bba-bb73-466c-b06a-e242c04cfc48"
        - name: city
          in: query
          description: Город для получения прогноза
          required: true
          schema:
            type: string
        - name: units
          in: query
          description: Единицы измерения температуры
          required: true
          schema:
            type: string
            enum: [celsius, fahrenheit]
      responses:
        '200':
          description: Прогноз погоды
          content:
            application/json:
              schema:
                type: object
                properties:
                  temperature:
                    type: number
                    format: float
                    description: Температура воздуха
                  humidity:
                    type: integer
                    description: Влажность воздуха (%)
                  wind_speed:
                    type: number
                    format: float
                    description: Скорость ветра (м/с).

{
  "tools": [
    {
      "name": "forecast",
      "description": "Получить прогноз погоды",
      "inputSchema": {
		  "type": "object",
		  "properties": {
			"headers": {
			  "type": "object",
			  "properties": {
				"requestUuid": {
				  "type": "string",
				  "format": "uuid",
				  "description": "Уникальный идентификатор запроса"
				}
			  },
			  "required": ["requestUuid"]
			},
			"query": {
			  "type": "object",
			  "properties": {
				"city": {
				  "type": "string",
				  "description": "Город для получения прогноза"
				},
				"units": {
				  "type": "string",
				  "enum": ["celsius", "fahrenheit"],
				  "description": "Единицы измерения температуры"
				}
			  },
			  "required": ["city"]
			}
		  }
		},
      "outputSchema": {
        "type": "object",
        "properties": {
          "temperature": {
            "type": "number",
            "description": "Температура воздуха"
          },
          "humidity": {
            "type": "integer",
            "description": "Влажность воздуха (%)."
          },
          "wind_speed": {
            "type": "number",
            "description": "Скорость ветра (м/c)."
          }
        }
      }
    }
  ]
}

Есть некоторые ограничения такой трансляции:

• В output‑схеме МСР‑инструмента и в output схеме в вызове функций в LLM нельзя указать больше, чем один вариант ответа. При этом в REST API могут быть описаны несколько схем успешных ответов с разными кодами, а также коды ошибок, но для LLM приходится оставлять только одну схему и один код. Описание кодов ошибок можно в каком‑то виде добавлять в описание инструмента, а при наличии нескольких вариантов успешного ответа выставлять один API под разными инструментами с разным описанием.

• Если API имеет примеры в examples, то они будут опущены при трансляции, так как нет соответствующих полей в МСР. Здесь мы видим два решения:

  • Вставлять примеры в описание функции, тогда они попадут в описание инструмента, но это не очень красиво.

  • На стороне транслятора (такого, как MCP Gateway) переносить примеры в поле _meta в ответе. Но для обработки этой дополнительной информации придётся расширять библиотеку МСР клиента и корректно передавать её в LLM, например в поле few_shot_examples в вызове функций Gigachat LLM.

Подключение к существующему корпоративному ландшафту

Виртуализация инструментов позволяет не реализовывать MCP‑сервер, а подключать к агенту существующие API систем: выставить LLM‑ready API, и MCP Gateway преобразует протокол. Но далеко не каждый API можно подключить к агенту.

Каким должно быть LLM‑ready API или AI‑ready API

Строгих стандартов нет — описание API должно быть машиночитаемым и достаточным для того, чтобы LLM могла:

• выделить его из списка предоставленных как решающее определённую задачу;

• корректно заполнить параметры вызова;

• корректно обработать данные в ответе, чтобы обогатить ими свой контекст.

Мы вывели для себя несколько рекомендаций, которые помогут минимизировать галлюцинации и ложные вызовы таких API. Рекомендации представлены в виде MCP‑инструментов со стороны LLM.

Внешний интерфейс MCP Gateway

MCP Gateway имеет внешний интерфейс в виде стандартного MCP‑сервера с поддержкой инструментов и ресурсов. Можно добавить и поддержку шаблонов промптов, но есть мнение, что они мало распространены среди существующих МСР‑серверов.

В качестве транспорта мы выбрали HTTP Streamable, так как это единственная стандартизированная опция для взаимодействия с внешними клиентами. Stdio можно использовать фактически только для локальных клиентов, а другие протоколы требуют кастомной поддержки на клиенте. Поддерживается механизм МСР‑сессий, о котором расскажем ниже.

Расширение Envoy proxy и управление через Service Mesh

Функциональность MCP Gateway нативно встроена в Envoy proxy и включается только при определённых настройках, не затрагивая обработку остального трафика.

Зарубежный аналог расширения Envoy.

Сам Envoy proxy управляется Platform V Synapse Service Mesh — преемником Istio. Можно развернуть прокси с MCP Gateway как граничный шлюз в namespace ИИ‑агента, а можно сделать и отдельную централизованную инсталляцию в отдельном namespace. Также можно развернуть в виде DeamonSet.

Что даёт интеграция MCP Gateway в Envoy proxy и управление Synapse Service Mesh:

Безопасность и управление доступом

Аутентификация и авторизация:

• Envoy обеспечивает взаимное TLS‑шифрование (mTLS) между MCP Gateway и клиентом и между MCP Gateway и сторонней системой.

• Service Mesh позволяет настраивать политики доступа, а также проверку подлинности запросов с помощью JWT. Расширенные политики доступа работают до уровня инструментов и ресурсов и JSON‑RPC-методов МСР.

• Envoy применяет политики доступа, обрабатывая не только заголовки, но и тело сообщения, что необходимо, так как МСР работает через вызовы JSON‑RPC.

• Механизм External Authorization в Envoy позволяет делегировать принятие решений о разрешении или запрете запросов к внешнему сервису авторизации, например, если необходимо подключать проверку пользователя при вызове инструмента или ресурса.

• Механизм Rate Limiting в Envoy ограничивает интенсивность запросов для предотвращения атак.

Управление секретами. MCP Gateway может безопасно получать и передавать секретные данные (токены, ключи) через Envoy Secret Discovery Service (SDS), обеспечивая их защиту и ротацию.

Наблюдаемость и аудит

Полный аудит действий. Envoy ведёт детальные журналы всех запросов и ответов, а Service Mesh позволяет автоматически собирать метрики, журналы и трассировки (telemetry), обеспечивая полное понимание работы MCP Gateway.

Трассировка вызовов. Service Mesh поддерживает распределённую трассировку (Jaeger, Zipkin), что позволяет проследить путь запроса от клиента через MCP Gateway к целевому инструменту и обратно.

Мониторинг производительности. Envoy и Service Mesh предоставляют метрики использования инструментов задержки, ошибки и другие показатели, помогая оптимизировать работу MCP Gateway.

Масштабируемость и отказоустойчивость

Горизонтальное масштабирование MCP Gateway является частью самого прокси, что позволяет легко масштабировать его параллельно с ростом нагрузки.

Отказоустойчивость. Envoy поддерживает Circuit Breaking, Retry Policies и Timeouts, предотвращая каскадные сбои и обеспечивая стабильность работы MCP Gateway.

Если вы уже используете Service Mesh или задумываетесь о его использовании для взаимодействия ИИ‑агентов, то расширение его базовых возможностей с помощью MCP Gateway даст ощутимые бонусы для архитектуры в целом.

Конфигурирование MCP Gateway

Для настройки функциональности МСР Gateway мы сделали в составе управляемого прокси дополнительные CRD (Custom Resource Definition), поддерживаемые Synapse Service Mesh. Расскажем о них подробнее.

McpGateway: в нём указывается, на каком Envoy proxy должен быть доступен MCP Gateway, параметры создания нового HTTP Server'а и другие параметры.

apiVersion: ai.synapse.sber/v1alpha1
kind: McpGateway
metadata:
  name: my-mcp-gateway
spec:
  selector:
    matchLabels:
      app: egressgateway
  gateway:
    host: mcp-gateway
    port: 443   
  inboundTlsConfig:
    mode: ISTIO_MUTUAL
 
  outboundTlsConfig:
    mode: MUTUAL
    caCertificates: /etc/certs/cacert.pem
    clientCertificate: /etc/certs/clientcert.pem
    privateKey: /etc/certs/privatekey.pem

McpEntrySlice: в нём определяются инструменты и ресурсы, доступные в McpGateway. На запрос ИИ‑агента «tools/list» или «resources/list» MCP Gateway отвечает, используя локальную конфигурацию и авторизационные политики.

Средствами МСР Gateway можно изменить заголовки и тело сообщения. Соответствующие настройки можно найти в CRD.

apiVersion: ai.synapse.sber/v1alpha1
kind: McpEntrySlice
metadata:
  name: my-mcp-config
spec:
  gateway: my-mcp-gateway
 
  tools:
  - name: getRecords
    title: Получить список записей из архива
    description: Позволяет получить список записей из архива с возможностью пагинации.
    inputSchema: |
      {
        ...
      }
    outputSchema: |
      {
        ...
      }
    backend:
      type: "REST"
      destination: "rest-server-1"
      http:
        path: "/records"
        method: "GET"
        ## Опционально: обработка заголовков запроса и ответа при взаимодействии с бекендом функции или ресурса
        headers:
          request: ## хедеры запроса
            proxyAll: true ## Проксировать все хедеры или не проксировать никаких, по умолчанию true
            set: ## Overwrite the headers specified by key with the given values. map<string, string>
              custom-header: "custom-value"
            add: ## Append the given values to the headers specified by keys. map<string, string>
              custom-header: "custom-value"
            remove: ["custom-header"] ## Remove the specified headers. string[]
          response: ## хедеры ответа
            proxyAll: true ## Проксировать все хедеры или не проксировать никаких, по умолчанию true
            set: ## Overwrite the headers specified by key with the given values. map<string, string>
              custom-header: "custom-value"
            add: ## Append the given values to the headers specified by keys. map<string, string>
              custom-header: "custom-value"
            remove: ["custom-header"] ## Remove the specified headers. string[]
       
        ## Опционально: обработка body части http запроса и ответа при взаимодействии с бекендом функции или ресурса
        body:
          request: ## body часть запроса
            append: ## Append the body params specified by key with the given value. Allowed to specify hierarchy where to add the param
            - key: "custom-param1"
              jsonpath: "$" ##root
              value: "custom-value"
            - key: "custom-param2"
              jsonpath: "$.store.book[0].title"
              value: "custom-value" 
            remove: ["$.store.book[*].price"] ## Remove the body params by their jsonPath. string[]
  
  #-----------------------------------
  resources:
  - name: "test-resource-1"
    title: "My resource 1"
    description: "My favourite resource 1"
    uri: "file:///project/src/main.rs"
    backend:
      type: "MCP"
      destination: "mcp-server-1"
      http:
        path: "/mcp"
    subscribable: true
  
  destinations:
  - name: "rest-server-1"
    host: "myserver.mydomain.ru" 
    port: 443
  - name: "mcp-server-1"
    host: "mcpserver. mydomain.ru"
    port: 443 
    ## Опционально: настройка ретраев.
    http: 
      retries:
        attempts: 3
        perTryTimeout: 2s
        retryOn: gateway-error,connect-failure,refused-stream
    ## Опционально: настройка TLS. 
    tls: #DestinationRule
      mode: MUTUAL
      caCertificates: ...
      clientCertificate: ...
      privateKey: ...
    ## Опционально: настройки circuit breaker. 
    trafficPolicy: 
      outlierDetection:
        consecutive5xxErrors: 1
        interval: 1s
        baseEjectionTime: 3m
        maxEjectionPercent: 100

McpAuthorizationPolicy: помогает определять точные правила доступа к инструментам и ресурсам, предотвращая несанкционированные вызовы. Политика также позволяет установить правила доступа к JSON‑RPC-методам MCP Gateway, чтобы, например, вообще ограничить доступ к инструментам или ресурсам.

apiVersion: ai.synapse.sber/v1alpha1
kind: McpAuthorizationPolicy
metadata:
  name: mcp-policy
spec:
  gateway: my-mcp-gateway
 
  action: ALLOW
  ##--------Авторизация по ServiceAccount агента с проверкой допустимых mime-type
  - from:
    - source:
        serviceAccounts: ["ai-agent-1"]
        namespaces: ["foo"]
    to:
      tools:
      - name: "test-tool-1"
      - name: "test-tool-2"
      resources:
      - uri: "file:///project/src/main.rs"
      mcpMethods:
        - initialize
        - notifications/initialized
        - tools/list
        - tools/call
        - resources/list
        - resources/read
        - resources/subscribe
        - resources/unsubscribe
    when:
    - key: request.headers["Content-Type"]
      values: ["application/json","text/event-stream"]

Как мы подружили MCP‑сессии с балансировкой

MCP‑сессии — это уникальные изолированные контексты взаимодействия между MCP‑клиентом (в нашем случае ИИ‑агентом) и MCP‑сервером. Поддержка состояния (statefulness) позволяет сохранять промежуточные данные, историю диалога и переменные в рамках одного сеанса работы. При этом разграничение контекстов изолирует данные и историю действий одного пользователя или агента от других, чтобы они не перемешивались. Для поддержания сессии в рамках взаимодействия между MCP-клиентом и MCP-сервером используют HTTP-заголовок mcp‑session‑id.

MCP Gateway поддерживает установку сессии до клиента и до сторонних МСР‑серверов. При этом сессия до стороннего МСР‑сервера инициируется только при запросе инструмента или ресурса клиентом, а закрывается при завершении клиентской сессии, в рамках которой та была инициирована.

MCP Gateway являясь частью прокси, может иметь несколько работающих Pod’ов. Поэтому необходимо, чтобы клиент, установивший сессию с определённым Pod’ом шлюза, при последующих запросах в рамках сессии был адресован на тот же Pod для сохранения контекста сессии.

При этом нужна балансировка трафика по заголовку mcp‑session‑id. Её сложность в том, что первый запрос на инициализацию от МСР‑клиента отправляется без mcp‑session‑id, и клиент получает заголовок только в ответе на этот запрос.

Мы решили эту проблему доработкой маршрутизации на сервисном прокси, который развёртываем для всех сервисов в Service Mesh. Его логику дополнили так. При получении ответа от MCP GW сервисный прокси запоминает значение заголовка mcp‑session‑id и IP-адрес Pod’а шлюза, от которого получен ответ. Когда МСР‑клиент обратится с тем же mcp‑session‑id, то его направят на соответствующий Pod шлюза. Если Kubernetes удалил этот Pod, то клиента направят на другой Pod согласно балансировке по умолчанию, и он получит ответ, что его сессии не существует. Протокол требует, чтобы МСР клиент умел обрабатывать такого рода ошибки и реинициализировать подключение.

В случае, если K8s удаляет Pod с поднятым MCP GW, на котором открыта сессия до стороннего МСР‑сервера, то принудительного закрытия сессии не произойдёт. На стороне МСР‑сервера должен быть реализован механизм TTL-сессий, так как принудительное закрытие сессий не требуется согласно спецификации МСР (вызов удаления сессии стоит опциональным в протоколе).

Автоматизация через Synapse API Mesh: от реестра к шлюзам

Список инструментов и ресурсов и правила доступа к ним можно настраивать для MCP Gateway как вручную через CRD, так автоматически посредством Synapse API Mesh. Последний позволяет создать конфигурации в централизованном портале, а потом применить к выделенным шлюзам на прикладных кластерах.

За основу берут информацию из реестра портала, который можно интегрировать с внешними реестрами инструментов, API и автоматизированных систем, которые зачастую есть в компаниях и которые применяют в производственных процессах.

Важно, что при такой реализации достигаются все преимущества централизации, но отсутствует основной недостаток — в случае временного отказа реестра ИИ‑агенты продолжают работать в штатном режиме, так как они обращаются не напрямую к реестру, а к слою граничных шлюзов, предоставляющих МСР Gateway, что можно считать распределённым кешем того же реестра.

Теперь при подключении нового МСР‑сервера или нового внешнего инструмента ИИ‑агенту не нужно прописывать его в коде. Достаточно подключить агент к Synapse API Mesh и получать обновления доступных инструментов при запросах «tools/list». При этом MCP Gateway поддерживает возможность сообщать об изменении списка через стандартный подход с уведомлениями в МСР — достаточно лишь подписаться на это событие.

Само подключение ИИ‑агента к Synapse API Mesh выглядит несложно: нужно прописать несколько меток в развёртывании или сервисе агента и в развёртывании или сервисе граничного шлюза. Synapse API Mesh может через API K8s обнаруживать ресурсы на прикладном кластере и отбрасывать эту информацию в централизованный портал, где она объединяется с реестром API и систем.

После создания необходимых конфигураций централизованный портал отправляет их на прикладной кластер и применяет через API K8s, где их подхватывает Synapse Service Mesh и доносит до прокси. Всё это можно как автоматизировать, так и выполнять под контролем пользователя (администратора системы).

Помимо очевидных функций API Mesh, о которых можно почитать в других источниках, портал Synapse API Mesh предоставляет несколько функций для поддержки конкретно агентских инструментов:

✅ Единый реестр инструментов с версионированием и учётом прав доступа.

✅ Описание инструментов поверх API, с возможностью указания описания и выставления схемы, отличной от оригинального API, чтобы, например, разделить один унифицированный API на несколько сценариев использования для облегчения понимания LLM.

✅ Дедубликация имён инструментов. Для этого есть механизм замены вызываемого имени инструмента на MCP Gateway на целевой перед отправкой запроса на внешний МСР-сервер. При автоматическом формировании конфигураций через портал Synapse API Mesh обязательно проверяется дублирование имён инструментов и выставление дублируемых под уникальными промежуточными именами.

Надеюсь, что идеи, использованные при создании наших продуктов, помогут вам при решении собственных задач.

В следующей статье расскажу, как к МСР Gateway подключать не только инструменты, но и агентские карточки, и как при этом осуществить межагентское взаимодействие. А пока буду рада увидеть ваши комментарии и обсудить подход!