Этот MCP‑сервер можно было бы уложить в файле JSON

Сейчас много говорят о MCP (протоколе контекста модели). Я вообще не уверен, что он нужен

Сейчас много говорят о серверах стандарта MCP (протокол контекста модели) ^[1]. Идея проста: учим большие языковые модели (LLM) ^[2] взаимодействовать с другими программными системами. В процессе такой работы LLM могут учиться и давать реальный эффект. Например, вызвать веб‑сервер, чтобы позвонить по телефону, либо открыть инструмент для работы с интерфейсом командной строки (CLI) ^[3] и добавить пункт в список продуктов в приложении‑напоминалке для походов в магазин, и так далее. Чтобы выполнять такие операции, LLM должны знать, какие именно программы они вправе вызывать, и как это делать. Именно эту проблему и решает MCP: он сообщает LLM обо всех имеющихся в распоряжении программах, учит LLM ими пользоваться, а также прокладывает путь, по которому LLM может вызывать софт.

Разработчики пишут MCP‑серверы, обеспечивающие большие языковые модели ресурсами, промптами и инструментами. На сайте MCP эти концепции подробно обсуждаются ^[4], но в разделе Ключевые концепции MCP ^[5] они резюмированы так:

1. Ресурсы ^[6]: файлоподобные данные, которые могут считываться клиентами (например, отклики API или содержимое файлов)

2. Инструменты ^[7]: функции, которые LLM может вызывать (с одобрения пользователя)

3. Промпты ^[8]: заранее написанные шаблоны, при помощи которых пользователи могут решать конкретные задачи

Эти категории сформулированы вольно и могут запутать. На первый взгляд кажется, что ресурсы доступны только для чтения, а инструменты — только для записи. Но в документации на сервере MCP инструменты рассматриваются на примере searchFlights ^[9] — это операция только для чтения. Потом они ещё сильнее всё запутывают, показывая поиск авиарейсов как ресурс. Вот какое определение инструмента они дают:

{
  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 ^[10], описывающие потенциальные действия пользователя.

Весь этот протокол кажется мне каким‑то лишним. Промпты — это просто статическая документация, ресурсы — статические определения URL, а инструменты выглядят как определения вызовов удалённых процедур (RPC) ^[11]. Я попросил ChatGPT 5 Thinking ^[12] преобразовать определение инструмента searchFlights в определение OpenAPI ^[13] (в сущности, это и есть определение 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 ^[14], gRPC ^[15] и CLI. ChatGPT понимает определения OpenAPI. Уже существуют миллионы веб‑сервисов, также предоставляющих определения OpenAPI. А ChatGPT уже превосходит большинство людей в обращении с CLI — сами посмотрите, как Codex ^[16] управляется с командами sed, awk и grep. Недавно друг рассказал мне, что ему удалось научить ChatGPT пользоваться tmux ^[17]. Вот как об этом сказано в статье «MCP vs CLI: Benchmarking Tools for Coding Agents» ^[18]:

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).

Я видел ряд аргументов ^[19], призванных оправдать существование MCP:

1. Контекстное окно у LLM ограничено. В свою очередь, документация OpenAPI занимает слишком много места в этом контексте.

2. Многие сервисы не слишком хорошо документированы; к ним не предоставляется спецификация API.

3. LLM нужно каким‑то образом обнаруживать, какие инструменты есть у неё в распоряжении.

Скептически к этому отношусь. Пожалуй, MCP действительно позволяет втиснуть в контекстное окно пару дополнительных инструментов. Может быть, с ним модели работают чуть‑чуть быстрее. Документация к OpenAPI действительно кажется несколько многословной. Но как долго это будет иметь значение?

В прошлом году речь шла о модели на миллион токенов. Теперь в OpenRouter ^[20] есть модели на 2 миллиона токенов ^[21]. Не стоят на месте исследования по более мелким моделям, тонкой настройке, в таком духе. С такой точки зрения ^[22] MCP кажется просто временным костылём.

Последний довод о том, что многие сервисы плохо документированы справедлив для внутрикорпоративных сервисов больших предприятий. Например, это отмечает Джейк Мэнникс ^[23] в своём треде ^[24]. Я слышал, что протокол MCP шире всего задействован именно в этом сегменте.

С клиентоориентированными SaaS API совсем другая история. Известно, насколько ^[25] хорошо документированы ^[26] многие из них ^[27]. Некоторые сложноваты, но часто это неотъемлемая сложность ^[28] (могу это подтвердить по опыту ^[29] работы с API WePay ^[30]).

Более того, аргумент создаёт впечатление ^[31], как будто те самые люди, которые написали плохие спецификации к OpenAPI, напишут хорошие спецификации к MCP. Неубедительно. (Опять же, даже если бы им это было под силу, почему бы не написать конечную точку в стиле OpenAPI или как инструмент CLI?)

«Не понимаю этого баттла между CLI и MCP. Может быть, я что‑то упускаю?»

Почему MCP может послужить хорошей заменой такому локализованному инструменту как CLI? В лучшем случае, это кажется дискуссией об использовании песочниц, то есть, о том, где запускается MCP, а не где фактически работает — фактически же он интегрирован в сетевой уровень«.»

Что касается обнаружения сервисов — соглашусь, что LLM необходимо знать, где находятся инструменты, и как их использовать. Но это статическое содержимое. У нас уже есть AGENTS.md ^[33], .github/instructions ^[34], openapi.json ^[35] и так далее

Разработчики ^[36] на это ^[37] реагируют ^[38]. В компании Bruin ^[39] MCP используется просто для предоставления документации ^[40]; инструменты они вызывают через обычные команды CLI. В Donobu ^[41] sпросто предоставляют спецификацию OpenAPI. Оба решения рабочие. Тем временем, в Google Trends тренд MCP выглядит бледно.

^[42]

Я не виню авторов MCP в таком беспорядке. В экосистеме ИИ всё происходит быстро. Протокол MCP — жертва собственного успеха. В MCP: An (Accidentally) Universal Plugin System ^[44] хорошо объяснена эта ситуация.

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

Каков мой вывод? Может быть, лучше не спорить, что лучше — MCP или CLI — а начинать писать более качественные инструменты. Протокол — это просто прокладка. В данном случае важно, помогает ли ваш протокол агенту решать задачи или, наоборот, мешает.

‑Mario Zechner, MCP vs CLI: Benchmarking Tools for Coding Agents ^[18]

Книга

А ещё я написал книгу The Missing README: A Guide for the New Software Engineer ^[45], можете приобрести её для себя или для кого‑нибудь ещё.

Приобрести книгу:«README. Суровые реалии разработчиков» можно приобрести на нашем сайте. ^[46]