MCP-сервер - это программа, которая по единому протоколу отдает ИИ-модели набор инструментов, данных и готовых сценариев. Модель сама смотрит, что доступно, и вызывает нужное. Проще говоря: MCP server решает вопрос «как подключить нейросеть к внешнему миру» один раз и для всех клиентов сразу. Ниже разберем архитектуру host-client-server, три типа возможностей, транспорт по stdio и HTTP MCP, а главное - чем MCP protocol отличается от привычного REST API. Навигатор: сначала суть, потом устройство, потом сравнение с API и практика.
TL;DR: MCP-сервер - это компонент протокола Model Context Protocol от Anthropic (ноябрь 2024), построенного на JSON-RPC 2.0. Он выставляет инструменты, ресурсы и промпты в стандартной схеме. ИИ-агент находит их в рантайме и вызывает. В отличие от REST API, где разработчик заранее прописывает каждый вызов, MCP client договаривается с сервером сам.
Что такое MCP-сервер простыми словами?
Это сервис, который переводит любой инструмент на язык, понятный нейросети. Модель подключается и получает список того, что умеет сервер, без чтения документации человеком.
Суть за 40 секунд. MCP (Model Context Protocol) Anthropic выпустила в ноябре 2024 как открытый стандарт. Его прозвали «USB-C для мира ИИ»: одна розетка вместо десятка проводов. Сервер выставляет возможности, а модель подключается к нему через клиент и вызывает функции по стандартной схеме. Ни один вызов не прошит в промпт заранее.
Возьмем бытовой пример. Раньше, чтобы дать ассистенту доступ к базе данных, календарю и файлам, под каждый источник писали отдельную интеграцию. Каждая модель требовала своего кода. Появился новый инструмент - снова пиши обвязку. Сервер убирает эту рутину. Вы описываете возможности один раз, и любой MCP-совместимый клиент, будь то Claude Desktop, Cursor или ваш собственный агент, видит их и работает с ними. По данным <cite index="14-1">официальной спецификации, протокол определяет стандартные механизмы обмена между клиентом и сервером</cite>, поэтому набор инструментов переносится между разными приложениями без переписывания.
Ключевая идея: MCP переносит логику «что можно сделать» на сторону сервера. Модель не хранит список в голове, а спрашивает его в момент задачи. Это и отличает подход от старой схемы с зашитыми функциями.
Как устроена архитектура MCP: host, client, server?
Три роли: хост запускает всю сцену, клиент держит одно соединение, сервер отдает возможности. Между ними идет диалог по JSON-RPC 2.0.
Кто есть кто. <cite index="20-1">MCP работает по модели host-client-server: хост - это ИИ-приложение или сама модель, клиент управляет соединением между хостом и одним или несколькими серверами, а сервер выставляет инструменты, ресурсы и промпты в стандартной схеме, которую агент читает и вызывает.</cite> Один хост поднимает несколько изолированных клиентских сессий.
Разложим MCP client server по полочкам:
| Роль | Что делает | Примеры |
|---|---|---|
| Host (хост) | Запускает ИИ-приложение, создает и координирует несколько клиентских сессий | Claude Desktop, Claude Code, Cursor, ChatGPT, свой агент на LangChain |
| Client (клиент) | Держит одно соединение 1:1 с сервером, ведет согласование протокола и обнаружение возможностей | Встроен в хост, по одному на каждый сервер |
| Server (сервер) | Выставляет инструменты, данные и промпты, выполняет вызовы | GitHub MCP, Postgres MCP, файловый сервер |
Почему клиентов несколько. Каждый сервер получает свой отдельный клиент внутри хоста. Такая изоляция нужна для безопасности: сессия с сервером базы данных не пересекается с сессией файлового сервера. Когда агент подключается к серверу, <cite index="20-1">он получает полную схему всех доступных инструментов - имя, описание, обязательные параметры и ожидаемый результат.</cite> Дальше хост решает, какой инструмент дернуть под конкретный шаг задачи.
Весь обмен идет по JSON-RPC 2.0. Это простой формат запросов и ответов, где у каждого сообщения есть метод и параметры. Именно на нем строится вся коммуникация MCP protocol.
Что MCP-сервер отдает агенту: tool, resource и prompt?
Сервер выставляет три вещи: инструменты для действий, ресурсы для чтения данных и промпты как готовые шаблоны. Модель комбинирует их под задачу.
Три примитива. У сервера ровно три типа возможностей, и это его фундамент. Каждый MCP tool - это функция, которую агент может вызвать: отправить письмо, создать задачу, прочитать строку из базы. Ресурс - это данные для чтения: файл, запись, документ. Промпт - заготовленный сценарий, который сервер предлагает клиенту.
Как это выглядит в цифрах и логике:
| Примитив | Назначение | Кто инициирует | Аналог |
|---|---|---|---|
| Tool (инструмент) | Действие с побочным эффектом | Модель вызывает | Функция, POST-запрос |
| Resource (ресурс) | Чтение данных для контекста | Хост подтягивает | GET-запрос, файл |
| Prompt (промпт) | Готовый шаблон сценария | Пользователь выбирает | Сниппет, макрос |
Разберем механику вызова инструмента. Сначала клиент спрашивает список: метод tools/list. Сервер возвращает каталог со схемами. Потом модель выбирает нужное и шлет tools/call. Вот как выглядит mcp json такого вызова:
{
"jsonrpc": "2.0",
"id": 7,
"method": "tools/call",
"params": {
"name": "get_inventory",
"arguments": { "part_number": "BRK102" }
}
}
Модель тут вызывает функцию напрямую, без разработчика в середине. Это и есть динамическое обнаружение: <cite index="24-1">агент вызывает tools/list и получает каждый доступный инструмент с именем, описанием и схемой ввода - без чтения документации, без установки SDK, без разбора OpenAPI-спецификации.</cite> Разница с ручным подходом огромная, и к ней мы переходим дальше.
Как выглядит полный круг на живой задаче. Пользователь пишет агенту: «найди сотрудников, сменивших отдел за 90 дней, и набросай письмо их руководителям». Это не один вызов, а цепочка. Агент запрашивает tools/list, видит инструмент поиска по кадрам и инструмент черновиков писем. Дальше он в рантайме решает порядок: сначала выбирает данные, потом формирует письма. Контекст между шагами держит сессия, поэтому промежуточный результат не теряется. Разработчик заранее эту логику не прописывал, агент собрал ее сам из доступных возможностей.
Чем MCP отличается от обычного REST API?
REST API статичен: разработчик читает доки и жестко прописывает вызовы. MCP динамичен: агент сам находит инструменты и держит контекст между шагами.
Главное различие. Технически сервер - это тоже вид API. Но когда говорят «mcp api» против «обычного API», сравнивают с REST. И тут подходы противоположны. <cite index="21-1">REST-подключения дают жестко заданные статичные связи, тогда как MCP позволяет агентам подключаться к ресурсам динамически, через согласование в рантайме.</cite> Один говорит на языке разработчика, другой - на языке модели.
Сведем mcp server api и REST в таблицу:
| Критерий | REST API | MCP-сервер |
|---|---|---|
| Кто клиент | Программа, написанная человеком | ИИ-агент, LLM |
| Обнаружение | Разработчик читает доки и хардкодит вызовы | Агент вызывает tools/list в рантайме |
| Состояние | Без состояния, каждый запрос сам по себе | Сессия с состоянием, контекст сохраняется |
| Масштаб интеграций | N клиентов x M инструментов = N x M связей | N + M реализаций, каждый пишет протокол один раз |
| Схема | OpenAPI, свой формат под каждый сервис | Единая схема, переносимая между клиентами |
Три отличия, которые решают все. Первое - обнаружение. С REST разработчик заранее знает, какой эндпоинт дернуть. С MCP <cite index="19-1">модель узнает доступные инструменты в рантайме, вызвав tools/list, тогда как в REST разработчик читает OpenAPI и хардкодит вызовы.</cite> Второе - состояние. <cite index="19-1">REST не хранит состояние: каждый запрос несет весь контекст сам, сервер не помнит прошлых обращений. MCP держит состояние: сессия сохраняет контекст между несколькими вызовами.</cite> Третье - экономика интеграций. Вместо N x M связок получаем N + M: каждая сторона реализует протокол однажды.
Важная оговорка без иллюзий: MCP не заменяет REST. <cite index="20-1">MCP оборачивает REST API, добавляя слой динамического обнаружения и оркестрации сверху. Ваши эндпоинты остаются на месте.</cite> Многие серверы под капотом дергают привычный REST. Но сервер может быть и самостоятельным: читать файлы, ходить в базу, считать - без всякого API снизу.
Как MCP-сервер общается по сети: stdio и HTTP MCP?
Два транспорта: stdio для локального запуска на своей машине и Streamable HTTP для удаленных серверов в облаке. Формат сообщений в обоих один - JSON-RPC.
Транспортный слой. У сервера есть два способа передавать сообщения. Локальный - через stdio. Удаленный - через HTTP. <cite index="11-1">Оба используют один формат JSON-RPC 2.0, поэтому определения инструментов полностью переносимы между локальным и удаленным развертыванием.</cite>
Как выбрать транспорт:
| Транспорт | Где живет | Плюс | Минус |
|---|---|---|---|
| stdio | Локально, дочерний процесс хоста | Быстро, ноль настройки сети | Обычно один клиент на сервер |
| Streamable HTTP | Удаленно, в облаке | Много клиентов, масштаб, OAuth 2.1 | Нужна инфраструктура |
Стандартный ввод-вывод (stdio) - это дефолт для локальных серверов. <cite index="11-1">Хост запускает сервер как дочерний процесс и общается через потоки ввода-вывода. Это быстро, не требует сетевой настройки и идеально для личной разработки, например Postgres MCP на ноутбуке рядом с Claude Desktop.</cite> Минус - такой сервер обычно обслуживает одного клиента.
Для продакшена нужен http mcp. <cite index="8-1">Streamable HTTP появился в спецификации ноября 2025, заменил устаревший транспорт SSE и позволяет запускать серверы как удаленные сервисы.</cite> Сервер выставляет один HTTPS-эндпоинт, принимает POST и GET, подключает OAuth 2.1 для авторизации и держит много клиентов сразу. Именно так серверы деплоят на Cloudflare, AWS и другие облака.
Куда все движется. В <cite index="9-1">кандидате новой спецификации MCP появляется stateless-ядро протокола, фреймворк расширений, механизм Tasks, серверные UI через MCP Apps и усиленная авторизация.</cite> Плюс на горизонте связка с A2A - протоколом общения агентов между собой от Google. MCP превращается из способа подключить один инструмент в фундамент для оркестрации множества агентов.
Кто уже использует MCP и какие серверы есть?
Протокол поддержали основные ИИ-клиенты и десятки готовых серверов. Есть обвязки для баз, репозиториев, облаков, а рядом растет протокол общения агентов A2A.
Экосистема на 2026. За полтора года MCP вышел далеко за рамки локальных подключений. Он работает в продакшене в компаниях любого размера и питает агентские сценарии. Готовые серверы закрывают типовые источники: GitHub через свой сервер отдает работу с репозиториями поверх REST GitHub, Postgres дает доступ к базе, файловые серверы работают с диском. Клиентская сторона тоже широкая.
Кто с чем работает:
| Слой | Примеры | Транспорт |
|---|---|---|
| Клиенты (хосты) | Claude Desktop, Claude Code, Cursor, ChatGPT, свои агенты | stdio и HTTP |
| Готовые серверы | GitHub, Postgres, файловая система, поиск | stdio локально |
| Облачные серверы | Развертывание на Cloudflare, AWS | Streamable HTTP |
Отдельно стоит связка с агентами. <cite index="20-1">A2A (Agent-to-Agent Protocol) от Google, апрель 2025, дает агентам находить и общаться друг с другом через Agent Cards по well-known URL.</cite> MCP отвечает за связь агента с инструментами и данными, A2A - за связь агентов между собой. Вместе они образуют каркас для мультиагентных систем, и <cite index="8-1">во втором полугодии 2026 к этому добавляются stateless-операции и автообнаружение через MCP Server Cards.</cite>
Что это значит на практике. Если вы строите ИИ-продукт, ставку стоит делать на MCP как слой интеграции по умолчанию. Инструмент, обернутый один раз, переиспользуется во всех клиентах и переживает смену модели.
Когда MCP нужен, а когда хватит обычного API?
MCP оправдан, когда клиент - это ИИ-агент, инструментов много и они переиспользуются между приложениями. Для фиксированной автоматизации проще прямой REST-вызов.
Честный выбор. Не каждой задаче нужен свой сервер. <cite index="18-1">MCP дает агентам обнаружение инструментов в рантайме и контекст с состоянием, а API дают разработчику прямой программный контроль. MCP стоит брать, когда в ИИ-процесс входят три и больше интеграций, а API - для одноцелевых скриптов автоматизации.</cite>
Сильные стороны сервера (с пояснением, а не списком ради списка):
- Одна сборка на всех. <cite index="17-1">Собрал сервер один раз, и любой MCP-совместимый клиент его использует. Никакой интеграции под каждого провайдера.</cite> Экономит недели.
- Нет «налога на контекст». При обычном function calling <cite index="17-1">каждое определение инструмента приходится класть в каждый запрос, это ест токены и место в контексте. С 50+ инструментами это дорого и вредит модели. MCP решает это: инструменты живут на сервере и обнаруживаются по запросу.</cite>
- Изоляция доступа. Отдельный клиент на каждый сервер - естественная граница безопасности.
Слабые стороны, без замалчивания:
- Сложнее наблюдаемость. <cite index="22-1">Сессии с состоянием и динамический выбор инструментов усложняют мониторинг: инструментарий пока менее зрелый.</cite>
- Комплаенс требует предсказуемости. В регулируемых отраслях нужно доказать, к каким данным был доступ и почему. Жесткие вызовы REST дают простой аудит, а поведение агента вносит вариативность.
- Избыточность для простого. Крон, который раз в час тянет метрику с одного эндпоинта, не выигрывает от обнаружения и сессий. Прямой REST проще и быстрее.
Вывод простой. Есть ИИ-агент, много источников и многошаговые сценарии - берите MCP. Есть один известный эндпоинт и фиксированная логика - хватит REST.
«Ребят, это работает. GoBanana я собрал за 6-8 часов, и он принес 12 миллионов рублей. Скорость решает. MCP - это как раз про скорость: подключил инструмент по стандарту один раз, и его видит любой агент. Не нужно каждый раз писать интеграцию заново. Мотаете на ус потихонечку». Максим Наговицын, основатель VibeCoderz
Как собрать свой первый MCP-сервер?
План на вечер: берете SDK, описываете пару инструментов, запускаете по stdio для Claude Desktop, потом при желании выносите на Streamable HTTP для удаленного доступа.
Практика по шагам. Сервер собирается быстрее, чем кажется. Логика такая: описать инструменты, поднять транспорт, подключить клиент. Для вайбкодера это задача на один заход в Cursor или Windsurf.
- Ставите SDK. Есть официальные библиотеки под Python и TypeScript, а также фреймворки вроде FastMCP, которые убирают рутину.
- Описываете mcp tool. Для каждого инструмента задаете имя, описание и схему входных параметров. Описание читает модель, поэтому пишите его понятно.
- Поднимаете транспорт stdio. Для локального теста хост запустит сервер как дочерний процесс. Прописываете сервер в конфиг Claude Desktop или Cursor.
- Проверяете обнаружение. Клиент дергает
tools/list, видит ваши инструменты, вызываетtools/call. Если ответ вернулся - сервер живой. Проверить схему инструментов вручную помогает MCP Inspector - официальная утилита для отладки, показывает список и результат вызова без написания клиента. - Выносите на HTTP при необходимости. Для удаленного доступа переключаете транспорт на Streamable HTTP, добавляете OAuth 2.1 и деплоите на облако.
Что важно на старте. Начните с двух-трех инструментов, а не с двадцати. Хорошее описание инструмента важнее их количества: модель выбирает по тексту описания. И помните про безопасность: <cite index="11-1">июньское обновление спецификации 2025 года классифицирует серверы как OAuth Resource Servers и требует от клиентов Resource Indicators по RFC 8707, чтобы вредоносный сервер не получил токен, предназначенный другому.</cite>
Подобрать среду для сборки помогает каталог IDE и инструментов на vibecoderz.ru/ide. Для работы с MCP из редактора подойдут Cursor, Claude Code и Windsurf.
Частые вопросы про MCP-сервер
сервер - это то же самое, что API? Технически сервер - это разновидность API. Но по смыслу он ближе к стандарту поверх API. Обычный REST дает статичные вызовы для программ, а MCP дает динамическое обнаружение и сессии для ИИ-агентов. Часто сервер внутри вызывает тот же REST.
Нужно ли переносить все свои function calling в MCP? Нет. <cite index="17-1">Если у вас простой чат-бот с парой инструментов на одном провайдере, function calling работает нормально. MCP берут, когда нужна переносимость между провайдерами, инструментов много или требуется корпоративная авторизация.</cite>
Чем MCP client отличается от MCP server? Клиент держит соединение и запрашивает возможности, сервер их выставляет и выполняет. Один хост поднимает много клиентов, по одному на каждый сервер. Это связка mcp client server, где стороны говорят по JSON-RPC.
Что такое http mcp и когда он нужен? Это транспорт Streamable HTTP для удаленных серверов. Нужен, когда сервер живет в облаке и обслуживает много пользователей. Для локального теста на своей машине хватает stdio.
Может ли сервер работать без REST под капотом? Да. Сервер может сам читать файлы, ходить в базу и считать данные. Тогда сервер и есть сервис, отдельного API снизу нет.
Кто выпустил MCP protocol? Anthropic, в ноябре 2024 года, как открытый стандарт. С тех пор его поддержали Claude, Cursor, ChatGPT и множество своих агентов.
Глоссарий
MCP (Model Context Protocol) - открытый стандарт от Anthropic для подключения ИИ-моделей к внешним инструментам и данным.
MCP-сервер - программа, которая выставляет инструменты, ресурсы и промпты по протоколу MCP.
MCP client - компонент внутри хоста, который держит соединение с одним сервером и обнаруживает его возможности.
Host (хост) - ИИ-приложение, которое запускает клиентов и координирует работу, например Claude Desktop.
JSON-RPC 2.0 - формат сообщений, на котором строится вся коммуникация MCP: метод плюс параметры.
Tool (инструмент) - функция сервера, которую модель вызывает через tools/call.
Resource (ресурс) - данные для чтения, которые сервер отдает как контекст.
stdio - локальный транспорт: хост запускает сервер как дочерний процесс и общается через потоки ввода-вывода.
Streamable HTTP - сетевой транспорт для удаленных серверов, ввели в спецификации ноября 2025.
A2A - протокол общения агентов между собой от Google, дополняет MCP на уровне координации.
С чего начать
Хотите разобраться в инструментах вайбкодинга и собрать свой стек - смотрите каталог IDE и AI-инструментов на vibecoderz.ru/ide. Там собраны редакторы, агенты и сервисы с обзорами и ссылками.
Нужна помощь с запуском своего продукта или разбор архитектуры под задачу - напишите Максиму на t.me/maxnagovitsyn. Разберет ваш случай по опыту реальных проектов.
Обновлено: июль 2026 | VibeCoderz - каталог AI-инструментов и IDE для вайбкодеров