Что такое MCP

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

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

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

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

Протокол открыт и не привязан к одному вендору 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, чат-клиент, агентная платформа. Оно управляет сессией, вызывает модель и решает, когда дернуть tool.
• MCP Client - компонент внутри host, который говорит с одним или несколькими серверами по протоколу MCP.
• MCP Server - процесс или сервис, который экспонирует resources, tools и prompts. Может быть локальным (файлы на диске) или удалённым (корпоративная API).

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

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

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

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

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

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

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

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

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

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

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

MCP и function calling

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

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

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

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

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

Среда	Роль MCP
Cursor	Встроенные и пользовательские MCP-серверы: файлы, терминал, браузер, сторонние API
Claude Desktop	Официальные коннекторы и community-серверы через claude_desktop_config.json
Zed, Continue, Cline	Поддержка MCP для расширения контекста в редакторе
Корпоративные агенты	Свои серверы поверх внутренних API, тикет-систем, wiki

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

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

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

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

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

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

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

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

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

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

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

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

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

MCP vs RAG и vs кастомные API

Подход	Сильная сторона	Слабая сторона
MCP	Стандартные tools/resources для любого host	Нужна поддержка MCP в клиенте
RAG	Поиск по большим корпусам без полной загрузки в контекст	Не даёт произвольных действий (write, API mutate)
Кастомный API	Полный контроль	Дублирование работы для каждого ИИ-клиента

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

Итог

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

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

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

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

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

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

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

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

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

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

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

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

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

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