MCP против REST: счёт приходит в токенах

Подключите к ассистенту официальный MCP-сервер GitHub со всеми включёнными наборами инструментов — и разговор начнётся со счёта примерно на 17 600 токенов. Вопроса ещё никто не задал. Это цена одних только описаний инструментов: названия, фраза о том, что каждый делает, форма аргументов, которые он принимает. И платится она заново в каждом запросе, пока сервер подключён.

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

Эта статья — про этот прайс-лист: сколько стоят описания, почему от добавления инструментов ассистент работает хуже, а не лучше, где обычный HTTP-вызов по-прежнему правильный ответ и что со счётом можно сделать.

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

В 4–32 раза — это не накладные расходы. Накладные расходы меряются процентами. Здесь другой порядок, и стоит сказать прямо: для любой задачи, которую можно решить скриптом, MCP платить не стоит. Ночному заданию, которое читает файл и отправляет его на эндпоинт, не нужны ни описания инструментов, ни модель, которая их читает, ни счёт за это. Цена начинает что-то покупать ровно там, где список вызовов больше нельзя написать заранее.

Задача, которая уверенно решалась с десятью инструментами, начинает разваливаться с пятьюдесятью. Первым делом винят объём — больше текста, полнее окно, хуже ответы, — но объём тут меньшая половина беды. Дело в выборе. Модель берёт один пункт из списка, и каждый непопавший пункт — это помеха, которую пришлось прочитать и отбросить. Два инструмента, описания которых различаются одним придаточным, — это не два варианта, а подбрасывание монетки, которое модель проводит за вас, молча, на каждом вызове. Длинные списки вдобавок подталкивают планировать в вызовах, а не в шагах: так работа на три вызова превращается в одиннадцать.

Второй расход обсуждают реже, а он часто больше первого: ответы инструментов. Описания — фиксированный платёж за запрос. Ответы идут по счётчику. Вызов «покажи пул-реквесты» возвращает объекты авторов, метки времени, ссылки на аватарки и метаданные ревью, которых никто не просил, и всё это ложится в то же самое окно. Ситуация, когда за сессию на ответы инструментов уходит больше контекста, чем на каталог того, что они умеют, — совершенно нормальная.

Третий расход я оплатил лично, и его нет ни в одном счёте. У меня есть небольшой MCP-сервер: он ведёт календарь публикаций и раскладывает статьи по площадкам. Адаптер Medium управляет залогиненным Chrome по отладочному протоколу — API для записи у Medium брошен гнить. Работу адаптер считал сделанной в тот момент, когда адрес в браузере менялся на редактор нового черновика, и тут же закрывал вкладку. А Medium в это время сохраняет содержимое редактора по частям, фоновыми запросами, которые ещё не закончились. Всё, что не успевало дойти до сервера к закрытию вкладки, пропадало молча. Адаптер при этом возвращал валидный URL и успех.

Аудит 25 июля 2026 года прошёл по всем 25 записям календаря, у которых был адрес публикации. Двенадцать живых постов на Medium оказались обрезаны: в них осталось от 41 до 72% текста, у части пропали блоки кода. Ещё один, тринадцатый адрес отдавал HTTP 410. Короткие анонсы примерно на 1500 знаков уцелели — они успевали сохраниться до закрытия вкладки. Остальное не пострадало: dev.to, Stack Overflow и Hacker News доехали целиком. Вот на чём стоит задержаться: Stack Overflow и Hacker News публикуются через тот же браузер, что и Medium. Граница проходила не между API и браузером. Она проходила между одной отправкой и многими: эти трое отдают весь текст одним POST, а Medium принимал его частями, и мой адаптер переставал смотреть после первой.

Почему этого неделями не замечали — причина самая обыкновенная. Имевшаяся проверка спрашивала, жив ли адрес, а не на месте ли статья. Пост открывается. Ссылка работает. Нет только второй половины.

Отсюда два вывода, и ни один из них не про Medium. Первый: инструмент, вернувший успех, ничего не сообщил о том, сделана ли работа. MCP различает две ступени ошибок — сломался протокол или инструмент отработал и принёс плохую новость, — а это третья, которую не видит ни одна из двух: с точки зрения протокола вызов прошёл отлично. Второй вывод — про токены. В том запросе модель заплатила за двадцать описаний инструментов, заплатила ещё раз за сам вызов, получила ok и двинулась к следующему пункту плана. Расход был настоящий. Работа сделана не была. Анонимную статистику про «столько-то процентов вызовов не доходят» цитируют часто, а источник называют почти никогда. Что стоит за ней, я не знаю. Знаю, что стояло за моей, — и что, когда это случится у вас, вам об этом не скажет никто.

Рядом с первым багом жил второй, и он поучительнее. Адаптер ловил баннер об ошибке сохранения, разыскивая в тексте страницы фразы вроде «something is wrong». В одной из публикуемых статей была строчка «if something is wrong you flip back». Успешный прогон объявили провалившимся, а повтор создал дубль черновика. Статус, вычитанный из прозы, — не статус.

REST не стал хуже от появления моделей. Он остался ровно таким же хорошим, каким был, и случаи, в которых он хорош, по-прежнему составляют большинство.

Оставляйте его везде, где вызовы известны заранее и их делает программа, а не выбирает модель. Если список вызовов можно перечислить, пока пишешь код, — перечислите: вы получите компилятор, ревью, стектрейс и тесты, а выбор инструмента моделью не даст вам ничего из этого. Большой поток однотипных запросов — второй очевидный случай: четверть века HTTP-кэширования, ETag, CDN, балансировщиков и лимитов на ключ уже лежат и ждут, написанные и отлаженные другими людьми, и ни одна из этих вещей не знает, что такое MCP-сервер. У публичного интерфейса своя причина остаться REST API: внешним разработчикам нужны стабильность, версии и описание OpenAPI, которое читают один раз при интеграции, а не гибкость, которую придётся выяснять заново на каждом вызове. И есть цена. У REST-вызова она заносится в таблицу; MCP-вызов стоит столько, сколько пользователь подключил себе именно сегодня.

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

Цена покупает ровно одно — то самое, что делает ИИ-агента агентом, а не скриптом: возможность не знать в момент написания программы, что у неё попросят. Там, где это незнание настоящее, счёт справедлив. Там, где оно привычка, вы платите за то, чтобы не принимать решение.

Решают два вопроса, и задавать их надо по порядку.

Первый: кто вызывает — программист или модель? Если программист, спор закончился, не начавшись. У вас есть документация, типы, компилятор и ревью, и вся машинерия, ради которой существует MCP, вам не нужна. Делайте HTTP-вызов.

Второй вопрос имеет смысл, только если на первый ответили «модель»: известен ли список действий на момент выпуска? Если он известен, мал и неизменен — три действия, всегда одни и те же, — вас почти полностью выручит function calling поверх собственного API: вы описываете модели три функции прямо в запросе и обходитесь без протокола между частями. Model Context Protocol начинает окупаться там, где набор по-настоящему открыт: пользователь сам подключает то, что ему нужно; сервер, которого вы в глаза не видели, объявляет свои инструменты на ходу; следующий шаг зависит от результата предыдущего так, что заранее это не перечислить.

На практике ответ почти всегда «и то, и другое», и это не дипломатический компромисс, а то, как системы выглядят на самом деле. Мой MCP-сервер — обёртка перед тем же админским API, которым пользуется веб-интерфейс: пятьсот строк определений инструментов и примерно столько же в адаптерах и проверяльщиках за ними. Эндпоинты те же самые, различается только способ аутентификации: браузеру — сессионная кука, серверу — API-ключ. Ничего в календаре не переделывалось «под MCP», и не требовалось. Обёртка добавляет ровно то, что нужно модели и не нужно программе: описания, написанные для чтения, а не для разбора; намеренно более узкий набор действий, чем есть в API; и точку, где человек может посмотреть, что сейчас уйдёт, и сказать «нет».

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

Механизмов четыре, и одна привычка обыгрывает почти все.

Поиск по инструментам появился в конце 2025-го, в наборе advanced tool use у Anthropic, и выносит каталог из запроса: полный список держит клиент, а модели выдаётся только то, что подходит к текущей задаче. В том же анонсе сообщается о сокращении стартовой стоимости на 95%. Как в общее правило я в это не верю. Цифра верна для сборок, где инструментов заведомо было слишком много, то есть она меряет чью-то прежнюю ошибку, а не эффект механизма. Возьмите продуманный набор из пятнадцати инструментов — и ничего похожего на 95% не увидите: там попросту нет 95% лишнего, которое можно убрать.

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

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

Кэшируемые списки инструментов пришли с редакцией 2026-07-28: подсказка от сервера, что это пока можно не перезапрашивать, — прямое следствие того, что протокол стал stateless. Механическая, скромная и полезнее всего ровно там, где в счёте преобладают описания.

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

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

Это вторая статья из трёх. Первая — про то, откуда взялись MCP и REST и почему июльская редакция 2026-го развернула MCP обратно к REST; третья — про то, из чего на самом деле сделан MCP-сервер.

Замеры стоимости токенов: публичные разборы GitHub MCP Server и сводные обзоры контекстных расходов конца 2025 — начала 2026 года; обсуждение issue #2808 в репозитории спецификации о накладных расходах схем. Спецификация MCP публикуется на modelcontextprotocol.io; здесь использованы редакции 2025-06-18 и 2026-07-28. Материал Anthropic о выполнении кода вместо цепочек вызовов. Инцидент с обрезанными публикациями от 25 июля 2026 года и аудит, который его нашёл, описаны в рантайм-справочнике проекта docs/publishing.md.