Короткий ответ: Чтобы создать MCP-сервер, вы оборачиваете систему или источник данных в протокол Model Context Protocol, чтобы любой совместимый AI-агент мог их вызвать. Работа всегда одна и та же — шесть шагов: выбрать инструменты, ресурсы и промпты, которые сервер будет отдавать; собрать каркас сервера на официальном SDK; реализовать каждый инструмент как типизированную функцию с понятной схемой; выбрать транспорт (stdio для локального, Streamable HTTP для удалённого); добавить аутентификацию и авторизацию, если сервер удалённый; затем протестировать его на реальном клиенте до выката. Сам протокол небольшой и стандартизированный — к марту 2026 года MCP перешагнул 97 миллионов загрузок SDK в месяц и теперь управляется Linux Foundation, где OpenAI, Google и Microsoft выступают со-спонсорами. Сложность не в протоколе. Сложность во всём вокруг него: спроектировать инструменты так, чтобы агент действительно мог ими пользоваться, корректно защитить удалённый сервер и доказать, что всё работает под нагрузкой, прежде чем подключать его к клиентскому агенту.

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

Что такое MCP-сервер на самом деле

MCP-сервер — это программа, которая отдаёт возможности AI-агентам через единый стандартный интерфейс. До MCP каждая команда, желавшая дать агенту инструмент, писала свою разовую интеграцию; MCP заменяет этот хаос «N на M» одним протоколом — именно поэтому он так быстро распространился. Тот же агент, который общается с вашим сервером, может общаться с любым из примерно 9 650 серверов в официальном реестре и любым из ~15 900 репозиториев GitHub с тегом по состоянию на май 2026 года. Концептуальный фон — зачем нужен протокол и какую проблему он решает — мы разбираем в материале о том, что такое Model Context Protocol. Это руководство — про сборку.

Сервер отдаёт три типа возможностей, и правильно их различать — это бо́льшая часть проектирования:


Полезная модель: инструменты — это глаголы, ресурсы — существительные, промпты — рецепты. Большинство серверов опираются в основном на инструменты, добавляют несколько ресурсов и используют промпты экономно. Ошибка новичка — свалить все эндпоинты своего API в инструменты и считать дело сделанным. Хороший MCP-сервер — курируемый, а не исчерпывающий.

До написания кода: определите границы сервера

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

Три вопроса, на которые нужно ответить первыми. Что агенту реально нужно делать? Идите от задачи агента, а не от поверхности вашего API. Агенту поддержки нужны , и — а не зеркало из сорока REST-эндпоинтов один в один. Какие инструменты пишут, а какие только читают? Действия записи (возвраты, удаления, отправки) требуют иных ограждений, чем чтение, и их стоит чётко разделить, чтобы на разрушительных можно было требовать подтверждение или более строгую авторизацию. Какой минимальный набор приносит пользу? Сервер с шестью хорошо названными и хорошо описанными инструментами лучше, чем с шестьюдесятью, между которыми агент не может надёжно выбрать. Это harness engineering на стороне сервера: пространство действий, которое вы отдаёте, — часть рассуждений агента, а не нейтральная труба.

Как создать MCP-сервер шаг за шагом

Когда границы определены, сборка идёт по предсказуемому пути. Официальные SDK (наиболее зрелые — Python и TypeScript) берут на себя обвязку протокола, поэтому бо́льшая часть вашего кода — это собственно логика.

  1. Соберите каркас сервера на официальном SDK. Установите SDK для вашего языка, создайте экземпляр сервера, задайте ему имя и версию. SDK управляет обработкой JSON-RPC-сообщений, согласованием возможностей и жизненным циклом, так что протокол на уровне проводов вы не реализуете.
  2. Опишите каждый инструмент строгой схемой. Для каждого инструмента задайте точное имя, описание в одно предложение, написанное для модели (а не для человека-читателя), и типизированную входную схему. Схема — это ваш контракт: именно она не даёт агенту передать строку там, где нужно целое, и делает инструмент самодокументируемым для клиента.
  3. Реализуйте логику инструмента. Внутри обработчика делайте настоящую работу — обращайтесь к базе, к внутреннему API, выполняйте вычисление — и возвращайте структурированный результат. Держите обработчики тонкими: валидируйте вход, вызывайте существующий сервисный слой, форматируйте вывод. Не зашивайте в MCP-обработчик бизнес-логику, которая нужна и остальной системе.
  4. Добавьте ресурсы и промпты там, где они помогают. Отдавайте контекст только для чтения как ресурсы (запись клиента, документ с политикой), а любую повторяемую многошаговую задачу упакуйте как промпт. Пропустите это, если ваш сервер чисто «про действия»; не каждому серверу нужны все три примитива.
  5. Обрабатывайте ошибки как данные, а не как падения. Когда инструмент падает — плохой ввод, таймаут на стороне зависимости, проблема с правами — возвращайте понятную структурированную ошибку, которую агент может прочитать и восстановиться, а не выбрасывайте необработанное исключение, рвущее соединение. Агенты рассуждают над текстом ошибки: хорошая («заказ не найден — проверьте ID заказа») позволяет агенту исправиться, а стектрейс — нет.
  6. Выберите и подключите транспорт. Решите, работает ли сервер локально рядом с клиентом (stdio) или как сетевой сервис, до которого дотягиваются многие клиенты (Streamable HTTP). Этот выбор задаёт всё в деплое и безопасности, поэтому ему посвящён отдельный раздел ниже.

Это и есть работающий MCP-сервер. От продакшен-уровня его отделяют следующие три раздела: выбор транспорта, слой безопасности и тестирование.

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

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

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

Streamable HTTP, появившийся в редакции спецификации от 18 июня 2025 года, запускает сервер как сетевой сервис, до которого многие клиенты дотягиваются по HTTP. Он заменил старый транспорт HTTP+SSE и теперь является вариантом по умолчанию для всего, что не является чисто локальным. Сервер на этом транспорте — удалённый MCP-сервер, и экосистема явно сходится именно к нему: реальные продукты выкатывают удалённые, доступные по сети серверы. Цена этой досягаемости — вы получаете задачу аутентификации и авторизации, которой у stdio не было.

Правило выбора простое. Делаете инструмент для себя или одной машины разработчика? Берите stdio. Делаете сервер, который будут вызывать продукт, команда или множество агентов по сети? Стройте его на Streamable HTTP с самого начала и считайте работу по безопасности ниже частью сборки, а не отдельным поздним этапом. Прикручивать авторизацию к серверу, который рассчитывал на доверенного локального вызывающего, болезненнее, чем заложить её в первый день.

Как защитить удалённый MCP-сервер

Как только сервер доступен по сети, он становится поверхностью атаки, и спецификация конкретна в том, как его защищать. Редакция от 18 июня 2025 года сделала OAuth 2.1 основой авторизации MCP. Корректно защищённый удалённый MCP-сервер требует PKCE для всех клиентов, использует RFC 9728 (Protected Resource Metadata), чтобы клиенты могли обнаружить, как аутентифицироваться, использует RFC 8414 для метаданных сервера авторизации и RFC 8707 (resource indicators), чтобы выданный токен был привязан к вашему конкретному серверу и не мог быть переигран против другого.

Практический совет от сообщества безопасности однозначен: внедряйте OAuth 2.1 с resource indicators с первого дня, а не откладывайте авторизацию «на потом». Поверхность атаки хорошо изучена, и спецификация даёт ясный путь через динамическую регистрацию клиента и PKCE. Отложить — значит перестраивать модель доверия сервера, когда он уже выкачен.

Аутентификация — только половина работы. MCP-сервер по своей сути — это способ дать языковой модели совершать реальные действия в ваших системах, а значит, он наследует всю проблему prompt injection. Если агент, вызывающий ваш сервер, можно вредоносным содержимым склонить к вызову вашего инструмента , никакая идеальная настройка OAuth вас не спасёт. Продакшен-серверы выдают узко ограниченные токены, разделяют инструменты чтения и записи, требуют явного подтверждения или более строгих проверок на разрушительные действия и логируют каждый вызов инструмента, чтобы плохую последовательность можно было отследить и остановить. Безопасность здесь — не один поток OAuth, а вся цепочка от токена к инструменту и к побочному эффекту.

Тестирование и оценка вашего MCP-сервера

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

Тестируйте на трёх уровнях. Первый — юнит-тестируйте каждый обработчик обычным образом: на заданный вход даёт ли он верный структурированный вывод и верную структурированную ошибку при сбое? Второй — тестируйте сервер на реальном MCP-клиенте: подключите его к настоящему агенту и посмотрите, может ли агент обнаружить ваши инструменты, выбрать нужный и передать корректные аргументы, опираясь только на ваши имена и описания. Здесь и вскрывается расплывчатый дизайн: если агент постоянно выбирает не тот инструмент, чинить нужно описание, а не модель. Третий — гоняйте eval’ы на сквозном поведении: оценённый набор реалистичных задач, которые агент должен выполнить с помощью вашего сервера, чтобы ловить регрессии при добавлении инструмента или смене схемы. Сочетайте это с наблюдаемостью: трассируйте каждый вызов инструмента, его аргументы, задержку и исход, потому что в продакшене сервер падает тихо — по одному плохому вызову за раз, ровно так, как обычно ломаются агентные системы.

Частые ошибки, из-за которых MCP-серверы не доходят до продакшена

Сбои повторяются у разных команд, и почти ни один из них не про протокол.


Как к этому подходит Moai Team

Мы относимся к MCP-серверу как к части поверхности рассуждений агента, а не как к тонкой обёртке над API. Это значит, что мы идём от задачи агента и проектируем небольшой, чётко описанный набор инструментов, разделяя чтение и запись так, чтобы разрушительные действия несли собственные ограждения. Для удалённых серверов мы строим на Streamable HTTP с OAuth 2.1, PKCE и привязанными к ресурсу токенами с первого коммита, потому что прикручивать авторизацию задним числом дороже, чем заложить её сразу. Каждый сбой инструмента мы обрабатываем как структурированные данные, из которых агент может восстановиться, выстраиваем токены и подтверждения вокруг реальности prompt injection, которую наследует любая система с вызовом инструментов, и не считаем сервер готовым, пока вокруг него нет eval’ов и трассировки. Цель — не сервер, который работает, когда мы вызываем его руками. Цель — сервер, которым агент может корректно пользоваться тысячи раз в день, не уходя тихо в сбой.

Часто задаваемые вопросы

Что такое MCP-сервер?

MCP-сервер — это программа, которая отдаёт возможности AI-агентам через Model Context Protocol, единый стандартный интерфейс, заменивший разовые интеграции, которые команды раньше писали под каждый инструмент. Сервер может отдавать три вещи: инструменты (функции, которые агент вызывает для действия), ресурсы (данные в виде файлов, которые агент читает) и промпты (переиспользуемые шаблоны задач). Поскольку протокол стандартизирован — и теперь управляется Linux Foundation при кросс-вендорной поддержке Anthropic, OpenAI, Google, Microsoft и других — любой совместимый агент может работать с любым совместимым сервером.

Как создать MCP-сервер?

Используйте официальный SDK (наиболее зрелые — Python и TypeScript) и пройдите шесть шагов: определите инструменты, ресурсы и промпты, которые агенту реально нужны; соберите каркас сервера на SDK; опишите каждый инструмент строгой типизированной схемой и описанием для модели; реализуйте логику инструмента поверх существующих сервисов; обрабатывайте ошибки как структурированные данные, а не падения; и выберите транспорт — stdio для локального, Streamable HTTP для удалённого. SDK берёт на себя обвязку протокола, поэтому бо́льшая часть кода — это собственно логика инструментов и решения вокруг неё.

В чём разница между транспортами stdio и Streamable HTTP?

stdio запускает сервер как локальный подпроцесс клиента — без сети и без аутентификации; идеально для личных инструментов и утилит разработчика на одной машине, но не масштабируется на многих пользователей. Streamable HTTP, появившийся в спецификации от 18 июня 2025 года, запускает сервер как сетевой сервис, до которого дотягиваются многие клиенты, и это вариант по умолчанию для всего, что выкатывается как продукт. Плата — удалённому серверу нужен слой аутентификации и авторизации (OAuth 2.1 с PKCE и resource indicators), которого локальному stdio-серверу не требуется.

Как защитить удалённый MCP-сервер?

Закладывайте OAuth 2.1 с первого дня. Спецификация MCP от 18 июня 2025 года требует PKCE для всех клиентов, RFC 9728 (Protected Resource Metadata) для обнаружения, RFC 8414 для метаданных сервера авторизации и RFC 8707 (resource indicators), чтобы токены были привязаны к вашему конкретному серверу. Помимо аутентификации, относитесь к серверу как к поверхности с вызовом инструментов, наследующей проблему prompt injection: выдавайте узкие токены, разделяйте инструменты чтения и записи, требуйте подтверждения на разрушительные действия и логируйте каждый вызов, чтобы вредоносную или некорректную последовательность можно было отследить и остановить.

Moai Team создаёт MCP-серверы и агентов, которые ими пользуются, честно — курируемые инструменты, спроектированные под то, как модель действительно рассуждает, OAuth 2.1 и принцип наименьших привилегий с первого коммита, eval’ы и наблюдаемость вокруг всего этого, чтобы оно держалось в продакшене, а не только в демо. Запланируйте звонок.