# MCP-сервер: что это, как работает и где применяется

Автор: Ермолаев Тимофей Владимирович  
Оригинал: https://timofei-ermolaev.ru/llm/mcp-server/  
Опубликовано: 2026-10-24  
Обновлено: 2026-10-24

Вы пишете ИИ-помощнику: «Найди молоко, доступное для доставки на мой адрес». Чтобы выполнить просьбу, ему нужны сведения магазина: какие товары доступны, сколько они стоят и подходят ли для выбранного адреса. Общих знаний языковой модели для этого недостаточно.

**MCP-сервером называют программу, которая предоставляет ИИ-приложению доступ к данным и действиям по открытому протоколу Model Context Protocol.** Протокол задаёт общие правила такого взаимодействия. Один сервер позволяет приложению искать товары. Другой помогает читать рабочие документы, а третий предоставляет инструменты для управления задачами в проекте. [Model Context Protocol](<https://modelcontextprotocol.io/docs/2026-07-28/learn/architecture>)

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

## Коротко

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

## Как запрос проходит от чата к внешнему сервису

Возьмём условный пример с ВкусВилл. У компании есть [MCP-сервер с поиском товаров](<https://mcp.vkusvill.ru/mcp>). Предположим, совместимое ИИ-приложение уже подключено к нему, пользователь авторизован, а адрес доставки выбран в личном кабинете магазина.

В этой схеме участвуют несколько программ. **ИИ-приложение** управляет диалогом и подключениями. В терминологии MCP оно называется **host**. **Языковая модель** обрабатывает просьбу и выбирает дальнейший шаг. За обмен сообщениями с сервером отвечает компонент приложения под названием **MCP-клиент**. **MCP-сервер** предоставляет возможности магазина.

Вот как может обрабатываться просьба найти молоко:

1. **Приложение передаёт модели запрос и описания доступных инструментов.** Из описаний понятно, какие операции существуют и какие параметры они принимают.
2. **Модель предлагает вызвать поиск товаров.** Она формирует структурированный запрос с параметрами поиска. На этом этапе товары ещё не найдены: подготовлен вызов функции.
3. **Приложение проверяет, разрешено ли действие.** Оно учитывает настройки подключения, выданные права и правила подтверждения операций. Если требуется согласие пользователя, его нужно получить до выполнения.
4. **MCP-клиент передаёт вызов серверу.** Сервер обрабатывает поиск и возвращает сведения о найденных товарах. В нашем примере доступность связана с адресом, выбранным в аккаунте.
5. **Приложение передаёт результат модели, а модель составляет ответ.** Пользователь видит найденные варианты и может продолжить диалог. Если сервер вернул ошибку, оснований сообщать об успешном поиске нет.

**Человек**

«Найди молоко»

**Просьба**К приложению

**Ответ**От приложения

**Языковая модель**

Предлагает вызов, формирует ответ

**К приложению**Предложение вызова;
после чтения — ответ

**К модели**Задача и описания;
после чтения — данные

**ИИ-приложение host**

Проверяет допуск вызова: политика и разрешения.
Полученные данные передаёт в контекст модели.

Допущенный вызов

Полученные данные

**MCP-клиент**

Компонент связи внутри этого приложения

**Вызов**`tools/call`

**Данные**К MCP-клиенту

**MCP-сервер**

Проверяет права и выполняет разрешённое чтение.

**Чтение**Поиск молока

**Данные**К MCP-серверу

**Данные о товарах ВкусВилл**

Для адреса, заранее выбранного в личном кабинете

Такое разделение ролей описано в [архитектуре MCP](<https://modelcontextprotocol.io/docs/2026-07-28/learn/architecture>). О том, как модель выбирает функцию, а приложение обрабатывает её вызов, можно прочитать в [документации по tool use](<https://platform.claude.com/docs/en/agents-and-tools/tool-use/overview>).

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

## Зачем понадобился отдельный протокол

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

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

При этом связь сервера с конкретным продуктом всё равно нужно реализовать. Сервер для магазина должен уметь искать товары, а сервер для редактора должен уметь выполнять команды этого редактора. MCP стандартизирует интерфейс между приложением и сервером; предметная логика остаётся у разработчиков интеграции.

### Кто создал MCP и кто его развивает

Anthropic [представила MCP 25 ноября 2024 года](<https://www.anthropic.com/news/model-context-protocol>). Его создали David Soria Parra и Justin Spahr-Summers.

9 декабря 2025 года компания [объявила о передаче MCP в Agentic AI Foundation](<https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation>). Этот фонд работает под эгидой Linux Foundation. Техническое развитие осталось за сопровождающими проект разработчиками и сообществом.

Поэтому полезно различать сам стандарт и отдельные продукты вокруг него. GitHub, Figma или независимый разработчик могут выпустить собственный MCP-сервер, но это не делает их владельцами протокола.

## Что сервер предоставляет приложению

В MCP есть три базовых способа предоставить возможности: инструменты, ресурсы и шаблоны запросов. Они описаны в [документации серверной части](<https://modelcontextprotocol.io/docs/2026-07-28/learn/server-concepts>).

| Возможность | Что получает приложение | Пример |
| --- | --- | --- |
| **Инструменты (tools)** | Функции с описанием и параметрами, которые можно вызвать | Найти товар, прочитать задачу, создать комментарий |
| **Ресурсы (resources)** | Данные с определённым адресом (URI), которые можно включить в контекст | Содержимое документа, файл проекта, схема базы данных |
| **Шаблоны (prompts)** | Готовые шаблоны инструкций или сообщений, иногда с параметрами | Шаблон разбора документа или подготовки отчёта |

Инструмент может как читать данные, так и менять их. Ресурс приложение может прочитать и включить полученные данные в контекст модели. Шаблон помогает сформулировать работу, но сам по себе не означает, что описанные в нём действия уже выполнены.

Конкретный сервер может поддерживать только часть этих возможностей. [Model Context Protocol](<https://modelcontextprotocol.io/docs/2026-07-28/learn/server-concepts>)

С помощью `tools/list` приложение получает описания инструментов, а `tools/call` позволяет вызвать выбранный инструмент. Список может кешироваться: запрашивать его заново перед каждым действием не требуется. Это предусмотрено [спецификацией tools](<https://modelcontextprotocol.io/specification/2026-07-28/server/tools>).

## Где работает MCP-сервер и как к нему подключаются

Слово «сервер» обозначает роль программы. Она может запускаться на том же компьютере, что и MCP-клиент, или работать на другой машине.

В стандартных вариантах подключения используются:

- **stdio.** Клиент запускает процесс сервера и обменивается с ним сообщениями через стандартные потоки ввода и вывода. Такой вариант часто встречается у локальных интеграций.
- **Streamable HTTP.** Клиент обращается к HTTP-адресу. Сервер может находиться на той же машине, во внутренней сети компании или в интернете.

Эти способы определены в [документации транспортов MCP](<https://modelcontextprotocol.io/specification/2026-07-28/basic/transports>). Для HTTP отдельно описаны и [условия локального запуска](<https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/streamable-http>).

Чтобы подключение работало, у клиента и сервера должна быть хотя бы одна общая версия протокола, совместимый способ обмена и поддержка нужных функций. Для защищённого сервиса понадобится также подходящий способ авторизации. Полные наборы возможностей у клиента и сервера могут различаться. [Model Context Protocol](<https://modelcontextprotocol.io/specification/2026-07-28/basic/versioning>)

**На 24 октября 2026 года актуальна редакция спецификации 2026-07-28.** В ней убраны обязательная предварительная инициализация и протокольные сессии прежней модели обмена. Инструкции для редакций 2025-11-25 и более ранних могут описывать другой порядок подключения. Это изменение протокола не запрещает приложению сохранять историю диалога или состояние задачи. Эти изменения описаны в [описании релиза](<https://blog.modelcontextprotocol.io/posts/2026-07-28/>) и [правилах совместимости версий](<https://modelcontextprotocol.io/specification/2026-07-28/basic/versioning>). [Model Context Protocol](<https://modelcontextprotocol.io/specification/latest>)

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

## Чем MCP отличается от API, tool calling, RAG и ИИ-агента

Эти понятия относятся к разным частям системы и часто используются вместе.

| Понятие | За что отвечает | Как связано с MCP |
| --- | --- | --- |
| **API сервиса** | Правила, по которым одна программа запрашивает у сервиса данные или выполнение операций | MCP-сервер может обращаться к API магазина, базы знаний или платформы разработки |
| **Tool calling / function calling** | Механизм, с помощью которого модель выбирает функцию и формирует параметры вызова | Приложение может передать модели описания инструментов, полученные от MCP-сервера |
| **RAG** | Подготовка ответа с использованием найденных внешних материалов | Поиск и получение этих материалов могут выполняться через MCP-сервер |
| **ИИ-агент** | Система, которая использует модель и инструменты, чтобы выбирать шаги и выполнять задачу | MCP может обеспечивать подключения, которыми пользуется агент |

Например, агент поддержки ищет нужный раздел внутренней инструкции, получает найденный текст и готовит ответ сотруднику. Поиск может идти через MCP-сервер. Сам сервер может обращаться к API базы знаний. Использование найденного текста при генерации ответа относится к RAG.

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

Подробнее о соседних понятиях можно прочитать в статьях [«Что такое RAG»](<https://timofei-ermolaev.ru/llm/chto-takoe-rag/>) и [«Что такое ИИ-агент и как он работает»](<https://timofei-ermolaev.ru/llm/chto-takoe-ii-agent/>). Сравнение опирается на [описание tool use](<https://platform.claude.com/docs/en/agents-and-tools/tool-use/overview>), [исходную работу о RAG](<https://arxiv.org/abs/2005.11401>) и [разбор агентных систем Anthropic](<https://www.anthropic.com/research/building-effective-agents>).

## Какие права получает приложение

Подключение сервера открывает определённый набор возможностей. Их границы зависят от самого сервера, прав пользователя, настроек приложения и ограничений среды выполнения. Проверки реализуют приложение, сервер и подключённый сервис: [сам протокол не гарантирует соблюдения этих ограничений](<https://modelcontextprotocol.io/specification/2026-07-28>). [Model Context Protocol](<https://modelcontextprotocol.io/specification/latest>)

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

Согласие подключить сервис также нужно отличать от разрешения на конкретное действие. Правила могут допускать чтение без дополнительных вопросов, но требовать подтверждения перед отправкой сообщения или изменением данных. Как именно это организовано, определяется приложением и настройками доступа.

Есть и вопрос доверия к содержимому. Внешний документ или страница могут содержать текст, который пытается выдать себя за инструкцию для помощника. Такие данные требуют проверки и не должны автоматически менять задачу пользователя или разрешённые действия. Описания инструментов и возвращаемые данные также нельзя считать надёжными только из-за того, что они пришли по MCP. [Model Context Protocol](<https://modelcontextprotocol.io/specification/latest>)

Для локального сервера дополнительно важно, какой код вы запускаете и к каким файлам и сетевым адресам он получает доступ. Официальная документация рассматривает эти риски в [рекомендациях по безопасности](<https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices>). Режим «только чтение» ограничивает изменения, но оставляет важным вопрос доступа к чувствительным данным. [Model Context Protocol](<https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices>)

Наконец, результат нужно проверять по самой операции: появилась ли задача, сохранился ли файл, вернул ли сервис подтверждение. Текст «готово» в чате не заменяет этих сведений.

Управляющее окружение модели, включая допуски и проверки, подробнее разобрано в статье [о harness engineering](<https://timofei-ermolaev.ru/llm/harness-engineering/>).

## Примеры MCP-серверов для разных задач

Дальше рассмотрим девять примеров с разным назначением. Возможности сверены по документации на **24 октября 2026 года**; сравнительное тестирование серверов и проверка на рабочих аккаунтах не проводились.

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

### Разработка, браузер и поиск информации

Официальный **[GitHub MCP Server](<https://github.com/github/github-mcp-server>)** предназначен для работы с репозиториями, задачами и запросами на изменение кода. Есть удалённый и локальный варианты. Набор инструментов можно ограничить, в том числе режимом только для чтения. Подходит, например, для подготовки сводки по задачам; создание и изменение объектов зависят от выданных прав.

**[Playwright MCP](<https://github.com/microsoft/playwright-mcp>)** разрабатывает Microsoft. Этот проект позволяет управлять браузером. Его основной способ работы использует структурированное описание элементов страницы: кнопок, полей, ссылок. Документирован локальный запуск. Это полезно для проверки интерфейсов и выполнения действий на сайтах. Разработчики отдельно предупреждают, что сервер не является границей безопасности: управление браузером может приводить к реальным изменениям в открытых сервисах.

Сервис **[Context7](<https://github.com/upstash/context7>)** от Upstash предоставляет документацию и примеры кода для библиотек с учётом их версий. Для MCP есть удалённое подключение. Он полезен, когда помощнику нужно опереться на описание конкретной версии библиотеки. При выборе важно проверить, есть ли в доступной документации нужный пакет и версия.

Официальный **[Firecrawl MCP Server](<https://github.com/firecrawl/firecrawl-mcp-server>)** предназначен для поиска веб-материалов, извлечения содержимого страниц и обхода сайтов. Для удалённого подключения предусмотрены OAuth и API-ключ; документация предлагает оба способа для доступа к полному набору инструментов. Также есть ограниченный режим без ключа для базовых операций. Условия доступа и квоты нужно смотреть для выбранного режима.

### Дизайн, 3D и игровые проекты

Официальный **[Figma MCP Server](<https://developers.figma.com/docs/figma-mcp-server/>)** передаёт в ИИ-приложение сведения о макетах, компонентах и структуре интерфейса; доступны и возможности создания и изменения содержимого. Есть удалённый сервер и вариант через настольное приложение. Для записи на холст нужен удалённый вариант; доступность функций зависит от клиента, прав, тарифа и типа лицензии Figma.

Проект сообщества **[MCP for Blender](<https://github.com/ahujasid/mcp-for-blender>)** от разработчика ahujasid позволяет взаимодействовать с Blender. Локальный MCP-сервер связан с дополнением внутри редактора и позволяет работать со сценой и объектами. Автор предупреждает: у соединения с дополнением нет встроенной аутентификации и шифрования, поэтому этот интерфейс нельзя открывать в публичную сеть.

Команда Aura поддерживает проект сообщества **[MCP for Unity](<https://github.com/CoplayDev/unity-mcp>)**, который интегрируется в Unity Editor. Он предоставляет операции с ресурсами проекта, сценами и скриптами, а также возможности запуска тестов и сборки. Это сторонний проект, не официальный продукт Unity Technologies. Поскольку инструменты могут менять проект, набор разрешённых операций нужно выбирать под задачу.

### Учётные системы и пользовательские сервисы

Проект сообщества **[@1c-odata/mcp](<https://github.com/hacker-cb/1c-odata/blob/master/packages/mcp/README.md>)** от hacker-cb позволяет читать метаданные и данные 1С через OData. Это не официальный сервер фирмы «1С». В нём не предусмотрены инструменты создания, изменения и удаления данных информационной базы. При этом служебные инструменты могут менять настройки подключений и сохранённые реквизиты доступа. Это отдельная возможность пакета.

Официальный удалённый **[MCP-сервер ВкусВилл](<https://mcp.vkusvill.ru/mcp>)** позволяет искать товары с учётом выбранного в аккаунте адреса, получать историю заказов и персональные предложения. В опубликованном наборе есть создание ссылки на корзину. Такая ссылка ещё не означает оформленного заказа: отдельные инструменты завершения покупки и смены адреса в текущем перечне не заявлены.

## Зачем появился Code Mode

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

При использовании **Code Mode** модель генерирует код для работы с доступными инструментами. Этот код может вызывать функции, обходить списки, проверять условия и отбирать данные. Модель получает результат выполнения и использует его для ответа.

В условном примере код мог бы собрать задачи, отфильтровать их по сроку и вернуть только нужные поля. Такой способ позволяет обрабатывать промежуточные данные и объединять операции. Это не обещание, что любая задача выполнится быстрее или без ошибок. [Cloudflare Agents docs](<https://developers.cloudflare.com/agents/tools/codemode/>)

В [документации Cloudflare](<https://developers.cloudflare.com/agents/model-context-protocol/codemode/>) описаны два варианта:

- **Один инструмент `code` поверх существующего MCP-сервера.** Модель пишет код, используя описания доступных функций, их параметров и результатов.
- **Пара `search` и `execute` для большого API.** Первый инструмент выполняет код, который ищет нужные операции в машиночитаемом описании API в формате OpenAPI. Второй выполняет код для вызова этих операций через предоставленную функцию запросов.

В этих вариантах Cloudflare код выполняется в изолированной среде. Проверка прав и необходимых подтверждений остаётся обязанностью обработчиков инструментов или функции, через которую выполняются запросы. Изоляция кода и разрешение изменить данные решают разные задачи. [Cloudflare Agents docs](<https://developers.cloudflare.com/agents/model-context-protocol/codemode/>)

Code Mode развивается вокруг способов использования инструментов и не является обязательной частью MCP. Cloudflare обозначает свою реализацию как [экспериментальную](<https://developers.cloudflare.com/agents/tools/codemode/>) и для простых задач с небольшим фиксированным набором инструментов рекомендует обычные прямые вызовы.

## Куда развивается MCP

В [дорожной карте MCP](<https://blog.modelcontextprotocol.io/posts/mcp-roadmap/>) среди направлений работы названы длительные агентные задачи, события и потоковые результаты, упрощение HTTP-взаимодействия, идентичность агентов и делегирование прав.

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

Дорожная карта описывает направление развития. Доступность конкретной функции нужно проверять у выбранных клиента и сервера.

## С чего начать выбор сервера

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

Затем проверьте три вещи:

1. **Нужная операция действительно есть.** Название продукта в имени сервера не означает поддержку всех его возможностей.
2. **Ваше приложение умеет подключаться выбранным способом.** Сверьте транспорт, версии и авторизацию по инструкции.
3. **Результат можно проверить.** Для первой пробы выберите ограниченную задачу: найти известную запись, прочитать конкретный документ или получить сведения, которые можно сравнить с интерфейсом сервиса.

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

## По теме

- [Что такое RAG и как работает поиск по внешним источникам](<https://timofei-ermolaev.ru/llm/chto-takoe-rag/>) — Поможет подробнее разобраться, как системы находят фрагменты документов и передают их языковой модели для ответа.
- [Что такое ИИ-агент и чем он отличается от обычного чата с моделью](<https://timofei-ermolaev.ru/llm/chto-takoe-ii-agent/>) — Объясняет, как устроен цикл работы агента с планированием шагов, вызовом инструментов и проверкой результата.
- [Harness engineering: как устроена среда вокруг языковой модели](<https://timofei-ermolaev.ru/llm/harness-engineering/>) — Показывает, как прикладное окружение управляет контекстом, ограничениями, проверками и выполнением задач вокруг модели.

## Первоисточники

1. [Архитектура MCP](<https://modelcontextprotocol.io/docs/2026-07-28/learn/architecture>) — MCP project
2. [возможности серверов](<https://modelcontextprotocol.io/docs/2026-07-28/learn/server-concepts>) — MCP project
3. [инструменты](<https://modelcontextprotocol.io/specification/2026-07-28/server/tools>) — MCP project
4. [ресурсы](<https://modelcontextprotocol.io/specification/2026-07-28/server/resources>) — MCP project
5. [Транспорты](<https://modelcontextprotocol.io/specification/2026-07-28/basic/transports>) — MCP project
6. [Streamable HTTP](<https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/streamable-http>) — MCP project
7. [совместимость версий](<https://modelcontextprotocol.io/specification/2026-07-28/basic/versioning>) — MCP project
8. [Анонс MCP от Anthropic](<https://www.anthropic.com/news/model-context-protocol>) — Anthropic
9. [объявление о передаче в AAIF](<https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation>) — Anthropic
10. [Релиз 2026-07-28](<https://blog.modelcontextprotocol.io/posts/2026-07-28/>) — MCP Lead Maintainers
11. [дорожная карта](<https://blog.modelcontextprotocol.io/posts/mcp-roadmap/>) — MCP Lead Maintainers
12. [Принципы безопасности в спецификации](<https://modelcontextprotocol.io/specification/2026-07-28>) — MCP project
13. [рекомендации по безопасности MCP](<https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices>) — MCP project
14. [Tool use](<https://platform.claude.com/docs/en/agents-and-tools/tool-use/overview>) — Anthropic
15. [исходная публикация о RAG](<https://arxiv.org/abs/2005.11401>) — arXiv
16. [Building effective agents](<https://www.anthropic.com/research/building-effective-agents>) — Anthropic
17. [Обзор Code Mode](<https://developers.cloudflare.com/agents/tools/codemode/>) — Cloudflare
18. [варианты MCP-серверов в Code Mode](<https://developers.cloudflare.com/agents/model-context-protocol/codemode/>) — Cloudflare
19. [GitHub](<https://github.com/github/github-mcp-server>) — GitHub
20. [Playwright](<https://github.com/microsoft/playwright-mcp>) — Microsoft
21. [Context7](<https://github.com/upstash/context7>) — Upstash
22. [Firecrawl](<https://github.com/firecrawl/firecrawl-mcp-server>) — Firecrawl
23. [Figma](<https://developers.figma.com/docs/figma-mcp-server/>) — Figma
24. [Blender](<https://github.com/ahujasid/mcp-for-blender>) — ahujasid / Siddharth
25. [Unity](<https://github.com/CoplayDev/unity-mcp>) — CoplayDev / Aura
26. [@1c-odata/mcp](<https://github.com/hacker-cb/1c-odata/blob/master/packages/mcp/README.md>) — hacker-cb
27. [ВкусВилл](<https://mcp.vkusvill.ru/mcp>) — ВкусВилл
