Протокол контекста модели (MCP): Полное руководство

Компания Anthropic представила протокол контекста модели (Model Context Protocol, MCP) в ноябре 2024 года.

Протокол был разработан Махешем Мурагом (Mahesh Murag) в составе команды Anthropic. Полная официальная документация доступна онлайн. В настоящее время MCP полностью реализован в виде SDK на Python и TypeScript.

Махеш Мураг также провёл подробный воркшоп на тему «Создание агентов с использованием протокола контекста модели» в рамках конференции AI Engineer Summit.

Конечно! Твой перевод уже очень качественный, стиль соответствует оригиналу, структура чётко передаёт смысл. Ниже — предложения по улучшению и стилистическому выравниванию, чтобы текст стал чуть плавнее, профессиональнее и ближе к тону технической статьи для блога.

Контекст — ключевой элемент

Базовые возможности генеративной модели ИИ определяются её предварительным обучением, используемыми данными и архитектурой. Однако чтобы такие модели работали точнее и выдавали более уместные и связные результаты под конкретную задачу, им необходимо предоставить качественный контекст.

В данном случае контекст — это информация, на основе которой модель формирует релевантные и логически связанные ответы. Контекст определяет, как модель понимает и продолжает диалог, завершает текст или генерирует изображение.

Форма подачи контекста зависит от типа модели и решаемой задачи:

1. Текстовые модели (например, GPT, DeepSeek, LLaMA) получают контекст через:

   • Подсказку (prompt) — входной текст или запрос, направляющий ответ модели.
   • Окно токенов — количество токенов, которое модель способна удерживать в рабочей памяти (например, GPT-4 Turbo поддерживает до ~128K токенов).
   • Историю диалога — в чат-ботах предыдущие сообщения помогают поддерживать контекст в диалогах с несколькими репликами.
   • Дополнение через извлечение (RAG) — динамически извлекаемый контекст из внешних источников, повышающий точность ответов.

2. Мультимодальные и генеративные модели изображений (например, DALL·E, Gemini) получают контекст через:

   • Текстовые описания — текстовый запрос задаёт направление генерации изображения.
   • Визуальный контекст — при наличии изображения модель сначала анализирует его содержимое.
   • Кросс-модальный контекст — при объединении текста и изображений модель учитывает оба типа данных для создания осмысленного результата.

3. Модели Генерации кода (например, Codex, DeepSeek-Coder) получают контекст через:

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

4. Модели Обработки речи и аудио (например, Whisper, AudioPaLM) получают контекст через:

   • Аудиосегменты — ранее произнесённая речь или музыка задаёт основу для следующего фрагмента.
   • Лингвистические и акустические особенности — такие как тон, скорость и интонация, влияющие на распознавание и генерацию.

В итоге контекст — это ключевой элемент, позволяющий генеративному ИИ выдавать уместные и согласованные результаты. Чем лучше организовано управление контекстом, тем выше качество работы модели.

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

https://www.anthropic.com/engineering/building-effective-agents

Каждый источник данных (сервер) реализуется по-своему — например, в виде open source-пакета в отдельной кодовой базе, а не как универсальный интерфейс обмена сообщениями, доступный любому клиенту. Иногда такие источники оформлены как JSON-RPC сервисы, но всё равно отсутствует единый стандарт, по которому модель ИИ (клиент) могла бы искать и запрашивать нужные данные. Это и создаёт фрагментацию.

До появления MCP построение ИИ-систем часто сопровождалось следующими трудностями:

• Индивидуальные интеграции под каждое приложение, чтобы подключиться к необходимому контексту — это приводило к дублированию работы.
• Разнородная логика промтов и различные методы доступа к инструментам и данным в рамках разных команд и компаний.
• Проблема "N на M" — когда множество клиентских приложений должно было взаимодействовать с множеством серверов и инструментов. В результате возникала сложная сеть интеграций, каждая из которых требовала отдельной реализации.

Протокол контекста модели (MCP) решает проблему фрагментированного доступа к данным

Model Context Protocol (MCP) предлагает открытый стандарт для подключения ИИ-систем к источникам данных и инструментам — таким как репозитории, бизнес-приложения и среды разработки. Вместо множества разрозненных интеграций используется единый протокол, обеспечивающий взаимозаменяемость между ИИ-клиентами и серверами.

Благодаря этому MCP предоставляет унифицированный способ для приложений:

• передавать языковым моделям контекстную информацию;
• открывать доступ к инструментам и функциям, доступным ИИ-системе;
• строить модульные интеграции и автоматизированные рабочие процессы.

Протокол использует сообщения в формате JSON-RPC 2.0 для установления связи между следующими компонентами:

• Хостами — LLM-приложениями, инициирующими соединение;
• Клиентами — коннекторами внутри хоста;
• Серверами — службами, предоставляющими контекст и функциональные возможности.

На сегодняшний день MCP поддерживается рядом популярных ИИ-инструментов, включая:

• Cursor
• Windsurf (Codium)
• Cline (расширение для VS Code)
• Claude Desktop
• Claude Code

MCP частично вдохновлён Language Server Protocol (LSP) — стандартом, который описывает, как реализовать поддержку языков программирования во всей экосистеме средств разработки. Аналогичным образом MCP стандартизирует способ интеграции дополнительного контекста и инструментов в экосистему ИИ-приложений.

Архитектура MCP

Model Context Protocol (MCP) использует архитектуру клиент–хост–сервер, где каждый хост может запускать несколько экземпляров клиентов одновременно.

• Такой подход позволяет гибко интегрировать возможности искусственного интеллекта в различные приложения, при этом сохраняя чёткие границы безопасности и изолируя зоны ответственности.
• Основанный на JSON-RPC, MCP представляет собой сессионный протокол с сохранением состояния, разработанный для обмена контекстом и координации генерации (sampling) между клиентами и серверами.

https://spec.modelcontextprotocol.io/specification/2024-11-05/architecture/

Хост

Хост-процесс выполняет роль контейнера и координатора. Его задачи включают:

• создание и управление несколькими экземплярами клиентов;
• контроль прав доступа и жизненного цикла клиентов;
• применение политик безопасности и требований согласия;
• обработку решений, связанных с авторизацией пользователей;
• координацию интеграции с ИИ/LLM и процессов генерации (sampling);
• управление агрегацией контекста между клиентами.

Клиенты

Каждый клиент создаётся хостом и устанавливает изолированное соединение с сервером. Он:

• устанавливает отдельную сессионную (stateful) сессию для каждого сервера;
• выполняет согласование протокола и обмен информацией о возможностях;
• перенаправляет протокольные сообщения в обоих направлениях;
• управляет подписками и уведомлениями;
• поддерживает границы безопасности между серверами.

Одно приложение-хост может управлять несколькими клиентами. При этом каждый клиент связан с конкретным сервером по принципу один к одному (1:1).

Клиенты MCP — это ИИ-приложения или агенты, которым требуется доступ к внешним системам, инструментам или источникам данных. Среди примеров — собственные приложения компании Anthropic, а также Cursor, Windsurf и агенты, такие как Goose.

Ключевая характеристика MCP-клиента — его совместимость с протоколом, то есть способность использовать стандартизированные интерфейсы, определённые MCP:

• подсказки (prompts),
• инструменты (tools),
• ресурсы (resources).

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

В контексте инструментов: языковая модель внутри клиентского приложения сама определяет, когда и какие инструменты сервера нужно вызывать.

Для ресурсов: клиент *контролирует, как использовать данные, предоставленные сервером.

Подсказки (prompts) считаются инструментами, управляемыми пользователем, и вызываются вручную через интерфейс клиента.

Серверы

Серверы предоставляют специализированный контекст и функциональность. Они:

• открывают доступ к ресурсам, инструментам и промтам через примитивы MCP;
• работают независимо, с чётко определённой зоной ответственности;
• инициируют генерацию (sampling) через интерфейсы клиента;
• соблюдают политики безопасности и ограничения доступа;
• могут быть реализованы как локальные процессы, так и удалённые сервисы.

Серверы MCP действуют как обёртки или посредники, обеспечивая стандартизированный способ подключения к внешним системам, инструментам и источникам данных. MCP-сервер может, например, предоставлять доступ к базам данных, CRM-системам (таким как Salesforce), локальным файловым системам или системам контроля версий вроде Git.

Задача разработчика сервера — открыть доступ к инструментам, ресурсам и промтам в формате, совместимом с любым MCP-клиентом. После реализации такой сервер может быть использован любым клиентом MCP, что решает проблему “N на M”, устраняя необходимость индивидуальных интеграций между клиентами и серверами.

Для:

• Инструментов (tools): сервер описывает доступные функции и их назначения, чтобы языковая модель клиента могла определить, когда их использовать.
• Ресурсов (resources): сервер описывает доступные данные и при необходимости может создавать или извлекать их.
• Подсказок (prompts): сервер предоставляет шаблоны типовых взаимодействий, которые клиент может запускать от имени пользователя.

Протокол MCP выполняет роль унифицированного коммуникационного слоя между клиентами и серверами, стандартизируя структуру и формат обмена запросами и ответами. Такое разделение обязанностей даёт ряд преимуществ:

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

В итоге взаимодействие между MCP-клиентами и серверами — это стандартизированная модель, в которой клиенты используют открытые сервером возможности через общий язык протокола. Это делает экосистему ИИ-приложений более гибкой, масштабируемой и эффективной.

Возможности MCP

Функциональность MCP-серверов

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

• Промты — заранее заданные шаблоны или инструкции, направляющие поведение языковой модели.
• Ресурсы — структурированные данные или контент, которые предоставляют модели дополнительный контекст.
• Инструменты — исполняемые функции, позволяющие модели выполнять действия или получать информацию.

Примитив	Кем управляется	Описание	Примеры
Промты	Пользователем	Интерактивные шаблоны, которые запускаются вручную по выбору пользователя	Slash-команды, пункты меню
Ресурсы	Приложением	Контекстные данные, предоставляемые и контролируемые клиентом	Содержимое файлов, история Git
Инструменты	Языковой моделью (LLM)	Функции, доступные модели для выполнения действий	API-запросы (POST), запись файлов

https://spec.modelcontextprotocol.io/specification/2024-11-05/server/

Model Context Protocol (MCP) предоставляет стандартизированный способ, с помощью которого серверы открывают доступ к промтам, ресурсам и инструментам для клиентов.

Промты (Ревизия протокола: 2024–11–05)

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

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

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

Серверы, поддерживающие промты, ОБЯЗАНЫ объявлять о наличии соответствующей функциональности на этапе инициализации:

{
  "capabilities": {
    "prompts": {
      "listChanged": true
    }
  }
}

https://spec.modelcontextprotocol.io/specification/2024-11-05/server/prompts/

Ресурсы (Ревизия протокола: 2024–11–05)

Ресурсы позволяют серверам передавать данные, обеспечивающие дополнительный контекст для языковых моделей — например, файлы, схемы баз данных или специфическую информацию из приложений. Каждый ресурс в MCP однозначно идентифицируется с помощью URI.

В MCP ресурсы изначально проектируются как управляемые приложением, то есть хост-приложение самостоятельно определяет, как именно использовать контекст в соответствии со своими задачами.

Возможные сценарии включают:

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

Серверы, поддерживающие работу с ресурсами, ОБЯЗАНЫ объявить соответствующую возможность при инициализации:

{
  "capabilities": {
    "resources": {
      "subscribe": true,
      "listChanged": true
    }
  }
}

https://spec.modelcontextprotocol.io/specification/2024-11-05/server/resources/

Эта возможность поддерживает два необязательных параметра:

• subscribe — позволяет клиенту подписываться на уведомления об изменениях отдельных ресурсов.
• listChanged — указывает, будет ли сервер отправлять уведомления при изменении списка доступных ресурсов.

Инструменты (Ревизия протокола: 2024–11–05

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

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

Серверы, поддерживающие работу с инструментами, ОБЯЗАНЫ объявлять о наличии соответствующей функциональности:

{
  "capabilities": {
    "tools": {
      "listChanged": true
    }
  }
}

https://spec.modelcontextprotocol.io/specification/2024-11-05/server/tools/

Параметр listChanged указывает, будет ли сервер отправлять уведомления при изменении списка доступных инструментов.

Функциональность MCP-клиентов

Клиенты MCP могут реализовывать дополнительные функции, расширяющие возможности подключённых серверов. Среди таких функций — Roots и Sampling.

Roots (Ревизия протокола: 2024–11–05)

Roots (корневые области) определяют границы доступа серверов к файловой системе, позволяя им понимать, к каким директориям и файлам они имеют доступ. MCP предоставляет стандартизированный механизм, с помощью которого клиенты могут предоставлять информацию о корневых директориях серверам.

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

Определение root включает следующие поля:

• uri — уникальный идентификатор корневой области. В текущей версии спецификации это обязательно должен быть URI с префиксом file://.
• name — (необязательное поле) человеко-читаемое имя для отображения в интерфейсе.

Примеры корневых областей для различных сценариев использования:

Project Directory

{
  "uri": "file:///home/user/projects/myproject",
  "name": "My Project"
}

Multiple Repositories

[
  {
    "uri": "file:///home/user/repos/frontend",
    "name": "Frontend Repository"
  },
  {
    "uri": "file:///home/user/repos/backend",
    "name": "Backend Repository"
  }
]

https://spec.modelcontextprotocol.io/specification/2024-11-05/client/roots/

Sampling (Ревизия протокола: 2024–11–05)

MCP предоставляет стандартизированный механизм, с помощью которого серверы могут запрашивать генерацию (sampling) — то есть «дополнения» или «ответы» от языковых моделей через клиентов. Такой подход позволяет клиенту сохранять контроль над доступом к модели, её выбором и правами, а серверам — использовать ИИ-возможности без необходимости передачи API-ключей.

Серверы могут инициировать как текстовые, так и визуальные (на основе изображений) генерации, при этом при необходимости добавляя контекст от других MCP-серверов непосредственно в промт.

Механизм sampling в MCP также позволяет реализовывать агентное поведение на стороне серверов — за счёт вложенных LLM-вызовов внутри других функций MCP.

Разработчики могут реализовать вызов sampling в любом подходящем формате интерфейса — протокол не диктует конкретную модель взаимодействия с пользователем.

Composability

• Композиционность (Composability) в MCP подчёркивает, что различие между клиентом и сервером является логическим, а не физическим. Это означает, что любое приложение, API или агент может одновременно выполнять функции MCP-клиента и MCP-сервера.
• Такой подход позволяет строить многоуровневые и связные системы. Например, пользователь взаимодействует с основным агентом (в роли клиента), который обращается к специализированному подагенту (в роли сервера). Этот подагент, в свою очередь, может сам выступать как клиент и вызывать другие MCP-серверы — например, файловую систему или сервер веб-поиска — для выполнения своей части задачи.
• Значение для агентных систем: Композиционность особенно важна при создании модульных и масштабируемых архитектур агентов. Она позволяет формировать иерархическую систему агентов, где каждый решает узкоспециализированную задачу и может делегировать подзадачи другим. Например, агент-оркестратор получает высокоуровневую цель, разбивает её на подзадачи и распределяет их между исследовательскими агентами, кодогенерирующими агентами, агентами проверки фактов. Каждый из этих агентов работает как MCP-сервер, но при необходимости может выступать и как клиент, запрашивая доступ к другим MCP-сервисам или инструментам. Такой подход позволяет: выстраивать гибкие цепочки взаимодействия, объединять возможности разных агентов; повторно использовать агентов, разработанных сторонними командами, даже если они не были частью изначального дизайна системы.

Вместе с механизмом семплинга, композиционность становится ключом к созданию по-настоящему интеллектуальных и адаптивных мультиагентных систем. В тандеме они обеспечивают:

• распределение интеллекта: клиент управляет вызовами языковой модели, а серверы (агенты) могут инициировать эти вызовы по мере необходимости;
• построение сложных, многоуровневых систем агентов, где каждый компонент может быть и клиентом, и сервером;
• высокую гибкость и расширяемость, позволяющую легко интегрировать новые возможности в виде MCP-серверов в уже существующие процессы;
• способность агентов к развитию и адаптации через взаимодействие с другими агентами и внешними сервисами.

Эти принципы позволяют перейти от монолитных архитектур агентов к более распределённым, кооперативным и адаптивным ИИ-системам.

Дополнительные возможности, предоставляемые MCP

• Конфигурация
• Отслеживание прогресса
• Отмена операций
• Обработка ошибок
• Логирование

Безопасность и доверие

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

Основные принципы безопасности и надёжности MCP

1. Согласие и контроль пользователя

Пользователь должен явно соглашаться на все действия и доступ к данным, а также осознавать последствия. Он должен сохранять полный контроль над тем, какие данные передаются и какие действия выполняются. Реализация должна предусматривать понятный пользовательский интерфейс для просмотра и подтверждения всех операций.

2. Конфиденциальность данных

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

3. Безопасность инструментов

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

4. Контроль семплинга LLM

Каждый запрос на семплинг должен быть одобрён пользователем вручную. Он должен контролировать:

• Факт запуска семплинга
• Конкретный промт, отправляемый модели
• Какие результаты может увидеть сервер
• Протокол преднамеренно ограничивает доступ сервера к содержимому промтов

Рекомендации по реализации

Разработчики, внедряющие MCP, должны:

• Реализовать надёжные процессы согласия и авторизации
• Обеспечить прозрачную документацию, объясняющую риски и ограничения
• Внедрить механизмы защиты данных и контроля доступа
• Следовать современным практикам безопасной разработки
• Учитывать влияние на конфиденциальность при проектировании каждой функции

Принципы проектирования MCP

Архитектура MCP основана на ряде ключевых принципов, которые определяют её гибкость, безопасность и удобство интеграции.

1. Серверы должны быть максимально простыми в разработке

   • Серверы легко создавать и подключать
   • Сложная логика оркестрации лежит на хост-приложении
   • Каждый сервер отвечает за чётко ограниченный набор функций
   • Простые интерфейсы снижают порог реализации
   • Явное разделение ответственности облегчает поддержку и развитие кода

2. Серверы должны быть высококомпозиционными

   • Каждый сервер предоставляет изолированную, сфокусированную функциональность
   • Несколько серверов могут быть объединены без конфликтов
   • Общий протокол обеспечивает совместимость и взаимодействие
   • Модульная архитектура поддерживает расширяемость и масштабирование

3. Серверы не должны иметь доступа ко всей истории диалога или «видеть» другие серверы

   • Сервер получает только необходимый для работы контекст
   • Полная история взаимодействия хранится на стороне хоста
   • Каждое соединение с сервером изолировано
   • Межсерверное взаимодействие контролируется хостом
   • Хост обеспечивает жёсткие границы безопасности

4. Возможности серверов и клиентов могут расширяться поэтапно

   • Ядро протокола содержит только минимально необходимую функциональность
   • Дополнительные возможности можно подключать по мере необходимости
   • Серверы и клиенты могут эволюционировать независимо друг от друга
   • Протокол спроектирован с прицелом на долгосрочную расширяемость
   • Поддерживается обратная совместимость

Типы сообщений в MCP

Model Context Protocol использует три основных типа сообщений, основанных на спецификации JSON-RPC 2.0:

• Запросы (Requests): двусторонние сообщения, содержащие метод и параметры, которые ожидают ответ
• Ответы (Responses): результат успешного выполнения или ошибка, соответствующие конкретному идентификатору запроса
• Уведомления (Notifications): односторонние сообщения, не требующие ответа

Каждый из этих типов строго следует структуре и правилам передачи, определённым в JSON-RPC 2.0.

Система согласования возможностей в MCP

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

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

Каждая возможность активирует конкретные элементы функциональности.

Примеры:

• Поддерживаемые функции должны быть явно указаны в capabilities сервера
• Чтобы отправлять уведомления о подписке на ресурсы, сервер должен заявить поддержку подписок
• Вызов инструментов возможен только при наличии соответствующей декларации
• Для семплинга клиент обязан указать эту возможность в своём описании

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

https://spec.modelcontextprotocol.io/specification/2024-11-05/architecture/

Подробности базового протокола MCP

Ревизия протокола: 2024–11–05

Все сообщения между MCP-клиентами и серверами ОБЯЗАНЫ соответствовать спецификации JSON-RPC 2.0. Протокол определяет три основных типа сообщений:

Тип	Описание	Требования
Requests	Сообщения, отправляемые для инициирования операции	Должны содержать уникальный ID и имя метода
Responses	Сообщения, отправляемые в ответ на запросы	Должны содержать тот же ID, что и у исходного запроса
Notifications	Односторонние сообщения, не предполагающие ответа	Не должны содержать ID

https://spec.modelcontextprotocol.io/specification/2024-11-05/basic/

Ответы (Responses) далее подразделяются на два типа: успешные результаты и ошибки. Результаты могут иметь произвольную структуру JSON-объекта, а ошибки обязаны содержать как минимум код ошибки и сообщение.

Слои протокола

Model Context Protocol (MCP) состоит из нескольких ключевых компонентов, которые работают согласованно:

• Базовый протокол: основные типы сообщений, построенные на JSON-RPC
• Управление жизненным циклом: инициализация соединения, согласование возможностей, контроль сессии
• Функциональность сервера: ресурсы, промты и инструменты, предоставляемые сервером
• Функциональность клиента: семплинг и предоставление списков корневых директорий
• Служебные функции: логирование, автодополнение аргументов и другие общие механизмы

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

Такая многослойная структура обеспечивает чёткое разделение ответственности, сохраняя при этом богатые возможности взаимодействия между клиентом и сервером.
Модульный подход позволяет внедрять только те функции, которые действительно необходимы, без избыточной сложности.

Жизненный цикл клиент-серверного соединения

Model Context Protocol (MCP) определяет строгий и формализованный жизненный цикл взаимодействия между клиентом и сервером, обеспечивающий корректное согласование возможностей и управление состоянием сессии.

Основные этапы:

• Инициализация: согласование возможностей и версии протокола
• Рабочий режим: стандартный обмен сообщениями по MCP
• Завершение: корректное завершение сессии

Фазы жизненного цикла

1. Инициализация

Фаза инициализации всегда должна быть первым этапом взаимодействия между клиентом и сервером. В рамках этой фазы стороны:

• проверяют совместимость версий протокола;
• обмениваются и согласовывают поддерживаемые возможности;
• передают информацию о своей реализации.

Клиент обязан инициировать эту фазу, отправив запрос initialize, в котором указывает:

• поддерживаемую версию протокола;
• список клиентских возможностей (capabilities);
• информацию о реализации (например, имя, версия и т.д.).

Сервер обязан ответить своим набором возможностей и информацией о реализации.

После успешного завершения инициализации клиент должен отправить уведомление initialized, сигнализируя о готовности к работе. До получения ответа на initialize клиент НЕ ДОЛЖЕН отправлять другие запросы, кроме ping. До получения уведомления initialized от клиента сервер НЕ ДОЛЖЕН отправлять другие запросы, кроме ping и logging.

2. Согласование версии

В initialize-запросе клиент обязан указать поддерживаемую версию протокола — желательно самую свежую. Если сервер поддерживает указанную версию, он должен подтвердить её. Если нет — он должен вернуть одну из поддерживаемых версий (предпочтительно самую последнюю). Если клиент не поддерживает предложенную версию, он должен разорвать соединение.

3. Согласование возможностей (Capability Negotiation)

Клиент и сервер обмениваются списками своих возможностей (capabilities), тем самым определяя, какие дополнительные функции протокола будут активны в рамках текущей сессии.

Ключевые возможности включают:

Категория	Возможность (capability)	Описание
Клиент	roots	Возможность предоставлять корневые директории файловой системы
Клиент	sampling	Поддержка запросов на семплинг от LLM
Клиент	experimental	Поддержка нестандартных экспериментальных функций
Сервер	prompts	Предоставляет шаблоны промтов
Сервер	resources	Предоставляет читаемые ресурсы
Сервер	tools	Открывает доступ к вызываемым инструментам
Сервер	logging	Отправляет структурированные сообщения логирования
Сервер	experimental	Поддержка нестандартных экспериментальных функций

https://spec.modelcontextprotocol.io/specification/2024-11-05/basic/lifecycle/

Объекты возможностей могут описывать подкатегории (подвозможности).

4. Рабочая фаза (Operation)

В рабочей фазе клиент и сервер обмениваются сообщениями в соответствии с согласованными возможностями.

Обе стороны ДОЛЖНЫ:

• соблюдать согласованную версию протокола;
• использовать только те возможности, которые были явно согласованы в процессе инициализации.

5. Завершение (Shutdown)

На этапе завершения одна из сторон (чаще всего клиент) корректно завершает соединение. Специальные сообщения завершения не предусмотрены — вместо этого используется транспортный механизм для сигнализации об окончании сессии.

stdio

Для транспорта stdio клиент ДОЛЖЕН завершать соединение следующим образом:

1. Закрыть входной поток в дочерний процесс (сервер);
2. Подождать завершения сервера или отправить сигнал SIGTERM, если он не завершился в разумные сроки;
3. Если сервер не реагирует на SIGTERM, отправить SIGKILL.

Сервер МОЖЕТ инициировать завершение, закрыв свой выходной поток и завершив выполнение.

HTTP

При использовании транспорта HTTP завершение соединения происходит путём закрытия соответствующих HTTP-соединений.

---

6. Обработка ошибок

Реализация ДОЛЖНА быть готова к следующим типам ошибок:

• несовместимость версий протокола;
• невозможность согласовать необходимые возможности (capabilities);
• таймаут на initialize-запрос;
• таймаут при завершении соединения.

НЕОБХОДИМО реализовывать таймауты для всех типов запросов, чтобы избежать зависаний и чрезмерного потребления ресурсов.

Аутентификация и авторизация

Аутентификация и авторизация на данный момент не входят в основную спецификацию MCP, однако могут быть добавлены в будущих версиях.

Полная спецификация MCP оформлена как схема на TypeScript — это единственный источник истины для всех структур и сообщений протокола.

На её основе автоматически генерируется JSON-схема, предназначенная для использования в автоматизированных инструментах.

Mindmap of MCP Protocol

Преимущества MCP для заинтересованных сторон

Для разработчиков приложений

Model Context Protocol (MCP) предоставляет разработчикам целый ряд существенных преимуществ.

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

2. Стандартизированный интерфейс
MCP унифицирует взаимодействие AI-приложений с внешними системами через три ключевых интерфейса: промты, инструменты и ресурсы. Это даёт разработчикам единый, предсказуемый способ подключения новых возможностей и избавляет от необходимости разбираться с каждым сервером по отдельности.

3. Доступ к широкой экосистеме
Создавая MCP-клиент, разработчик получает доступ ко всё более обширной экосистеме MCP-серверов, созданных как сообществом, так и в рамках официальных решений.
Подключение к базам данных, CRM-системам, локальным файловым хранилищам и другим сервисам становится простым и единообразным. Скоро ожидается MCP Registry API, который позволит централизованно находить и подключать совместимые серверы.

4. Фокус на логике и пользовательском опыте
Благодаря MCP разработчики могут сосредоточиться на бизнес-логике и UX своего приложения, вместо того чтобы тратить ресурсы на реализацию интеграций.
Протокол берёт на себя стандартизацию передачи данных и взаимодействия. Как отметил Махеш, разработчики могут сосредоточиться на "агентном цикле" и управлении контекстом, в то время как MCP обеспечивает единый и надёжный способ доставки контекста в модель.

5. Использование интеллекта модели для вызова инструментов
Интерфейс tools позволяет сделать функции приложения доступными для языковой модели, и модель самостоятельно решает, когда и как их вызывать.
Это снижает необходимость вручную описывать каждое взаимодействие и делает поведение приложения более гибким, динамичным и адаптивным.

6. Расширенное взаимодействие с пользователем
Интерфейс resources даёт возможность предоставлять не только текст, но и структурированные данные, изображения и другой контекст.
Это открывает путь к более богатым, визуально насыщенным и интерактивным пользовательским сценариям.

Model Context Protocol (MCP) предоставляет серьёзные преимущества не только разработчикам приложений, но и провайдерам инструментов/API, конечным пользователям и организациям.

Для Tool/API-провайдеров:

1. Расширение охвата без лишней работы
Создав MCP-сервер один раз, поставщики могут получить доступ к множеству AI-приложений, совместимых с MCP. Это устраняет необходимость реализовывать отдельную интеграцию для каждого клиента и значительно расширяет потенциальную аудиторию. Как выразился Махеш:

«Один MCP-сервер — и он работает везде, во всех этих AI-приложениях».

2. Простая и стандартизированная интеграция
Благодаря стандартным интерфейсам — prompts, tools, resources — MCP позволяет легко подключать инструменты и данные к AI-приложениям. Это упрощает интеграцию для разработчиков и повышает вероятность того, что ваш сервис будет активно использоваться.

3. Снижение затрат на поддержку интеграций
Больше не нужно решать задачу вида «N на M» — поддерживать десятки отдельных связок с разными клиентами. MCP выступает как единый слой взаимодействия, упрощая разработку и поддержку интеграций.

4. Доступ к интеллектуальным агентам
MCP позволяет инструментам и API становиться частью экосистемы интеллектуальных агентов, которые автоматически определяют, когда и как использовать возможности сервиса. Это открывает путь к новым способам применения — более автономным и контекстно-зависимым.

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

Для конечных пользователей

1. Более мощные и контекстно-зависимые AI-приложения
MCP открывает путь к созданию персонализированных, глубоко интегрированных систем, обладающих доступом к релевантным данным и инструментам в реальном времени.
В результате пользователи получают более точные, полезные и адаптированные ответы.
Как выразился Махеш:

«Пользователи получают более мощные и контекстно насыщенные AI-приложения».

2. Контекстно-осознанное поведение
Приложения, построенные на MCP, могут понимать текущий контекст пользователя, автоматически получать необходимые данные и предлагать актуальные действия.
Такие решения, как Curser и Windsurf, показывают, как системы могут «действительно знать что-то о вас и действовать в реальном мире».

3. Интеграция с привычными инструментами
С помощью MCP AI-приложения могут бесшовно интегрироваться с уже используемыми сервисами, такими как GitHub, Asana и другими. Это формирует единый, цельный и более продуктивный рабочий процесс без необходимости переключаться между платформами.

4. Более интеллектуальные ассистенты
Агенты, подключённые через MCP, могут использовать широкий спектр инструментов и данных, что делает их более гибкими и полезными в самых разных задачах.
С запуском реестра MCP (MCP Registry) они смогут автоматически находить и подключать новые функции, расширяя свои возможности на лету.

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

Для предприятий

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

2. Разделение ответственности между командами
С помощью MCP можно разделить зоны ответственности: инфраструктурные команды обслуживают, например, векторные базы данных, а команды продуктовой разработки используют их через стандартизированные интерфейсы. Такое разграничение позволяет каждой группе фокусироваться на своей специализации и работать быстрее. Пример: одна команда администрирует MCP-сервер с доступом к базе, а остальные подключаются к нему без необходимости вникать в детали реализации.

3. Ускоренные циклы разработки
Готовые MCP-серверы и стандартизированные интерфейсы позволяют компаниям быстро разрабатывать и масштабировать AI-решения, без необходимости каждый раз реализовывать кастомные интеграции для новых источников данных или инструментов.

4. Централизованное управление доступом и политиками (в перспективе)
Хотя эти механизмы пока развиваются, внедрение удалённых серверов и авторизации по OAuth 2.0 создаёт основу для централизованного контроля над доступом и безопасностью. Будущий реестр MCP-серверов (MCP Registry) позволит организациям управлять внутренними и внешними сервисами, проверяя их и регулируя их использование.

5. Повышенная масштабируемость и надёжность
Благодаря унифицированной архитектуре MCP, AI-системы становятся более устойчивыми к изменениям и лучше масштабируются. Интеграции меньше зависят от конкретных API и проще в поддержке.

6. Использование существующей инфраструктуры
Организации могут обернуть свои текущие инструменты и источники данных в виде MCP-серверов, тем самым открывая доступ к ним для AI-приложений без масштабных изменений архитектуры.

MCP Registry API (в разработке)

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

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

2. Сведения о протоколе и местоположении
Реестр будет содержать информацию о типе транспорта (например, stdio или SSE) и расположении сервера — будь то локальный путь или удалённый URL.

3. Доверие и верификация
Одна из главных задач — оценка надёжности и подлинности MCP-серверов.
Реестр может предложить механизмы верификации, такие как пометка “официальный” для серверов от компаний с высокой репутацией (например, Shopify или Grafana).

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

5. Управление версиями
По мере эволюции MCP-серверов реестр обеспечит отслеживание изменений и поддержку версионности. Пользователи смогут закрепляться на нужной версии и понимать, что именно изменилось между релизами.

6. Управление метаданными
Реестр будет хранить расширенные метаданные о MCP-серверах — например, список доступных ресурсов и инструментов (capabilities). Это позволит быстро оценить возможности сервера и подключить его без лишнего анализа документации.

Удалённые серверы и интеграция OAuth 2.0 в протокол MCP

Зачем нужны удалённые MCP-серверы

В текущей реализации протокола MCP взаимодействие чаще всего происходит локально или в памяти, например, через стандартный ввод-вывод (standard IO). Это может создавать лишние сложности при настройке и развёртывании.

С поддержкой удалённых серверов — через протоколы вроде SSE (Server-Sent Events) — MCP-серверы могут быть размещены по публичным URL и становиться доступными через интернет.

Это открывает ряд важных возможностей:

• Простота подключения: пользователям и приложениям не нужно разбираться в тонкостях хостинга MCP-серверов. Как и при работе с обычным веб-сайтом, можно просто подключиться к удалённому серверу по URL.
• Гибкость в архитектуре: клиент и сервер больше не привязаны к одному устройству или окружению. Например, AI-агент может работать локально, а MCP-сервер — в облаке или на удалённой машине.
• Расширение доступных возможностей: чем больше удалённых серверов — тем больше разнообразия функций и инструментов, доступных через MCP. Это открывает новые сценарии для агентов, разработчиков и конечных пользователей.

Интеграция OAuth 2.0

Интеграция OAuth 2.0 обеспечивает стандартизованный и безопасный механизм аутентификации и авторизации между MCP-клиентами и удалёнными серверами.

Теперь MCP поддерживает OAuth 2.0 handshake — процесс, при котором сервер управляет аутентификацией, взаимодействуя с OAuth-провайдером (например, Slack). Клиент (пользователь) проходит привычный веб-интерфейс авторизации, подтверждая доступ к нужным возможностям.

После успешной аутентификации:

• Сервер получает OAuth-токен от провайдера,
• И может выдать клиенту токен сессии для дальнейших взаимодействий.

Это позволяет серверу контролировать доступ к внешним сервисам (например, Slack) и управлять пользовательскими сессиями более гибко.

Такой механизм критически важен для:

• Безопасного доступа к чувствительным данным и функциям на стороне сервера,
• Построения доверенной среды между агентами, приложениями и сервисами,
• Управления правами доступа и разграничением полномочий в масштабируемой архитектуре.

Влияние на доступность и удобство использования

Новые возможности MCP — поддержка удалённых серверов и интеграция OAuth 2.0 — существенно улучшают доступность и удобство использования MCP-серверов как для разработчиков, так и для конечных пользователей.

1. Снижение порога входа
Подключение к удалённым серверам по обычному URL сильно снижает технический барьер. Это облегчает работу как для разработчиков, внедряющих MCP в свои приложения, так и для пользователей, которым теперь не нужно разбираться в устройстве протокола. Во многих случаях пользователь даже не будет знать, что взаимодействует с MCP-сервером — всё работает "из коробки".

2. Расширение спектра применений
Удалённые серверы позволяют интегрировать MCP в гораздо более широкий круг приложений: веб-сервисы, мобильные приложения, облачные решения. Теперь не требуется сложная локальная настройка — достаточно подключиться к нужному серверу по адресу.

3. Рост доступности функциональности
Порог вхождения для разработчиков падает, и это приведёт к быстрому росту количества MCP-серверов с разнообразными возможностями. AI-приложения получат доступ к более богатой экосистеме инструментов и данных.

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

5. Упрощение разработки
Разработчики теперь могут сосредоточиться на бизнес-логике и пользовательском опыте, а не на реализации низкоуровневых механизмов связи и авторизации. Стандартизированный OAuth-поток делает MCP удобным и безопасным решением “по умолчанию”.

Саморазвивающиеся агенты благодаря реестру MCP-серверов

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

Пример:
Представим агента общего назначения, которому поручено проверить логи Grafana. Если он изначально не был сконфигурирован для работы с Grafana, он может:

1. Обратиться к реестру MCP-серверов,
2. Найти официальный, верифицированный сервер Grafana, предоставляющий нужный API,
3. Подключиться к нему (возможно, удалённо через SSE, как обсуждалось ранее),
4. Выполнить необходимые запросы и устранить ошибку.

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

Потенциальные преимущества саморазвивающихся агентов

1. Повышенная адаптивность
Главное преимущество — это способность агента адаптироваться к новым ситуациям и задачам. Вместо того чтобы быть ограниченным заранее заданным функционалом, агент может динамически расширять свои возможности, подбирая нужные инструменты в процессе работы.

2. Расширение области применения
Такие агенты способны выполнять более широкий спектр задач, без необходимости предусматривать все возможные сценарии ещё на этапе проектирования. Это позволяет использовать их в гораздо более гибких и непредсказуемых условиях.

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

4. Непрерывное развитие и улучшение
Агенты могут по сути “самообучаться”, обнаруживая и интегрируя новые, более эффективные инструменты и источники данных по мере их появления в MCP-реестре. Это делает их со временем всё более продуктивными и полезными.

5. Снижение нагрузки на разработчиков
Разработчики могут сосредоточиться на построении основной логики: мышления, принятия решений, планирования, в то время как доступ к внешним данным и инструментам обеспечивается через динамическую и расширяемую инфраструктуру MCP. Это снижает необходимость в создании кастомных интеграций под каждый потенциальный источник.

Ключевые аспекты и вызовы саморазвивающихся агентов

1. Управление и безопасность
Один из важнейших аспектов — контроль над тем, какие MCP-серверы и возможности доступны агенту. Без чётких ограничений агент может случайно подключиться к ненадёжному или даже вредоносному серверу, что создаёт угрозы безопасности и приватности данных. Как отмечает Махеш, необходимы защитные меры, такие как:

• собственные (self-hosted) реестры с одобренными серверами,
• механизмы верификации и белые списки,
• проверка происхождения и доверия к серверам.

Понятие доверия к серверу становится центральным элементом архитектуры.

2. Надёжность и верификация
Важно обеспечить, чтобы агент подключался только к действительно безопасным и проверенным серверам. Развивающийся MCP-реестр должен включать механизмы верификации — например, официальные отметки от компаний вроде Shopify или Grafana.

3. Производительность и задержки
Динамический поиск и подключение новых серверов может вносить задержки в выполнение задач агента. Оптимизация работы с реестром, кэширование и «предзагрузка» часто используемых серверов могут сыграть решающую роль в обеспечении отзывчивости.

4. Выбор инструментов и логика принятия решений
Агенты должны не просто уметь подключаться к новым возможностям, но и осознанно выбирать подходящие инструменты среди множества доступных. Избыточное количество вариантов может снизить эффективность агента или привести к неоптимальным решениям. Необходимы механизмы приоритезации, фильтрации и контекстного выбора.

5. Отладка и наблюдаемость
По мере усложнения поведения агента становится всё труднее понять:

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

Нужны прозрачные средства мониторинга и отладки, а также поддержка протоколируемых взаимодействий и метаданных — как со стороны клиента, так и со стороны серверов.

6. Версионирование и совместимость
Серверы со временем обновляются, и их API могут меняться. Агент должен:

• понимать, с какой версией сервера он работает,
• обрабатывать возможные несовместимости,
• при необходимости — закрепляться на проверенной версии.

MCP-реестр должен учитывать версии и предоставлять метаданные о совместимости.

Ссылки и материалы:

1. Воркшоп Mahesh Murag по MCP на AI Engineer Summit —
   https://www.youtube.com/watch?v=kQmXtrmQ5Zg
2. Руководство Supabase по началу работы с MCP —
   https://supabase.com/docs/guides/getting-started/mcp
3. Статья Anthropic: «Построение эффективных агентов» —
   https://www.anthropic.com/engineering/building-effective-agents
4. Анонс Model Context Protocol от Anthropic —
   https://www.anthropic.com/news/model-context-protocol
5. Спецификация MCP (версия от 05.11.2024) —
   https://spec.modelcontextprotocol.io/specification/2024-11-05/
6. Введение в MCP (официальный сайт) —
   https://modelcontextprotocol.io/introduction
7. Python SDK (GitHub) —
   https://github.com/modelcontextprotocol/python-sdk
8. TypeScript SDK (GitHub) —
   https://github.com/modelcontextprotocol/typescript-sdk

---

Этот текст является переводом статьи: The Model Context Protocol (MCP) — A Complete Tutorial