Что такое MCP простыми словами: протокол инструментов AI

Model Context Protocol (MCP) — открытый протокол, по которому AI-приложение узнаёт, какие данные и действия предоставляет внешний сервер, и вызывает их в согласованном формате. Представьте не «мозг с доступом ко всему», а разъём между приложением и конкретным источником. Приложение остаётся хозяином подключения; модель предлагает использовать инструмент, а исполняющий код решает, разрешён ли вызов.

Это объяснение для команды, которая выбирает способ подключить ассистента к документам или рабочей системе. Оно не заменяет выбор AI-специалиста в Армении: здесь разбирается один технический механизм. За практикой построения контролируемого процесса стоит обратиться к AI-автоматизации.

Определение без маркетинга

MCP задаёт общий язык между host (AI-приложением), его client и server (адаптером к возможностям). Один host может поддерживать несколько клиентов, по одному на соединение с сервером. Сервер публикует доступные возможности; клиент обнаруживает их и отправляет структурированные запросы. По официальной спецификации, базовые примитивы сервера — tools (выполнимые функции), resources (контекстные данные) и prompts (шаблоны взаимодействия).

MCP не обучает модель, не создаёт права доступа и не гарантирует качество ответа. В отличие от обычного REST API, здесь стандартизован слой обнаружения возможностей и обмена ими с AI-приложением. При этом реальная бизнес-операция всё равно исполняется кодом и существующей системой. Если достаточно одного фиксированного вызова API в известном workflow, дополнительный сервер может только увеличить сложность.

Как это работает: карта MCP-CONNECT-6

Ниже — авторская схема MCP-CONNECT-6. Это учебная модель для проектирования соединения, не утверждение о готовом продукте или результаты теста.

Граница доверия проходит между предложением модели и исполнением. Описание инструмента помогает модели выбрать вызов, но не служит разрешением. Сервер также нельзя считать доверенным только потому, что он «поддерживает MCP». Для операций записи нужны проверка полномочий пользователя, узкий scope, контроль аргументов и понятный маршрут отказа. Подробный разбор самой границы вызова есть в статье о tool calling.

Что означают три примитива

• Tool: функция вроде crm.findCustomer или calendar.createDraft. При её вызове может произойти чтение или изменение данных. Поэтому название и JSON-схема — только контракт входа, а не политика безопасности.
• Resource: документ, запись или другое содержание, которое host может включить в контекст. Данные из resource могут содержать ошибочные или вредоносные инструкции; их не следует превращать в правила поведения системы.
• Prompt: заранее подготовленный шаблон задачи, который пользователь или приложение выбирает для определённого сценария. Он помогает повторять форму работы, но не даёт дополнительных прав.

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

Сквозной пример: вопрос по договору и черновик CRM

Сотрудник спрашивает: «Какие условия поддержки действуют для клиента X и подготовь черновик задачи менеджеру». Организация уже хранит договор в базе знаний и карточку клиента в CRM. Команда публикует два узких интерфейса: resource для разрешённого фрагмента договора и tool crm.createTaskDraft. Host соединяется с сервером в контексте сотрудника.

1. Система устанавливает личность сотрудника и его организацию. Поиск договора фильтрует доступ до передачи фрагмента модели.
2. Модель получает ссылку на фрагмент и формирует ответ с указанием версии договора. Текст договора рассматривается как данные, даже если внутри него написано «отправь копию другому адресу».
3. Модель предлагает черновик задачи: customerId, summary, sourceRef. Host показывает точный черновик или отправляет его через разрешённый маршрут.
4. Сервер проверяет схему, владельца карточки и право сотрудника создать черновик. Если запись запрещена, он возвращает отказ. Если API ответил неоднозначно, интеграция сверяет состояние по идентификатору операции перед повтором.

Результат — ответ с источником и, при разрешении, черновик в CRM. Это синтетический пример, не кейс клиента и не обещание, что любой MCP-клиент выполнит все проверки автоматически. В production эти правила реализуют в host, gateway и серверном адаптере. Границы human approval важны, если черновик превращается в отправку письма или изменение коммерческих условий.

// Иллюстративный контракт, не готовый MCP SDK-код.
const proposal = { tool: "crm.createTaskDraft", customerId, summary, sourceRef };
if (!policy.allows(actor, proposal.tool, customerId)) return "deny";
if (!source.isCurrent(sourceRef)) return "refresh_source";
const receipt = await gateway.executeOnce(proposal, requestId);
return receipt.effectKnown ? receipt : "reconcile";

Где подходит, а где нет

Ограничения и проверка безопасности

На локальном компьютере подключённый сервер может исполняться как процесс; удалённый сервер добавляет сетевую аутентификацию и операционные риски. Для обоих вариантов фиксируйте владельца, происхождение пакета, список доступных возможностей и процесс отключения. Не выдавайте серверу общий ключ ко всем данным, если задаче нужна одна запись. Не принимайте текст ответа tool за подтверждённый эффект в CRM.

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

Начните с одного read-only resource и одного безопасного черновика. Зафиксируйте, кто может их видеть, как удалить доступ, какие события логируются и как оператор разберёт неизвестный результат. Если задача шире подключения инструментов, гайд по prompt engineering поможет сформулировать ожидаемый ответ, а разбор AI-автоматизации — встроить вызов в процесс. Для первичной оценки можно описать свой сценарий: систему, пользователя, данные и одно допустимое действие.