Что такое MCP

MCP - открытый протокол, который стандартизирует подключение ИИ-ассистентов к внешним данным и инструментам. Вместо отдельной интеграции под каждый сервис (GitHub, база данных, CRM, файловая система) разработчик поднимает MCP-сервер, а клиент - Cursor, Claude Desktop, Zed и другие - подключается к нему по единому контракту. Для бизнеса это конкретная экономия: интеграции ИИ с рабочими системами обходятся дешевле и делаются быстрее, а доступ агента к данным остаётся под явным контролем компании. Ниже - что такое MCP, как устроена архитектура и зачем протокол нужен в продакшене.

Определение простыми словами

Model Context Protocol - это спецификация обмена между ИИ-приложением и внешним источником контекста. Сервер может отдавать:

• Resources - читаемые данные: файлы, записи БД, документы API
• Инструменты - действия, которые модель может вызвать: запрос к API, SQL, поиск по индексу
• Промпты - готовые шаблоны промптов для типовых сценариев

Протокол открыт и не привязан к одному вендору LLM. Хост решает, какую модель использовать; MCP-сервер решает, какие данные и инструменты предоставить. Связь идёт по JSON-RPC 2.0 - тот же стиль, что у многих API, с транспортом через stdio, HTTP или SSE.

Идея Anthropic (ноябрь 2024): убрать «зоопарк» кастомных плагинов и дать экосистеме один способ подключать контекст к агентам.

Архитектура: host, client, server

Типичная схема из трёх ролей:

┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│  MCP Host   │────▶│ MCP Client  │────▶│ MCP Server  │
│ (Cursor,    │     │ (внутри     │     │ (GitHub,    │
│  Claude)    │     │  приложения)│     │  Postgres…) │
└─────────────┘     └─────────────┘     └─────────────┘

• MCP Host - приложение с LLM: IDE, чат-клиент, агентная платформа. Оно управляет сессией, вызывает модель и решает, когда дернуть инструмент.
• MCP Client - компонент внутри host, который говорит с одним или несколькими серверами по протоколу MCP.
• MCP Server - процесс или сервис, который экспонирует resources, инструменты и промпты. Может быть локальным (файлы на диске) или удалённым (корпоративная API).

Один host может держать несколько клиентов - по одному на каждый MCP-сервер. Например, в Cursor одновременно работают серверы для файловой системы, браузера, GitHub и пользовательские MCP из конфига.

Что даёт MCP на практике

Единый контракт вместо N интеграций

До MCP каждый продукт писал свои коннекторы: свой формат для «прочитать файл», свой для «вызвать API». MCP фиксирует:

• как объявляются инструменты (имя, схема параметров, описание)
• как передаются результаты
• как запрашиваются ресурсы и подписки на изменения

Один и тот же MCP-сервер для PostgreSQL может обслуживать и Claude Desktop, и другой host, если тот поддерживает протокол.

Безопасность и границы доступа

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

Локальные и облачные сценарии

• Локально - stdio-транспорт: host запускает бинарник сервера как дочерний процесс (типично для IDE и desktop-клиентов).
• Удалённо - HTTP/SSE: общий MCP-сервер в VPN или облаке для всей команды.

Оба варианта описаны в спецификации; выбор зависит от политики безопасности и того, где живут данные.

MCP и вызов функций

Function calling (tool use) - механизм на стороне LLM: модель возвращает структурированный запрос «вызови функцию X с аргументами Y». MCP - слой ниже и шире: он стандартизирует, откуда берутся эти функции и данные, как они регистрируются и как хост с ними общается.

Схема взаимодействия:

1. Host подключается к MCP-серверу и получает список инструментов.
2. Список передаётся модели в формате, который понимает провайдер (OpenAI tools, Anthropic tools и т.д.).
3. Модель выбирает инструмент; host выполняет вызов через MCP client → server.
4. Результат возвращается в контекст модели для следующего шага.

MCP не заменяет рассуждения модели - он унифицирует «проводку» между агентом и внешним миром.

Где MCP уже используется

Сообщество публикует готовые серверы: GitHub, Google Drive, Slack, Puppeteer, SQLite, Postgres, Brave Search и сотни других в реестрах вроде modelcontextprotocol/servers на GitHub.

Как написать или подключить MCP-сервер

Минимальный путь для разработчика:

1. Выбрать SDK: официальные библиотеки есть для TypeScript, Python, C#, Java и других языков.
2. Описать инструменты и resources в коде сервера (имя, inputSchema, handler).
3. Запустить сервер с транспортом stdio или HTTP.
4. Добавить конфиг в host (в Cursor - .cursor/mcp.json или настройки IDE).

Пример логики инструмента на Python (упрощённо):

@server.tool()
async def get_weather(city: str) -> str:
    """Текущая погода для города."""
    return await weather_api.fetch(city)

Host при старте сессии запрашивает возможности сервера; модель видит get_weather с описанием и JSON-схемой параметра city.

Для команд без своей разработки часто хватает готового сервера из реестра + правки конфига и секретов (API keys через env, не в репозитории).

Ограничения и на что смотреть

MCP решает проблему стандартизации подключений, но не:

• качество рассуждений модели
• оркестрацию сложных многошаговых workflow (это уровень агентных фреймворков)
• авторизацию между пользователями (нужен отдельный слой OAuth, RBAC на сервере)

На практике стоит учитывать:

• Латентность - каждый вызов инструмента - это round-trip; для цепочек из 10+ вызовов нужен бюджет по времени и токенам.
• Версионирование - серверы и host должны совпадать по версии спецификации (сейчас активно развивается 2025-03 и новее).
• Надёжность - падение MCP-сервера обрывает доступ к данным; для продакшена нужны health checks и запасной вариант.

MCP против RAG и кастомных API

В зрелых системах часто MCP + RAG: RAG для знаний из документов, MCP инструменты - для актуальных запросов к БД, тикетам, деплою.

Кому и когда MCP не подходит

MCP не решает всё и нужен не всем прямо сейчас:

• Один сценарий в одном закрытом продукте. Если весь ИИ-сценарий живёт внутри одного инструмента со встроенными интеграциями (без своих серверов и нескольких host), протокол добавляет инфраструктуру без ощутимой выгоды.
• Нет ресурса на поддержку сервера. MCP-сервер - это отдельный процесс, который нужно разворачивать, обновлять и мониторить. Без выделенного разработчика или подрядчика на сопровождение риск выше пользы.
• Один канал доступа к данным, и расширять его не планируется. Если под конкретную задачу уже есть единственная интеграция, писать под неё MCP-сервер - лишняя работа.
• Нужна гарантия результата, а не инструмент подключения. MCP стандартизирует доступ к данным и функциям, но не отвечает за качество ответов модели и не заменяет тестирование сценария перед продакшеном.

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

Итог

MCP - открытый протокол контекста для ИИ-агентов: host подключается к серверам, получает resources и инструменты, модель вызывает их через единый контракт. Это снижает стоимость интеграций, упрощает перенос сценариев между Cursor, Claude Desktop и другими клиентами и даёт явные границы доступа к данным.

Для разработчика разумный порядок: начать с готовых community-серверов под ваш стек, затем вынести внутренние API в свой MCP-сервер, если одни и те же инструменты нужны в нескольких host-приложениях.

Если нужна помощь с разработкой, внедрением ИИ или сопровождением сайта под вашу задачу - напишите мне.

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

Чем MCP отличается от обычного REST API?

REST API - это интерфейс конкретного сервиса под ваши HTTP-запросы. MCP - протокол между ИИ-host и «адаптером» к таким сервисам: он описывает, как host открывает список инструментов, вызывает их и читает resources в формате, понятном агенту. Один MCP-сервер может оборачивать REST API GitHub или Jira; host не пишет отдельную интеграцию под каждый продукт.

Нужен ли MCP, если я использую только один чат (например, ChatGPT)?

Если весь сценарий живёт в одном закрытом продукте с встроенными плагинами - не обязательно. MCP окупается, когда вы используете несколько host (IDE + desktop + свой агент), хотите переиспользовать одни и те же инструменты или держите чувствительные данные на своём сервере с явным контролем доступа.

Безопасно ли подключать MCP-серверы к рабочим данным?

Зависит от сервера и конфигурации. Доверенные серверы от сообщества с открытым кодом, доступ только на чтение и секреты через переменные окружения - базовый минимум. Для продакшена: отдельный процесс, минимальные права (минимум привилегий), аудит вызовов инструментов, не давать агенту write-доступ без подтверждения человека.

Можно ли использовать MCP с локальными моделями (Ollama, LM Studio)?

Да, если host поддерживает и MCP, и ваш локальный провайдер. MCP не привязан к облачному API - он поставляет контекст и инструменты; модель может быть локальной. Ограничение на стороне host: не все клиенты одинаково хорошо совмещают local LLM и полный набор MCP-инструментов.

С чего начать настройку MCP в Cursor?

1. Откройте настройки MCP в Cursor (или файл .cursor/mcp.json в проекте).
2. Добавьте готовый сервер из документации (например, filesystem, GitHub) с командой запуска и env для токенов.
3. Перезапустите Cursor и проверьте, что сервер в статусе connected.
4. В чате агента явно попросите использовать инструмент - убедитесь, что вызов проходит и результат попадает в ответ.

Дальше имеет смысл добавить один кастомный сервер под вашу внутреннюю API - так вы поймёте полный цикл без переписывания всей интеграционной логики под каждый инструмент.

Термины в статье

MCP — Model Context Protocol — протокол контекста модели

промпты — prompts — тексты-инструкции или запросы к модели

LLM — Large Language Model — большая языковая модель

SSE — Server-Sent Events — однонаправленный поток событий от сервера к браузеру по HTTP

function calling — model returning structured calls to functions — модель возвращает структурированные вызовы функций

VPN — Virtual Private Network — защищённый туннель к сети через интернет

латентность — latency — задержка до получения ответа

RAG — Retrieval-Augmented Generation — генерация с дополненным поиском

REST API — HTTP API that exposes resources via URLs and verbs — HTTP API: ресурсы через URL и методы GET/POST и т.д.

Jira — Atlassian tool for issues, sprints, and delivery tracking — инструмент Atlassian для задач, спринтов и поставки