Сейчас много говорят о MCP (протоколе контекста модели). Я вообще не уверен, что он нужен
Сейчас много говорят о серверах стандарта MCP (протокол контекста модели). Идея проста: учим большие языковые модели (LLM) взаимодействовать с другими программными системами. В процессе такой работы LLM могут учиться и давать реальный эффект. Например, вызвать веб‑сервер, чтобы позвонить по телефону, либо открыть инструмент для работы с интерфейсом командной строки (CLI) и добавить пункт в список продуктов в приложении‑напоминалке для походов в магазин, и так далее. Чтобы выполнять такие операции, LLM должны знать, какие именно программы они вправе вызывать, и как это делать. Именно эту проблему и решает MCP: он сообщает LLM обо всех имеющихся в распоряжении программах, учит LLM ими пользоваться, а также прокладывает путь, по которому LLM может вызывать софт.
Разработчики пишут MCP‑серверы, обеспечивающие большие языковые модели ресурсами, промптами и инструментами. На сайте MCP эти концепции подробно обсуждаются, но в разделе Ключевые концепции MCP они резюмированы так:
Ресурсы: файлоподобные данные, которые могут считываться клиентами (например, отклики API или содержимое файлов)
Инструменты: функции, которые LLM может вызывать (с одобрения пользователя)
Промпты: заранее написанные шаблоны, при помощи которых пользователи могут решать конкретные задачи
Эти категории сформулированы вольно и могут запутать. На первый взгляд кажется, что ресурсы доступны только для чтения, а инструменты — только для записи. Но в документации на сервере MCP инструменты рассматриваются на примере searchFlights — это операция только для чтения. Потом они ещё сильнее всё запутывают, показывая поиск авиарейсов как ресурс. Вот какое определение инструмента они дают:
{ name: "searchFlights", description: "Search for available flights", inputSchema: { type: "object", properties: { origin: { type: "string", description: "Departure city" }, destination: { type: "string", description: "Arrival city" }, date: { type: "string", format: "date", description: "Travel date" } }, required: ["origin", "destination", "date"] } }
А вот определение ресурса в их трактовке:
{ "uriTemplate": "travel://flights/{origin}/{destination}", "name": "flight-search", "title": "Flight Search", "description": "Search available flights between cities", "mimeType": "application/json" }
Промпты — это просто статические определения в формате JSON, описывающие потенциальные действия пользователя.
Весь этот протокол кажется мне каким‑то лишним. Промпты — это просто статическая документация, ресурсы — статические определения URL, а инструменты выглядят как определения вызовов удалённых процедур (RPC). Я попросил ChatGPT 5 Thinking преобразовать определение инструмента searchFlights в определение OpenAPI (в сущности, это и есть определение RPC). Не удивительно, что это сразу сработало:
openapi: 3.0.0 info: title: Flights API version: "1.0.0" paths: /searchFlights: get: operationId: searchFlights summary: Search for available flights description: Search for available flights parameters: - in: query name: origin required: true description: Departure city schema: type: string - in: query name: destination required: true description: Arrival city schema: type: string - in: query name: date required: true description: Travel date schema: type: string format: date responses: "200": description: Search results content: application/json: schema: type: array items: type: object
Поэтому напрашивается вопрос: а зачем нужен MCP для определения инструментов? У нас уже есть OpenAPI, gRPC и CLI. ChatGPT понимает определения OpenAPI. Уже существуют миллионы веб‑сервисов, также предоставляющих определения OpenAPI. А ChatGPT уже превосходит большинство людей в обращении с CLI — сами посмотрите, как Codex управляется с командами sed, awk и grep. Недавно друг рассказал мне, что ему удалось научить ChatGPT пользоваться tmux. Вот как об этом сказано в статье «MCP vs CLI: Benchmarking Tools for Coding Agents»:
MCP в сравнении с CLI — это как шило на мыло: terminalcp в версии как с MCP, так и с CLI достигает успеха в 100% случаев. Версия с MCP оказалась на 23% бвстрее (51 m и 66 m) и на 2,5% дешевле ($19.45 против $19.95)..
MCP в сравнении с CLI — это как шило на мыло: terminalcp в версии как с MCP, так и с CLI достигает успеха в 100% случаев. Версия с MCP оказалась на 23% бвстрее (51 m и 66 m) и на 2,5% дешевле ($19.45 против $19.95).
Я видел ряд аргументов, призванных оправдать существование MCP:
Контекстное окно у LLM ограничено. В свою очередь, документация OpenAPI занимает слишком много места в этом контексте.
Многие сервисы не слишком хорошо документированы; к ним не предоставляется спецификация API.
LLM нужно каким‑то образом обнаруживать, какие инструменты есть у неё в распоряжении.
Скептически к этому отношусь. Пожалуй, MCP действительно позволяет втиснуть в контекстное окно пару дополнительных инструментов. Может быть, с ним модели работают чуть‑чуть быстрее. Документация к OpenAPI действительно кажется несколько многословной. Но как долго это будет иметь значение?
В прошлом году речь шла о модели на миллион токенов. Теперь в OpenRouter есть модели на 2 миллиона токенов. Не стоят на месте исследования по более мелким моделям, тонкой настройке, в таком духе. С такой точки зрения MCP кажется просто временным костылём.
Последний довод о том, что многие сервисы плохо документированы справедлив для внутрикорпоративных сервисов больших предприятий. Например, это отмечает Джейк Мэнникс в своём треде. Я слышал, что протокол MCP шире всего задействован именно в этом сегменте.
С клиентоориентированными SaaS API совсем другая история. Известно, насколько хорошо документированы многие из них. Некоторые сложноваты, но часто это неотъемлемая сложность (могу это подтвердить по опыту работы с API WePay).
Более того, аргумент создаёт впечатление, как будто те самые люди, которые написали плохие спецификации к OpenAPI, напишут хорошие спецификации к MCP. Неубедительно. (Опять же, даже если бы им это было под силу, почему бы не написать конечную точку в стиле OpenAPI или как инструмент CLI?)
«Не понимаю этого баттла между CLI и MCP. Может быть, я что‑то упускаю?»
Почему MCP может послужить хорошей заменой такому локализованному инструменту как CLI? В лучшем случае, это кажется дискуссией об использовании песочниц, то есть, о том, где запускается MCP, а не где фактически работает — фактически же он интегрирован в сетевой уровень«.»
Что касается обнаружения сервисов — соглашусь, что LLM необходимо знать, где находятся инструменты, и как их использовать. Но это статическое содержимое. У нас уже есть AGENTS.md, .github/instructions, openapi.json и так далее
Разработчики на это реагируют. В компании Bruin MCP используется просто для предоставления документации; инструменты они вызывают через обычные команды CLI. В Donobu sпросто предоставляют спецификацию OpenAPI. Оба решения рабочие. Тем временем, в Google Trends тренд MCP выглядит бледно.
Я не виню авторов MCP в таком беспорядке. В экосистеме ИИ всё происходит быстро. Протокол MCP — жертва собственного успеха. В MCP: An (Accidentally) Universal Plugin System хорошо объяснена эта ситуация.
Нужно сделать шаг назад и обдумать, чего мы добиваемся. Нет такого закона, согласно которому LLM требовался бы новый протокол для взаимодействия с программами. Как правило, всё нужное уже есть. В тех случаях, когда чего‑то не хватает, нужно писать CLI, веб‑сервисы и документацию, опираясь на действующие стандарты.
Каков мой вывод? Может быть, лучше не спорить, что лучше — MCP или CLI — а начинать писать более качественные инструменты. Протокол — это просто прокладка. В данном случае важно, помогает ли ваш протокол агенту решать задачи или, наоборот, мешает.
‑Mario Zechner, MCP vs CLI: Benchmarking Tools for Coding Agents
Книга
А ещё я написал книгу The Missing README: A Guide for the New Software Engineer, можете приобрести её для себя или для кого‑нибудь ещё.
Приобрести книгу:«README. Суровые реалии разработчиков» можно приобрести на нашем сайте.