У спільноті AI-інженерів Model Context Protocol (MCP) часто подають як універсальний спосіб підключити великі мовні моделі до зовнішніх сервісів. Але коли справа доходить до реальних, масивних API, протокол раптом перетворюється на те, що в Cloudflare назвали «Mega Context Problem». Інженер Cloudflare Метт Кері, який працює над MCP та агентами, розповів, як компанія зіткнулася з цією стіною масштабування — і чому врешті дійшла висновку, що проблема не в MCP, а в тому, як влаштовані самі агенти.
Цей матеріал розбирає, як Cloudflare намагається зробити «кожен API — інструментом для агентів», не розбиваючи його на десятки урізаних сервісів і не перевантажуючи контекст LLM. Ключ до цього — прогресивне відкриття інструментів, пошук по них і наслідування того, як працюють звичайні CLI.
Коли OpenAPI стає надто великим навіть для «великих» моделей
Проблема починається з масштабів. REST OpenAPI-специфікація Cloudflare сьогодні — це приблизно 2,3 мільйона токенів і близько 2600 API-ендпойнтів. Для людини це вже величезний масив документації. Для агента, який має «знати» всі ці можливості одночасно, — майже гарантований крах.
Перший інстинкт у світі MCP виглядає логічно: взяти OpenAPI, автоматично перетворити кожен ендпойнт на MCP-інструмент і дати агенту повний доступ. Cloudflare так і зробила — і отримала близько 1,1 мільйона токенів лише на визначення інструментів. Це не запити користувача, не промпт системи, не історія діалогу, а тільки опис того, що вміють інструменти.
Навіть для моделей з найбільшими доступними контекстними вікнами це практично непридатний сценарій. Якщо весь контекст забивається описами інструментів, не залишається місця ні для задачі, ні для промптів, ні для проміжних міркувань моделі. MCP у такій конфігурації дійсно виглядає як «Mega Context Problem».
Це змусило Cloudflare піти шляхом, який обрали багато інших сервісів: розбити API на низку окремих MCP-серверів.
16 MCP-серверів, 2500 ендпойнтів і все одно неповна картина
Щоб обійти обмеження контексту, Cloudflare почала публікувати продуктово-орієнтовані MCP-сервіси. Замість одного гігантського набору інструментів з усіх 2600 ендпойнтів, компанія створила близько 16 окремих MCP-серверів, кожен з яких відповідав за певний продукт чи продуктовий блок.
На папері це виглядає розумно: кожен сервер описує тільки частину API, контекст не вибухає, агенту простіше орієнтуватися. На практиці виявився інший дефект: кожен із цих серверів покривав лише неповну підмножину ендпойнтів свого продукту.
Типовий приклад: у продукті може бути 30 ендпойнтів, але MCP-сервер для нього експонує лише шість інструментів. Решта можливостей просто не потрапляють до агента. У масштабі всієї платформи Cloudflare це означало, що приблизно 2500 ендпойнтів були розкидані по 16 сервісах, але жоден із них не давав повної картини навіть для свого домену.
Це компроміс, продиктований контекстними обмеженнями: щоб не перевантажувати модель, доводиться «обрізати» API. Але саме це й суперечить початковій меті — зробити «кожен API — інструментом для агентів», а не лише вибрані шматки.
У підсумку користувачі змушені самі обирати, з яким MCP-сервером працювати, миритися з неповним покриттям і вручну перемикатися між сервісами. Для агентів це теж погано: вони не можуть цілісно бачити можливості платформи, а отже, не здатні будувати складніші, крос-продуктові сценарії.
Саме на цьому етапі в Cloudflare зробили принциповий висновок: проблема не в MCP як такому.
Обмеження контексту — це не вада MCP, а вада агентів
Ключовий зсув мислення, до якого прийшла команда Cloudflare: ліміти контекстного вікна — це насамперед проблема дизайну агентів, а не протоколу MCP чи розміру API.
MCP — лише транспорт і формат для опису інструментів. Він не вимагає, щоб усі інструменти були одночасно завантажені в контекст LLM. Це рішення приймає клієнт, тобто агент. Саме агенти сьогодні часто працюють за наївною моделлю: «підключили MCP-сервер — значить, треба одразу завантажити всі його інструменти в контекст».
При такому підході будь-який достатньо великий API неминуче перетворюється на «Mega Context Problem». Але це не означає, що треба скорочувати API чи дробити його до безкінечності. Натомість потрібно змінити те, як агенти відкривають і використовують інструменти.
У Cloudflare сформулювали це так: не слід «зменшувати» API до розміру контексту, слід навчити агентів відкривати інструменти поступово, за потреби. Іншими словами, контекстне вікно — це обмеження клієнта, а не сервера. Відповідно, рішення має лежати на боці клієнта: у стратегіях вибору, завантаження та оновлення набору інструментів.
Ця ідея виводить на концепцію прогресивного відкриття інструментів.
Прогресивне відкриття: як навчити агента «дізнаватися» про інструменти
Прогресивне відкриття інструментів означає, що агент не повинен знати про всі можливості API наперед. Замість цього він має вміти поступово дізнаватися, які інструменти існують, які з них релевантні до поточного запиту, і підвантажувати тільки їх.
Це радикально відрізняється від нинішньої практики, коли клієнт підключає MCP-сервер і одразу «заливає» в контекст повний список інструментів разом з їхніми описами. При прогресивному підході MCP-сервер може як і раніше експонувати повний API, але клієнт ніколи не тягне все одразу.
Cloudflare розглядає три основні шляхи до такого прогресивного відкриття: використання CLI як самодокументованого інтерфейсу, пошук по інструментах і більш просунуті підходи, які компанія розвиває окремо. У цьому матеріалі ключовими є два перші — CLI та пошук.
CLI як еталон самовідкриття
Командні інтерфейси давно вирішили проблему самодокументації. Класичний приклад — CLI Cloudflare Wrangler. Якщо запустити просто wrangler, користувач бачить список доступних команд. Далі можна викликати wrangler d1 для роботи з базами даних, а потім wrangler d1 list — щоб отримати перелік баз. У будь-який момент можна додати --help, щоб побачити параметри, приклади та опис.
Для агента це ідеальне середовище: він може викликати команду, прочитати вивід, розібрати, які є підкоманди та аргументи, і крок за кроком будувати потрібну послідовність дій. Немає потреби завантажувати в контекст повний опис усього CLI; достатньо мати можливість виконувати команди та читати їхню довідку.
Wrangler у цьому сенсі — показовий приклад «самовідкриваного» інтерфейсу. Він не вимагає від агента попереднього знання всієї поверхні можливостей. Замість цього агент може інспектувати CLI динамічно, коли виникає потреба.
Проблема в тому, що CLI вимагає доступу до shell. Для багатьох сценаріїв, особливо у хмарних середовищах або в браузерних клієнтах, це або незручно, або взагалі неможливо. Саме тому Cloudflare шукає способи перенести принципи самовідкриття CLI в більш структурований, API-орієнтований світ MCP.
Пошук по інструментах: замість тисячі описів — шість-вісім релевантних
Другий підхід, який Cloudflare вже активно використовує, — це пошук по інструментах. Ідея проста: замість того, щоб завантажувати всі MCP-інструменти в контекст, клієнт спочатку виконує пошук за запитом користувача, а потім підтягує лише невелику підмножину інструментів, які, ймовірно, знадобляться.
На практиці це виглядає так. Користувач формулює задачу, наприклад: «Створи нового воркера». Агент або клієнтська частина робить пошук по каталогу інструментів: за ключовими словами, описами, можливо, за вбудованими векторними поданнями. Результатом стає невеликий список кандидатів — скажімо, K≈6–8 інструментів, які найбільше відповідають запиту.
Тільки ці 6–8 інструментів завантажуються в контекст моделі разом з описами параметрів і повертаємих значень. Далі LLM аналізує їх і обирає той, який найкраще підходить, наприклад, щось на кшталт workers.create. Решта інструментів залишаються в контексті як запасні варіанти, але їхня кількість все ще невелика, тому загальний обсяг токенів залишається керованим.
Cloudflare наводить орієнтовні цифри: у такому режимі можна мати близько 2100 токенів, з яких реально використовуються приблизно 500. Це все одно набагато краще, ніж намагатися вмістити 1,1 мільйона токенів описів усіх інструментів.
Такий підхід не ідеальний — іноді пошук може промахнутися, іноді доведеться робити кілька ітерацій. Але він дозволяє зберегти повноту API на сервері й водночас не перевантажувати контекст агента. Головне — інструменти більше не сприймаються як статичний список, який треба знати напам’ять; вони стають динамічним простором, у якому агент орієнтується за допомогою пошуку.
Чому MCP не «мертвий», а потребує інших клієнтів
На тлі цих експериментів у спільноті регулярно спливають дискусії: чи не виявився MCP помилкою? Якщо кожна спроба підключити великий API призводить до вибуху контексту, можливо, сам підхід із «інструментами» хибний?
Позиція Cloudflare тут доволі чітка. MCP — це протокол, а не стратегія керування контекстом. Він дозволяє експонувати API як набір інструментів, але не диктує, як саме клієнт має їх завантажувати, фільтрувати чи комбінувати. Проблема виникає тоді, коли клієнти реалізують MCP наївно: «є сервер — значить, треба витягнути всі інструменти й показати їх моделі».
Якщо ж дивитися на MCP як на транспортний шар для прогресивного відкриття, він цілком придатний для роботи з великими API. Сервер може надавати повну поверхню можливостей, а клієнт — відкривати її шматками: через пошук, через спеціальні «інструменти-індекси», через багатокрокові діалоги з сервером.
У цьому сенсі Cloudflare фактично перекладає відповідальність за масштабованість з боку сервера на бік клієнта. Замість того, щоб будувати десятки урізаних MCP-сервісів, компанія прагне мати повноцінний, єдиний API, а клієнти мають навчитися працювати з ним розумно.
CLI Wrangler тут виступає не як альтернатива MCP, а як орієнтир: API мають стати такими ж самодокументованими й самовідкриваними, як хороші CLI. Агенти повинні мати змогу «запитати» API, які в нього є можливості, які параметри потрібні, як виглядають типові сценарії — і робити це поетапно, а не через одноразове завантаження всього опису.
Висновок: масштаб MCP вирішується не скороченням API, а розумнішими агентами
Історія Cloudflare з MCP добре ілюструє, як швидко наївні рішення в AI-інфраструктурі впираються в фізичні обмеження. Перетворити 2,3 мільйона токенів OpenAPI на 1,1 мільйона токенів інструментів і спробувати втиснути це в контекст LLM — технічно можливо, але практично безглуздо. Розбити API на 16 MCP-серверів і експонувати лише частину ендпойнтів — працює, але суперечить ідеї повного доступу агентів до можливостей платформи.
Вихід, до якого приходить Cloudflare, полягає не в тому, щоб робити API меншими, а в тому, щоб робити агентів розумнішими. Контекстне вікно — це ресурс, яким потрібно керувати так само уважно, як пам’яттю чи CPU. Агенти мають навчитися відкривати інструменти поступово, шукати їх за потреби, інспектувати можливості API так само, як вони сьогодні інспектують CLI через --help.
MCP у цій картині не зникає і не «вмирає». Навпаки, він стає ще важливішим як стандартний спосіб підключення великих API до агентів. Але справжня робота зі зняття обмежень контексту відбувається на рівні клієнтів: у стратегіях пошуку інструментів, у механізмах прогресивного відкриття, у здатності агентів працювати з частковим знанням і доповнювати його в процесі.
Cloudflare вже робить ставку на ці підходи, поєднуючи ідеї з світу CLI, пошуку та агентних систем. Для індустрії це сигнал: проблема масштабування MCP для великих API не в тому, що протокол «занадто важкий», а в тому, що агенти поки що надто прості. І саме їх доведеться переосмислити, якщо ми хочемо, щоб «кожен API став інструментом для агентів» — без Mega Context Problem.