MCP-серверы: обзор и как выбрать под задачу

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

Если вы только начинаете знакомство с протоколом, полезно сначала прочитать что такое MCP простыми словами — здесь мы идём на шаг дальше и сравниваем готовые серверы.

Что такое MCP-сервер за одну минуту

MCP (Model Context Protocol) — открытый протокол, который Anthropic представила в конце 2024 года и передала сообществу. Он описывает единый способ, которым языковая модель может обращаться к внешним данным и действиям: файлам, базам, API, поисковикам. Раньше под каждую интеграцию писали свой «клей», теперь достаточно поднять MCP-сервер, и любой совместимый клиент — Claude Desktop, IDE, собственный агент — подключается к нему по одному стандарту.

MCP-сервер — это программа, которая говорит на языке протокола и предоставляет клиенту набор возможностей. Клиент (host) запускает или подключается к серверу, узнаёт, что тот умеет, и передаёт модели список доступных инструментов. Дальше модель сама решает, когда их вызвать. Архитектура строго клиент-серверная: один клиент может держать соединения сразу с несколькими серверами, комбинируя, скажем, доступ к файловой системе и к базе данных.

Из чего состоит сервер: инструменты, ресурсы и промпты

Любой MCP-сервер выставляет наружу три типа примитивов, и понимание разницы между ними сразу помогает оценить, подходит ли сервер под задачу.

Инструменты (tools) — это действия, которые модель может выполнить: отправить запрос к API, записать файл, выполнить SQL. Именно инструменты дают агенту «руки». Ресурсы (resources) — это данные, которые сервер отдаёт для чтения: содержимое файла, строки таблицы, документ. Их подтягивают в контекст, но они не меняют мир. Промпты (prompts) — заготовленные шаблоны запросов, которые сервер предлагает клиенту как готовые сценарии. На практике большинство популярных серверов делают упор именно на инструменты, но при выборе стоит смотреть, отдаёт ли сервер ещё и ресурсы — от этого зависит, насколько удобно будет наполнять контекст.

Транспорты: stdio и Streamable HTTP

Транспорт — это способ, которым клиент и сервер обмениваются сообщениями. Сообщения всегда кодируются в формате JSON-RPC, а вот канал доставки бывает двух видов, и от выбора зависит, где сервер запускается и как масштабируется.

stdio — локальный запуск

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

Streamable HTTP — удалённый и многопользовательский

Второй транспорт, Streamable HTTP, превращает сервер в самостоятельный веб-сервис с одним HTTP-эндпоинтом, который принимает POST и GET. Он умеет обслуживать сразу много клиентов, поддерживает потоковую передачу через Server-Sent Events, сессии и возобновление прерванного соединения. Это выбор для облачных серверов, командных развёртываний и любых сценариев, где сервер должен жить отдельно от клиента. Важная деталь безопасности: такой сервер обязан проверять заголовок Origin и при локальном запуске слушать только localhost — иначе он открыт для атак через DNS-rebinding.

Отдельно стоит запомнить: старый транспорт HTTP+SSE, который встречается в статьях 2024 года, признан устаревшим и заменён на Streamable HTTP начиная со спецификации от 26 марта 2025 года. Актуальная стабильная версия протокола на середину 2026 года — 2025-06-18, и сообщество уже готовит следующий релиз. Если документация сервера всё ещё описывает отдельные эндпоинты SSE и POST, это признак, что проект не обновлялся.

Официальные референс-серверы

У протокола есть набор эталонных серверов, которые поддерживает сама команда MCP. Они небольшие, хорошо задокументированы и служат образцом реализации, а не готовым продакшн-решением. На сегодня их семь: Filesystem — безопасные операции с файлами и настраиваемым доступом; Git — чтение, поиск и изменение git-репозиториев; Fetch — загрузка веб-страниц и их конвертация в удобный для модели вид; Memory — постоянная память на основе графа знаний; Sequential Thinking — пошаговое рассуждение над сложными задачами; Time — работа со временем и часовыми поясами; и Everything — демонстрационный сервер, показывающий сразу все примитивы протокола.

Важный нюанс: раньше в этом же репозитории лежали серверы для GitHub, GitLab, Slack, Google Drive, PostgreSQL и десятков других сервисов. Их вынесли в архив, а поддержку передали вендорам и сообществу. Так, официальный сервер Slack сейчас ведёт компания Zencoder, а поиск Brave заменён на официальный сервер от самого сервиса. Поэтому искать интеграцию под конкретный продукт нужно не в эталонном репозитории, а в реестре.

Популярные серверы под реальные задачи

Чтобы обзор был полезным, разложим самые востребованные серверы по типам задач.

Разработка и код. Официальный сервер GitHub даёт агенту доступ к репозиториям, issue и pull request — это база для ассистента-программиста. Локальные Filesystem и Git закрывают работу с кодом на своей машине. Если вы уже работаете в терминале, посмотрите наш практический гайд по Claude Code, где такие серверы подключаются в пару команд.

Данные и браузер. Playwright и Puppeteer позволяют модели управлять реальным браузером — открывать страницы, кликать, заполнять формы. Firecrawl и Fetch специализируются на извлечении и очистке веб-контента для последующего анализа. Это связка для парсинга, мониторинга и веб-автоматизации.

Продуктивность и знания. Серверы Notion, Slack и Google Drive подключают ассистента к рабочим документам, переписке и файлам команды — именно они превращают модель из «умного чата» в помощника по внутренним данным. Похожий сценарий с CRM и сайтом мы подробно разбирали в заметке MCP: подключаем ИИ к сайту и CRM.

Базы данных и поиск. Серверы для PostgreSQL и Supabase дают агенту безопасный доступ к SQL, а векторные хранилища вроде Pinecone нужны для семантического поиска и RAG-сценариев. Отдельная категория — агрегаторы: сервер Zapier открывает разом тысячи внешних приложений через один интерфейс, что удобно, когда точечного сервера под нужный сервис пока нет.

Как выбрать сервер под задачу

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

Локально или в облаке? Если данные и инструменты на вашей машине и сервером пользуетесь только вы — берите вариант на stdio, он проще и быстрее. Если сервер нужен команде или должен жить в облаке — ищите реализацию на Streamable HTTP.

Кто поддерживает проект? Официальный сервер от вендора сервиса или из реестра предпочтительнее случайного репозитория с парой звёзд. Смотрите на дату последнего обновления, число открытых issue и то, под какую версию спецификации заявлена поддержка.

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

Что именно он выставляет? Загляните в список инструментов и ресурсов до подключения. Иногда сервер обещает интеграцию с сервисом, но на деле отдаёт две-три операции, которых вам не хватит. Лишние же инструменты раздувают контекст и повышают риск ошибочных вызовов.

Реестр и вопросы безопасности

Главная точка входа для поиска серверов сегодня — официальный реестр MCP (registry.modelcontextprotocol.io), запущенный в 2025 году. Это каталог, куда вендоры и сообщество публикуют серверы с описанием, способом установки и метаданными. Реестр удобно использовать как отправную точку, но он не гарантирует качества или безопасности конкретной записи — проверку по-прежнему делаете вы.

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

Вывод

Выбор MCP-сервера — это не поиск «самого мощного», а подбор инструмента под конкретную задачу и модель доверия. Определитесь с транспортом (локальный stdio или облачный Streamable HTTP), отдавайте предпочтение официальным и активно поддерживаемым серверам, проверяйте набор инструментов и объём прав, а начинать поиск удобнее с официального реестра. Эталонные серверы вроде Filesystem, Git и Fetch хороши для старта и как образец, а под рабочие сценарии почти всегда найдётся специализированный сервер от вендора. И если готового решения нет или нужен полный контроль — протокол устроен так, что свой сервер поднимается за вечер.