Начиная с 2025 года MCP (Model Context Protocol) кардинально изменил классические подходы к построению ИТ-инфраструктуры предприятий. Отвечая на бурное развитие ИИ-инструментов и систем, разработчики протокола предложили элегантное решение для стандартизации межмашинного взаимодействия при посредничестве ИИ-агентов. Одна из самых привлекательных сторон MCP-протокола — универсальность. Теоретически протокол не накладывает ограничений на специфику объекта, с которым необходимо установить взаимодействие. Это может быть как ПО (ERP-система, СУБД, прикладной пакет проектирования электронных схем и пр.), так и оборудование (шлюз промышленного интернета вещей, коммутатор, АСУТП-контроллер и пр.). Однако у MCP есть и недостатки, а также имеются принципиальные ограничения, основанные на самой природе ИИ-решений.

Рождение

В ноябре 2024 года компания Anthropic выложила в открытый доступ исходный код универсального протокола MCP и инструменты разработки решений на его основе. Протокол представляет собой средство стандартизации интеграции ИИ-приложений с внешними источниками данных и программными сервисами их обработки. При этом подразумевается, что внутри интеграционного контура работа с данными происходит без участия человека — ИИ-компоненты сами решают, какие данные им нужны, где их лучше взять, как обработать, а затем что и как выгрузить.

Первоначально ИТ-сообщество скептически приняло протокол, однако с начала 2025 года популярность MCP и количество идей по его использованию стали расти лавинообразно. Изначально протокол задумывался как решение одной из фундаментальных проблем LLM-систем — изолированности моделей от внешнего мира, работающих в «вакууме», без интеграции с внешней информационной средой. Они обучены на статических данных из прошлого, могут иметь доступ к открытой информации из Сети (хотя не все источники допускают ИИ-агентов к своим данным), но обычно не имеют доступа к персональной или корпоративной информации.

MCP предлагался в качестве стандартизованного протокола общения LLM с реальным миром, позволяющего создавать решения, превращающие LLM из «всезнающего эрудита с устаревшими данными» в систему, общающуюся с внешними информационными системами в режиме реального времени. При этом архитектура протокола реализует возможность двунаправленного обмена данными: системы могут не только забирать информацию, но и делиться ею с другими системами.

Популярности решения способствовала идея стандартизации обмена данными в среде ИИ/ML-приложений. До MCP каждый разработчик и каждая компания вынуждены были создавать собственные интеграционные решения: одноразовые плагины, уникальные скрипты под конкретную задачу и API-обертки. Это приводило к фрагментации, несовместимости и огромным затратам на поддержку. MCP был задуман как открытый стандарт по аналогии с протоколом HTTP.

Важно и то, что протокол предназначался для работы в корпоративной архитектуре с соблюдением требований бизнеса, включая обеспечение информационной безопасности. При этом перед разработчиками стоит непростая дилемма: как спроектировать протокол, реализующий требования ИБ корпоративной инфраструктуры, не перегрузив его функционально для использования в персональных системах.

MCP появился ровно в тот момент, когда возникла острейшая необходимость в подобном решении — мир осознал мощь LLM, но уперся в ограничение, связанное с их изолированностью. В системах, построенных на основе MCP, команды на поиск, выгрузку и загрузку данных, их трансформацию и обработку выдает сама модель.

Использование

В корпоративной ИТ-среде наиболее популярные направления использования MCP: СУБД и DevOps, CRM, ERP и облачные системы. Например, по состоянию на август 2026 года имеется уже 190 зарегистрированных MCP-серверов для PostgreSQL и несколько десятков для Microsoft SQL Server. Современные корпоративные системы активно включают в свой состав MCP-серверы, имеющие доступ к корпоративным системам, играя роль стандартизированного моста для взаимодействия с ними ИИ-агентов СУБД.

В области СУБД MCP-серверы могут применяться следующим образом.

  • Доступ к данным. ИИ-агент на основании текстового или голосового запроса пользователя на естественном языке, взаимодействуя с MCP-сервером, получает доступ только на чтение к данным в конкретной СУБД и ее аналитическому функционалу. Например: «Построй когортный анализ удержания клиентов по месяцам регистрации за 2025 год». Агент формирует таблицу с данными и предоставляет аналитический вывод на их основе.
  • Управление данными. Сегодня это пока еще экспериментальный функционал, привлекательный тем, что позволяет оперировать качественными и оптимизационными характеристиками, например: «Создай пайплайн ежедневной загрузки данных из 1С в PostgreSQL в периоды минимальной загрузки СУБД». Реализация подобного функционала требует от разработчиков значительных усилий, поскольку программную реализацию подобной команды, сгенерированную ИИ-агентом, необходимо проверять на валидность. Конечно, созданный на основе текстового описания набор команд можно передать пользователю на проверку, но тогда теряются вся привлекательность и смысл решения на основе MCP. Сегодня активно ведутся эксперименты в этом направлении. Если проблема будет решена, то системы MCP получат очень сильный толчок. Примеры возможных сценариев: автоматизация ETL/ELT-процессов, управление зависимостями между пайплайнами, управление качеством данных (Data Quality), управление схемой данных (Schema Evolution), управление метаданными и каталогами (примеры реализаций — dbt MCP, Kafka Schema Registry MCP и др.).
  • Администрирование и мониторинг СУБД. Унификация инструментов управления в рамках корпоративной инфраструктуры, позволяющая отказаться от специализированных продуктов, ориентированных на конкретное программное решение с тысячами пользовательских экранов и сотнями предопределенных метрик мониторинга. Подход к администрированию и мониторингу на основе ИИ-агентов позволяет создать единый инструмент администрирования на основе бизнес-терминов без необходимости глубокого погружения администратора в технические детали ключевых операций. Например, резервное копирование — это общее понятие практически для всех бизнес-сущностей. Роль администратора — дать команду и определить критерии ее выполнения, а агент автоматически разработает модель резервного копирования для конкретного программного решения и подскажет, если оператор ошибется в критериях. Сейчас это самый бурно развиваемый сегмент MCP-серверов.

Cегодня в продуктивных режимах обычно используется функционал MCP-сервера только в режиме чтения (Read-Only Mode) — пока отсутствует общая практика контроля действий ИИ-агента при модификации данных.

Сам по себе MCP-протокол не различает операции чтения и модификации данных на уровне сообщений — ИИ-агент может вызвать любую операцию из списка, предоставляемого MCP-сервером, поэтому ответственность за возможность модификации данных несет разработчик сервера.

В MCP описана возможность предупреждения пользователя о возможных деструктивных последствиях работы инструментов (через декларативный хинт — destructiveHint), но по факту это подсказки, а не требование формирования подтверждения со стороны пользователя. Использование этого механизма для запроса-подтверждения на выполнение конкретной операции со стороны пользователя-человека требует согласованной разработки MCP-сервера и MCP-клиента, так как нет стандартизованного механизма обработки этого хинта. По этой причине защиту от потенциально деструктивных команд принято реализовывать на основе RBAC (управление доступом на основе ролей) и дополнительных инструментов вне протокола MCP.

Архитекутура

Основные компоненты и типовые возможности работы протокола MCP можно рассмотреть на примере сервера VMware Tanzu Greenplum MCP, напрямую подключающего корпоративных ИИ-клиентов и большие языковые модели к кластеру баз данных Greenplum.

Сервер Greenplum MCP позволяет шлюзам и ИИ-приложениям безопасно запрашивать данные, анализировать и диагностировать среду СУБД Greenplum, используя естественный язык, выступая в качестве управляемого промежуточного слоя между ИИ и корпоративными данными. Сервер функционирует как компонент промежуточного программного обеспечения, который выполняет вызовы инструментов и SQL-запросы, генерируемые большими языковыми моделями. LLM использует предоставленный контекст схемы для генерации точных SQL-запросов или системных команд, которые затем сервер MCP проверяет на соответствие политикам безопасности перед выполнением в базе данных. Он разработан как stateless-приложение, не хранящее данные о предыдущих запросах, с поддержкой механизмов высокой доступности и независимостью от бэкенда.

Схема работы сервера VMware Tanzu Greenplum MCP. AI Assistant — терминология производителя для обозначения интерфейса взаимодействия с пользователем

Перечислим сновные компоненты сервера Greenplum MCP (см. рисунок).

  • Хост — приложение (например, Claude Desktop), предоставляющее пользовательский интерфейс для оператора и запускающее MCP-клиент(ов). Хост взаимодействует с LLM, которая принимает решения о вызове инструментов.
  • Клиент — мост между MCP-хостом и MCP-серверами. Клиенты — это многофункциональные программы, которые запрашивают у серверов список доступных инструментов и их описания; вызывают инструменты по мере необходимости; ведут реестр подключенных серверов и их возможностей; отправляют структурированные JSON-запросы (например, для выполнения SQL-запросов, поиска RAG или загрузки ресурсов) и обрабатывают потоковые ответы. Такая архитектура минимизирует задержку и поддерживает потоковую передачу данных, что делает ее идеальной для агентных систем, где критически важен динамический поиск данных. Многие производители интегрируют MCP-хост и MCP-клиент в одном продукте, но на рынке также присутствуют «чистые» реализации MCP-клиентов (например, SDK на TypeScript и Python).
  • Сервер — программа (по сути, коннектор), выступающая в роли интерфейса к внешней системе через ее API. По запросу MCP-клиента сервер предоставляет информацию о своих возможностях, обеспечивает выполнение заявленных команд, а также выполняет проверки валидности и отвечает за предотвращение вольных или невольных деструктивных воздействий, связанных с выполнением команд, полученных от MCP-клиента. Аутентификация пользователей и управление доступом обычно реализуются на уровне хоста или клиента, а не на стороне сервера.

MCP-клиенту предоставляются сведения о возможностях MCP-сервера.

  • Инструменты (tools) — это список команд (функций), которые ИИ-агент может вызывать для взаимодействия с базой данных, с описанием того, что делает каждая команда (эта информация предназначена для ИИ-агента). Форма описания инструментов и их аргументов стандартизирована в рамках MCP через спецификацию JSON-RPC 2.0 с использованием JSON Schema. Однако набор конкретных инструментов остается на усмотрение разработчика. Ответственные разработчики стремятся создать широкий набор «узких» инструментов с предсказуемым (по крайней мере теоретически) результатом. «Узкую» команду легче описать, контролировать и аудировать. Использование «свободного SQL» (free-form SQL) — самый простой и гибкий, но и самый рискованный подход: агент получает инструмент, принимающий строку с SQL-запросом. Это создает риски SQL-инъекций, случайных или вредоносных изменений данных и выполнения неоптимизированных запросов. Подобный подход чаще всего используется в экспериментальных разработках. Вероятнее всего, развитие пойдет по пути динамического формирования набора «полностью типизированных инструментов» (fully-typed tools) в зависимости от прав доступа и типа запрашиваемой информации, актуализированных и подтвержденных со стороны MCP-клиента.
  • Ресурсы (resources) — описание пассивных источников данных, предоставляющих доступ только на чтение в контексте: содержимое файлов, схемы баз данных, документация API и т. п. Ресурсы — это ключевой механизм предоставления ИИ-агенту метаданных и структурной информации о базе данных. В отличие от инструментов, которые выполняют действия (запросы), ресурсы предоставляют контекст, который модель использует для понимания схемы данных перед формированием запросов. Ресурсы могут использоваться для формирования семантического слоя данных — структурированного описания бизнес-сущностей и их связей.
  • Подсказки (prompts) — предварительно созданные шаблоны инструкций, которые указывают модели, как работать с конкретными инструментами и ресурсами. Подсказки — это готовые «сценарии работы», которые обучают ИИ-агента правильно комбинировать действия и данные для выполнения сложных многошаговых задач. Они превращают разрозненные возможности сервера в структурированный рабочий процесс, избавляя пользователя от необходимости каждый раз объяснять агенту последовательность действий. Подсказки могут быть гибкими: например, подсказка для анализа таблицы может принимать имя таблицы в качестве аргумента.

На примере сценария работы Tanzu Greenplum MCP Server рассмотрим особенности применения MCP.

Пользователь задает ИИ-агенту вопрос на естественном языке, например, «Предоставь данные о количестве проданных автомобилей за прошлую неделю». Агент передает запрос в LLМ, причем у нее уже есть информация от MCP-клиента о возможностях MCP-сервера. Модель понимает запрос, генерирует SQL-запрос и решает, какой инструмент использовать из списка доступных, затем передает его MCP-клиенту, который пересылает SQL-запрос MCP-серверу в формате конкретного инструмента (в нашем случае 'execute_query'). Сервер запускает этот инструмент, с помощью которого SQL-запрос будет выполнен в GPDB, и возвращает клиенту результат исполнения SQL-команды. MCP-клиент передает полученную информацию LLM, которая ее форматирует и передает пользователю.

Помимо выполнения SQL-команд и получения информации о схемах и таблицах, MCP-сервер с помощью инструмента explain_query позволяет просмотреть план выполнения запроса, а инструмент diagnose_query дает возможность провести анализ SQL-запроса на предмет потенциальных проблем, включая синтаксические ошибки, неправильный порядок объединения, передачу больших объемов данных, отсутствие исключения разделов, устаревшую статистику, ошибки оценки кардинальности и более 20 других антипаттернов. Другие инструменты предоставляют информацию о «здоровье» кластера.

Необходимо отдельно отметить возможность работы через MCP-сервер с gpMLBot (Greenplum Automated Machine Learning Agent) — агентом автоматизированного машинного обучения (AutoML), встроенным в экосистему VMware Tanzu Greenplum. Его ключевая задача — упростить и автоматизировать полный жизненный цикл ML-моделей: от обработки данных до развертывания. MCP-сервер выступает в качестве интерфейса для доступа к gpMLBot через стандартизованные запросы, описанные в виде инструментов. Кроме того, MCP-сервер предоставляет подсказки — шаблоны для выполнения сложных рабочих процессов, включающих набор инструментов.

Благодаря интеграции с gpMLBot VMware Tanzu Greenplum MCP Server превращается из простого инструмента выполнения SQL-команд и получения данных мониторинга в платформу для реализации возможностей машинного обучения, предоставляя функциональность MADlib, PostgreML и инференса.

Использование семантического слоя

Механизм семантического слоя служит «мостом» между техническими названиями в базе данных и бизнес-терминами, понятными человеку. При всей глубине познаний LLM не может знать, что конкретно закодировано в названии того или иного поля в таблице данных, особенно если пользователь применяет не очевидное обозначение. Сегодня для создания семантического слоя используются: семантическая разметка данных в СУБД — обогащение схемы базы данных семантическими описаниями, пригодными для интерпретации ИИ-агентами (разметку добавляют для сущностей, полей, параметров хранимых процедур и других объектов); реализация семантического слоя на уровне MCP-сервера — реализация бизнес-глоссариев и определений в среде сервера, обучение ИИ-агента работе с данными конкретной СУБД на основе предоставления примеров запросов, документации по API, схемы базы данных и других материалов; интеграция с корпоративным каталогом данных — использование централизованного решения Data Catalog для построения семантического слоя компании (не требуется «размывать» бизнес-определения по конкретным таблицам в СУБД или реализациям MCP-серверов. Хороший пример — реализация MCP-сервера в OpenMetadata, предоставляющая доступ к своему унифицированному графу знаний ИИ-агентам или другим MCP-серверам).

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

Один из ключевых моментов работы MCP-сервера — реализация механизма аутентификации и авторизации клиентов. Релиз MCP (2026–07–28) содержит ряд существенных изменений в этой области, выводящих протокол на уровень промышленного использования.

В MCP предусмотрено два варианта доступа:

  1. на основе локального транспорта (stdio) — аутентификации между клиентом и сервером не требуется;
  2. на основе удаленного транспорта (Streamable HTTP) — реализуется с использованием протокола OAuth 2.1, где MCP-сервер выступает в роли Resource Server. В этом случае MCP-сервер предоставляет информацию о расположении авторизационного сервера (внешнего провайдера, например, Keycloak), к которому MCP-клиент обращается для получения токена. Пользователь проходит аутентификацию (в рамках MCP-клиента или автономно). При этом MCP-клиент не видит учетные данные пользователя — он получает токен после успешной аутентификации и передает его серверу, который проверяет его валидность у провайдера аутентификации и права пользователя на основе областей действия (scopes).

Механизм контроля прав на основе scopes не является реализацией RBAC, и если объект, с которым интегрируется MCP-сервер, поддерживает аутентификацию через токены (OAuth/JWT/OpenID), то сервер, получив токен клиента, предъявляет его базе данных вместо логина и пароля. Если объект не поддерживает такой способ, то разработчикам необходимо его реализовать в соответствии с принятыми в компании стандартами информационной безопасности. Однако в обоих случаях, если для доступа к объекту важно учитывать RBAC, разработчики должны реализовывать его самостоятельно — RBAC в стандарте MCP не описан. Кроме этого необходимо учитывать, что в протоколе не реализовано обязательное требование на аутентификацию для удаленного транспорта. В одном из исследований, проведенном в мае 2026 года, было обнаружено, что из почти восьми тысяч «живых» удаленных (remote) MCP-серверов 40% вообще не используют аутентификацию. Протестировав 119 серверов, которые поддерживали OAuth, исследователи обнаружили как минимум одну уязвимость в реализации аутентификации каждого сервера.

Стандартизация

Один из ключевых вопросов, характеризующих успешность развития любого протокола и решений на его основе, — это стандартизация. Для MCP основой для этого стал переход в общественное управление — в декабре 2025 года MCP был передан в Linux Foundation через создание Agentic AI Foundation (AAIF), что заложило основу для превращения MCP в зрелый, нейтральный и управляемый сообществом отраслевой стандарт. Однако сегодня не все компании признают MCP как стандарт де-факто. Для того чтобы MCP стал стандартом де-юре, необходимо принять стратегическое решение о начале формального процесса в одной из аккредитованных организаций, скорее всего в IETF (Internet Engineering Task Force), и решать все технические вопросы по стандартизации.

Кроме MCP существуют и другие проекты, направленные на стандартизацию взаимодействия ИИ-агентов:

  • A2A (Google) — открытый протокол, цель которого, в отличие от MCP (ориентированного на «соединение агента с миром»), декларируется как «соединить агентов друг с другом» (агент-агентное взаимодействие);
  • AGNTCY (Cisco/Linux Foundation) — цель проекта определяется как «создание инфраструктуры интернета агентов для бесшовного взаимодействия» путем стандартизации механизмов обнаружения агентов, управления идентичностью, безопасного обмена сообщениями и наблюдаемости;
  • WITNESS (COGITATOR Witness Protocol) — создание механизма криптографически защищенного хранения неизменяемой информации о всех действиях агентов для последующего аудита и верификации.

Развитие

Протокол развивается от экспериментальных опытов к обеспечению должного уровня надежности, безопасности и производительности для интеграции экосистемы MCP в корпоративную инфраструктуру и обеспечения возможности ее промышленного применения для обработки данных и управления. Разработчики протокола стараются использовать организационный и технический опыт успешных проектов Open Source.

Cреди ключевых направлений развития:

  • Stateless-ядро MCP — переход полностью к архитектуре stateless (без сохранения состояния) с целью обеспечения горизонтального масштабирования и обеспечения высокой доступности в современных облачных средах;
  • создание механизма «расширений» — использование успешного опыта реализации «расширений» в проектах категории Open Source (например, PostgreSQL); расширения MCP — это официальный и стандартизированный способ добавления новых возможностей в протокол, не требующих изменений в ядре;
  • развитие механизмов аутентификации — спецификации, добавляющие важные требования безопасности для MCP-серверов, выбирающих использование аутентификации.

Кроме того, MCP-серверы развиваются в сторону создания универсальных серверов, работающих в качестве единого интерфейса к различным базам данных (PostgreSQL, MySQL, SQL Server, BigQuery, Oracle, SQLite, Snowflake, Redshift и др.). Такой подход обеспечивает унификацию работы с СУБД и позволяет MCP-клиенту взаимодействовать с распределенными базами данных без переключения контекста. В этом случае MCP-сервер реализует паттерн «database router» — не простое подключение к одной базе данных, а маршрутизация запросов между несколькими источниками прозрачна для модели (правда, имеются реализации, где выбор источника выполняется через параметры инструментов).

Создаются также MCP-серверы, ориентированные на работу с конкретными типами данных: векторными, графовыми, временными рядами и др. Например, существует несколько реализаций для работы с расширением PostgreSQL pgvector, обеспечивающих функциональность векторного поиска и интеграцию с провайдерами эмбеддингов (OpenAI, Cohere и др.). Также появляются специализированные серверы для графовых баз данных (например, Neo4j) и временных рядов (например, InfluxDB).

Изменения корпоративных архитектур

Сегодня решения, созданные на основе MCP, пока находятся в стадии между экспериментальными разработками и пилотными внедрениями в продуктивных средах, что связано с молодостью протокола. Однако бурное развитие решений на его основе демонстрирует, что разработчики видят достоинства и широкие возможности архитектур на основе MCP. Протокол позволяет элегантно решить ключевую проблему корпоративной инфраструктуры — интеграцию различных решений с пользовательскими приложениями, в качестве которых могут выступать не только программы с диалоговыми ИИ-интерфейсами, но и корпоративные системы, требующие интеграции с другими решениями. Это достигается благодаря трем ключевым факторам MCP.

  • Унификация и стандартизация. MCP-сервер не просто передает данные клиенту — он «рассказывает», какие операции может выполнять в рамках обслуживаемого им программного продукта. Это позволяет использовать один MCP-сервер в качестве интерфейса для широкого спектра решений вне зависимости от их предметной области. Каждый MCP-клиент может использовать только те команды, которые необходимы для выполнения его задач. При этом расширение (или изменение функционала) MCP-сервера не требует модификации клиентского ПО, если изменения не затрагивают протокол взаимодействия.
  • Ориентированность на новый тип потребителей. MCP кардинально отличается от классического API, создаваемого для традиционной программной инженерии: его потребитель — это код, написанный человеком, который работает по строгим, заранее известным правилам. Потребитель MCP — это LLM и автономные ИИ-агенты. MCP-серверы сами «рассказывают», как с ними работать, в отличие от классических API, где правила интеграции описаны в документации для людей. Новые правила интеграции формируют новую архитектуру корпоративных систем, внедряющих ИИ в продуктивный контур.
  • Единый API для программного и аппаратного обеспечения. MCP позволяет унифицировать доступ к программному и аппаратному обеспечению на основе единого подхода, реанимируя тем самым концепцию «умного интернета вещей» (Smart IoT) и трансформируя ее в Artificial Intelligence of Things (AIoT).

MCP открывает широкие возможности для взаимодействия между людьми и ИТ-решениями (программными и аппаратными) через ИИ-агентов. При этом возможности во многом зависят от креативности пользователей и сценариев использования. Например, ИИ-агенту одинаково легко как выполнять команды, описанные на естественном языке (голосом или текстом), так и формировать пользовательский интерфейс из доступных инструментов.

Однако у MCP есть и существенные недостатки, мешающие протоколу занять достойное место в корпоративной архитектуре продуктивных систем. Среди этих недостатков есть технологические — некоторые из которых преодолены в новом релизе спецификации 2026-07-28 (stateless-архитектура, усиленная авторизация, расширения) — но еще остаются концептуальные, в основе которых лежит сама природа ИИ-технологий.

Ключевой барьер — проблема верификации действий, сгенерированных ИИ. Кто может подтвердить, что ИИ-агент не ошибся и выполнение команды приведет к ожидаемым действиям? В первую очередь это касается операций, связанных с изменением данных и модификацией настроек, но и операции чтения и обработки данных могут приводить к непредсказуемым последствиям, которые не всегда можно компенсировать на уровне лимитов, определенных для пользователя, инициирующего выполнение операции.

Существует целый ряд экспериментальных проектов, направленных на обеспечение проверки валидности команд, получаемых от MCP-клиента. Среди них интересны проекты, связанные с выполнением команд в изолированной среде («песочнице»), и проверка на основе специально обученного ИИ-агента. Однако прорывных решений в этой области пока нет. Но технологии развиваются, и существует высокая вероятность, что скоро появятся новые решения, позволяющие либо решить эту проблему, либо, что более вероятно, обойти ее или нивелировать — имеющиеся ограничения и недоработки протокола могут быть преодолены: спецификация MCP (2026-07-28) — яркое этому подтверждение.

***

MCP заложил фундамент новой архитектуры интеграции технических объектов, а в его последнем релизе 2026–07–28 были решены проблемы масштабирования и обеспечены требования к аутентификации. Уже сегодня решения на базе MCP вполне можно использовать в корпоративных инфраструктурах, однако контроль логики исполнения команд на стороне интегрируемых приложений остается на стороне разработчиков MCP-решений вместе со всеми сопутствующими проблемами обеспечения безопасности. По всей видимости, эти задачи и будут определять вектор развития протокола в ближайшие годы.

Владимир Быков (vb@russianbi.ru) — директор по развитию, аналитический и исследовательский центр «Круги Громова» (Санкт-Петербург).