У спільноті AI-інженерів зараз активно обговорюють, як зробити будь-який API по-справжньому доступним для агентів — не лише через HTTP чи CLI, а як «рідний» інструмент у середовищі моделей. Один із тих, хто працює над цим на передовій, — Метт Кері, інженер Cloudflare, який займається MCP (Model Context Protocol) та агентами. На базі досвіду компанії з її гігантським API він окреслює досить конкретне бачення того, яким стане MCP у найближчі роки: безстанні сервери, програмне викликання інструментів через виконання коду, перетворення одноразових планів агентів на стійкі автоматизації та глибока інтеграція MCP у TypeScript‑фреймворки.
Це бачення не про ще один «шар обгортки» навколо API, а про зміну моделі: від «LLM викликає десятки окремих тулів» до «LLM пише й запускає код проти повноцінного SDK», а інфраструктура навколо цього стає такою ж керованою, як сучасні хмарні сервіси.
Безстанні MCP‑сервери: чому пам’ять агента не повинна жити в процесі
Одна з ключових ідей Cloudflare — зробити безстанність базовим патерном для MCP‑серверів. Компанія вже побудувала TypeScript‑SDK для MCP і рухається до того, щоб саме такий підхід став «за замовчуванням».
Традиційно багато агентних систем тримають стан розмови або сесію безпосередньо в процесі сервера, який обробляє виклики інструментів. Це зручно на ранніх етапах, але погано масштабується: кожен інстанс MCP‑сервера перетворюється на «теплу» істоту з власною пам’яттю, яку важко горизонтально масштабувати, перезапускати, оновлювати чи переносити між середовищами.
Cloudflare натомість прагне зробити MCP‑сервери максимально схожими на класичні HTTP‑сервіси: кожен запит — самодостатній, сервер не зберігає довготривалий контекст, а будь-яка пам’ять агента живе поза процесом. Це означає, що:
- MCP‑сервери можна масштабувати як звичайні безстанні мікросервіси.
- Оновлення, деплой, перезапуск не вимагають «міграції» стану.
- Різні клієнти (агенти) можуть по-різному керувати пам’яттю, не змінюючи сервер.
Паралельно Cloudflare говорить і про безстанні «agent loops» на боці клієнтів MCP. Ідея в тому, щоб сам цикл планування й виконання дій агентом був організований так, що стан можна вмикати чи вимикати у «хмарно‑нативний» спосіб. Пам’ять, історія, довготривалі профілі користувачів — усе це має бути відокремлено від конкретного процесу, який виконує інструмент чи код.
Такий поділ дозволяє:
- тримати довготривалу пам’ять у спеціалізованих сховищах (векторні бази, KV, БД),
- масштабувати обробку запитів без прив’язки до сесій,
- легше будувати мультиагентні системи, де кілька агентів працюють з одними й тими самими даними, але через різні MCP‑сервери.
Фактично MCP‑сервер у цьому баченні — це тонкий шар над логікою, який не знає нічого про «історію розмови», а лише виконує чітко визначені операції.
Від схем інструментів до коду як головного примітиву
Ще одна важлива зміна, яку прогнозує Cloudflare, стосується того, як саме агенти будуть викликати інструменти. Сьогодні типовий підхід MCP‑клієнтів — це набір окремих тулів із чітко описаними схемами параметрів. LLM обирає потрібний тул, формує аргументи, клієнт викликає його, отримує результат, і так по колу.
Cloudflare очікує, що клієнти MCP поступово перейдуть до програмного викликання інструментів, де головний тул — це примітив виконання коду. Замість десятків чи сотень окремих схем інструментів агент отримує можливість написати фрагмент коду (наприклад, TypeScript), який використовує повноцінний SDK, і передати його в єдиний «code‑execution» інструмент.
У такій моделі:
- інші можливості системи доступні не як окремі MCP‑інструменти, а через згенерований код, що викликає відповідні методи SDK;
- контекст, який потрібно показати моделі, різко скорочується: замість опису сотень тулів достатньо опису SDK і самого примітиву виконання коду;
- логіка стає більш виразною: агент може будувати цикли, умовні гілки, обробку помилок, агрегацію результатів — усе в одному фрагменті коду, а не через ланцюжок розрізнених викликів.
Cloudflare вже має для цього технічну основу: TypeScript‑SDK для MCP, який дозволяє моделі писати код проти типізованого інтерфейсу, згенерованого з OpenAPI‑специфікацій. Але ключовий зсув має відбутися на боці клієнтів: вони повинні навчитися сприймати «виконання коду» як базовий інструмент, а не як щось екзотичне.
Це також змінює роль MCP як протоколу. Замість того, щоб бути транспортом для великої кількості дрібних інструментів, MCP стає каналом, через який агенти надсилають програми, що взаємодіють з API. Інструменти в класичному розумінні не зникають, але відходять на другий план, поступаючись місцем коду як універсальній «надбудові».
Одноразові плани агентів як довготривалі автоматизації
Як тільки код стає основним способом взаємодії агента з сервісами, природним наступним кроком стає повторне використання цього коду. Cloudflare очікує, що MCP‑клієнти почнуть підтримувати збереження згенерованих агентами скриптів як міні‑скриптів для повторюваних завдань.
Сьогодні типовий сценарій виглядає так: користувач формулює запит, агент планує дії, викликає інструменти або пише код, виконує його, повертає результат — і все. План і код живуть лише в межах однієї сесії. Якщо користувач хоче зробити щось подібне завтра, агент знову проходить той самий шлях.
У моделі, яку описує Cloudflare, клієнт MCP має вміти:
- зберегти згенерований скрипт як окремий артефакт,
- дати йому ім’я, опис, можливо, параметри,
- запускати його повторно без повного перепланування,
- прив’язувати до розкладу, подій або тригерів — фактично як cron‑завдання.
Це перетворює агентів із «розумних чат‑ботів» на конструктор автоматизацій. Разове завдання на кшталт «перевірити статус усіх воркерів і надіслати звіт» стає основою для регулярного джобу, який виконується щодня, щогодини або за подією. Агенти перестають бути лише інтерфейсом до API і стають генераторами мікросервісів, які живуть довше за одну розмову.
Така можливість особливо логічна в поєднанні з безстанними серверами й безстанними agent loops. Стан сценарію, його конфігурація, розклад — усе це зберігається в окремому сховищі, а виконання кожного запуску — це окремий, ізольований виклик коду через MCP.
Для розробників це означає, що:
- з’являється новий клас артефактів — «агентні скрипти», які варто версіонувати, тестувати, можливо, навіть рев’ювати;
- інтерфейси клієнтів мають підтримувати каталог таких скриптів, їх редагування та моніторинг;
- інфраструктура повинна вміти запускати їх у безпечних середовищах, не ризикуючи стабільністю основних API.
Паралельні пісочниці й жорсткий rate limiting: як не дозволити агентам «зламати» ваш API
Перехід до коду як основного інструменту має й темний бік: агенти отримують можливість запускати багато екземплярів згенерованого коду паралельно. Якщо кожен такий екземпляр має доступ до API, навантаження може зрости лавиноподібно.
Cloudflare прямо попереджає: API повинні мати сильне обмеження швидкості, тому що агенти здатні запускати код у паралельних пісочницях і серйозно навантажувати сервіси, якщо їх не стримувати.
У моделі з динамічними воркерами або іншими ізольованими середовищами кожен запуск коду — це окремий «міні‑процес», який може:
- робити мережеві запити до API,
- виконувати обчислення,
- працювати з даними користувача.
Якщо клієнт або сервер не накладає жорстких лімітів, агент, що намагається оптимізувати час виконання, може несвідомо запустити десятки чи сотні паралельних скриптів. Для API це виглядає як раптовий сплеск трафіку, який легко перевищує допустимі межі.
Тому в майбутній екосистемі MCP стають критичними кілька речей:
- глобальні й пер‑клієнтні rate limits на рівні API;
- обмеження на кількість одночасних пісочниць, у яких може виконуватися код;
- політики доступу до мережі з кожної пісочниці (whitelist доменів, заборона зовнішніх запитів за замовчуванням);
- контроль за часом виконання й ресурсами (CPU, пам’ять) кожного скрипта.
Cloudflare вже будує таку модель навколо своїх динамічних воркерів: пісочниці можна конфігурувати так, щоб вони не бачили process.env, не мали доступу до мережі або могли звертатися лише до певних доменів. У поєднанні з rate limiting це створює кероване середовище, де агенти можуть писати й виконувати код, але не можуть випадково (або навмисно) вивести API з ладу.
Для розробників API це означає, що підготовка до «агентної ери» — це не лише документація й SDK, а й серйозна робота над політиками доступу, лімітами й моніторингом.
MCP як прапорець у фреймворку: MCP = true для всього стеку
Щоб MCP став по-справжньому масовим, його підтримка має з’явитися там, де живе основна логіка сучасних веб‑додатків, — у фреймворках. Cloudflare планує, щоб підтримка MCP‑серверів перетворилася на легкий middleware або навіть на простий прапорець у великих TypeScript‑фулстек‑фреймворках.
Ідея полягає в тому, щоб:
- MCP TypeScript‑SDK став настільки малим і самодостатнім, що його можна було б вбудувати без суттєвого оверхеду;
- фреймворки на кшталт Next.js могли нативно експонувати всі свої API не лише через HTTP, а й через MCP;
- розробнику було достатньо додати щось на кшталт
MCP = trueу конфігурацію, щоб увімкнути цей режим.
У такому сценарії один Next.js‑додаток може одночасно:
- обслуговувати тисячі HTTP‑ендпоінтів для класичних клієнтів,
- експонувати ті самі ендпоінти як MCP‑інструменти або як частину SDK для кодового викликання,
- використовувати одну й ту саму кодову базу, типи й бізнес‑логіку.
MCP‑шар у цьому випадку стає тонким middleware, який:
- транслює запити від агентів у виклики існуючих функцій або роутів,
- забезпечує автентифікацію й авторизацію в контексті агентів,
- додає необхідні метадані для коректної роботи інструментів або SDK.
Cloudflare очікує, що коли SDK стане достатньо легким, великі API‑провайдери й постачальники сервісів доступності зможуть «увімкнути MCP» для всього свого API одним прапорцем. Це, у свою чергу, стимулюватиме їх переходити до «codemode»‑підходу, де повний API стає доступним агентам через типізований SDK і примітив виконання коду.
Для екосистеми це означає:
- різке зниження бар’єру входу для розробників, які хочуть зробити свій сервіс «agent‑ready»;
- уніфікацію підходів: ті самі типи й функції використовуються і в HTTP‑клієнтах, і в агентних сценаріях;
- можливість для фреймворків стати «першокласними громадянами» у світі MCP, а не просто хостами для окремих серверів.
Розширення екосистеми клієнтів: від кількох реалізацій до масового прийняття
Сьогодні кількість по‑справжньому зрілих MCP‑клієнтів невелика. Cloudflare прямо визнає, що екосистема ще молода, але очікує її швидкого зростання в міру того, як реалізація клієнтів спрощуватиметься.
Кілька факторів мають прискорити цей процес:
- поява чітких патернів безстанних agent loops, які легко вбудовуються в існуючі платформи;
- стандартизація примітиву виконання коду як основного інструменту;
- підтримка збереження й повторного використання скриптів на рівні клієнтів;
- інтеграція MCP у популярні фреймворки через легкі middleware або прапорці конфігурації.
У такому світі клієнт MCP — це не обов’язково окремий «спеціалізований» застосунок. Це може бути:
- IDE з вбудованим агентом, який використовує MCP для доступу до внутрішніх сервісів;
- корпоративний портал, де агент допомагає співробітникам працювати з внутрішніми API;
- хмарна платформа, де агенти автоматизують розгортання, моніторинг і налаштування.
Коли реалізація клієнта зводиться до підключення легкого SDK і конфігурації кількох політик, кількість таких клієнтів може зрости на порядки. А це, у свою чергу, створює тиск на API‑провайдерів: якщо MCP‑клієнти стають масовими, відсутність MCP‑поверхні для API починає виглядати як обмеження.
Висновок: MCP рухається до моделі «код + безстанність + фреймворки»
Вектор, який окреслює Cloudflare, доволі чіткий. Майбутнє MCP — це:
- безстанні сервери, які не тримають пам’ять агента в процесі;
- безстанні agent loops, де стан вмикається й вимикається як хмарний ресурс;
- програмне викликання інструментів через примітив виконання коду й типізовані SDK;
- перетворення одноразових агентних планів на стійкі міні‑скрипти й cron‑подібні автоматизації;
- жорсткі rate limits і контроль ресурсів, щоб паралельні пісочниці не ламали API;
- глибока інтеграція MCP у TypeScript‑фреймворки, аж до моделі «
MCP = true» у конфігурації.
У цій моделі MCP перестає бути «ще одним способом описати інструменти» і стає інфраструктурним шаром, який дозволяє агентам писати, виконувати й повторно використовувати код поверх існуючих API. А завдання розробників — підготувати свої сервіси до такого світу: зробити їх безпечними, типізованими й готовими до того, що з ними працюватимуть не лише люди, а й агенти.