Введение в MCP: от фрагментации к общим серверам инструментов

Что, если бы модель языка могла взаимодействовать, обмениваться информацией и действовать в реальном мире? MCP — это связующее звено между интеллектом и действием.

ChatGPT был запущен 30 ноября 2022 года и ускорил использование ИИ в повседневной жизни — для повышения производительности, выполнения бытовых задач и решения проблем. Затем производители встроили ИИ в уже существующие продукты: наборы для повышения производительности, чат-приложения, поисковые системы, среды разработки, корпоративное программное обеспечение. Ассистенты больше не ограничивались лишь автономными чат-ботами.

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

Проблема фрагментации

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

Представьте разработчика в VS Code. Встроенный ассистент понимает структуру репозитория внутри IDE. Как только ему нужны задачи на GitHub или страницы в Confluence за пределами IDE, он покидает ассистента, копирует текст, вставляет его обратно и надеется, что модель получит достаточно контекста.

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

Что означает «контекст»

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

Пример: создание функции безопасности с помощью ChatGPT. Разработчик может:

1. JIRA — скопировать требования и критерии приемки в чат.
2. GitHub — вставить соответствующие реализации и репозитории.

MySQL — вручную извлекать данные системы и вводить их.

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

Teams/Slack — собирать не задокументированные знания от коллег.

Только тогда они задают настоящий вопрос. Модель отвечает лучше, но процесс причиняет трудности:

• Ручная копирование-вставка между системами происходит медленно.
• Контекст рассеивается; разработчики превращаются в своего рода человеческие API.
• Время сборки может превысить время разработки.
• Увеличение количества источников делает этот процесс нерасширяемым; реальные системы больше, чем буфер для вставки.

Именно эти трудности способствовали появлению механизмов вызова функций/инструментов в середине 2023 года (работа OpenAI).

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

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

Благодаря инструментам, предназначенным для JIRA, GitHub, MySQL, Drive, Slack и т. д., модель может выбирать, что вызвать на основе запроса пользователя, получать контекст и отвечать — без необходимости вручную вставлять данные.

Ограничения вызова функций в рамках отдельного приложения

Представьте трех ИИ-ассистентов в одной компании. Каждому из них по-прежнему требуются собственные функции/интеграции для работы с базами данных, GitHub, JIRA, Slack и другими сервисами.

Если у вас есть N ассистентов и M внешних ресурсов, возникает риск необходимости создания N × M интеграций. Десять ассистентов × двадцать ресурсов ≈ двести индивидуальных ссылок. С ростом числа ассистентов и ресурсов создание и поддержка такой сети становится очень дорогостоящим.

Если каждое приложение по-прежнему контролирует каждую интеграцию, фрагментация просто перемещается: проблемы с объединением контекста становятся проблемами интеграции.

Можно ли сократить N × M до N + M? Именно здесь на сцену выходит MCP.

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

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

Существуют две основные роли:

• Клиент MCP — находится в ИИ-приложении/агенте, подключается к серверу, находит и использует доступные инструменты/ресурсы.
• Сервер MCP — служит мостом между ИИ-приложением и GitHub, JIRA, базой данных, Drive, Slack или другим сервисом.

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

Вызов функций против MCP — пример с погодой

1. Вызов функций

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

import requests

def get_weather(city):
    response = requests.get(
        "https://api.weather.com/current",
        params={"city": city}
    )
    return response.json()

Эту функцию регистрируют как инструмент. Пользователь задаёт вопрос: «Какая погода в Бенгалуру?» Модель может вызвать get_weather("Bengaluru"). Приложение выполняет этот вызов, возвращает данные, после чего модель формирует ответ.

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

2. MCP

Информация о погоде хранится на сервере MCP, который взаимодействует с API и предоставляет стандартный инструмент:

@mcp.tool()
def get_weather(city: str):
    """Get the current weather for a city."""
    return weather_api.get_current_weather(city)

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

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

Преимущества MCP

Вот «почему». В следующих разделах рассматриваются архитектура, внутренние механизмы и практическая реализация.

Ещё раз рассмотрим вопрос функций безопасности

Вернёмся к разработчику, создающему механизмы безопасности. Без MCP или специальных инструментов ему приходится искать необходимые элементы в JIRA, GitHub, MySQL, Drive и Slack. Каждый шаг требует копирования контекста. С использованием вызовов функций эти шаги превращаются в названные функции, которые может использовать модель — однако каждому ассистенту в компании всё равно требуется собственная копия интеграций.

MCP устраняет такое дублирование. Один сервер погодных данных, один сервер JIRA и один сервер GitHub могут обслуживать множество клиентов, совместимых с MCP. Структура типа N×M приближается к формату N клиентов плюс M серверов.

Моменты дизайна, которые игнорируют команды

Рассматривайте описания инструментов как текст для рекламы продукта: четкие названия и документация к параметрам помогают выбрать правильную модель. Инструменты для записи данных должны использоваться только после подтверждения, а серверы для них следует отделять от инструментов каталога с режимом только чтения. Логируйте вызовы инструментов с идентификаторами корреляции, чтобы неправильный результат можно было отследить до ошибочного поиска, а не свалить на «модель» в общем смысле.

При сравнении функционала вызовов и MCP для новой системы спросите, кто несет ответственность за весь цикл интеграции. Если ответ — «каждая команда по разработке продукта навсегда», то общедоступные серверы MCP окупят себя. Если ответ — «одна временная демо-версия», то достаточно локальных функций.

Что будет дальше

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

Фрагментация как проблема бюджета

Посчитайте, сколько часов ваша команда тратит на копирование данных из JIRA и GitHub в чаты. Эти усилия представляют собой «налог» на каждого внедряемого ИИ-ассистента. Вызов функций сокращает время копирования, но увеличивает объем кода адаптеров. MCP направлено на использование общих серверов вместо отдельных копий для каждого ассистента.

Сформулируйте деловую ценность с этой точки зрения: меньше часов работы людей над API, меньше дублирующихся интеграций, более четкие критерии аудита. Для финансового отдела диаграммы архитектуры имеют меньшее значение, чем таблицы в формате N×M.

Выводы по примеру работы с погодой для рецензентов

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