API для AI-агентів: від MCP до власних ендпоінтів

Коли LLM навчилися викликати функції

В епоху GPT-3 взаємодія з LLM означала передати йому промпт і отримати текст у відповідь. Знання моделі були великими, але статичними, зафіксованими в тому стані, який містили навчальні дані. Ви могли попросити її пояснити квантові обчислення або написати чернетку електронного листа, і вона створювала правдоподібний текст. Але вона не могла перевірити сьогоднішню погоду, зробити запит до бази даних або виконати дію в реальному світі.

Функція, яка це змінила, отримує напрочуд мало визнання. Вона дала моделі вибір між генеруванням тексту та викликом функції. Замість того щоб завжди створювати наступний токен, модель тепер могла вивести структурований JSON-об’єкт із назвою функції та її аргументами. Середовище виконання запускало цю функцію, передавало результат назад моделі, і модель продовжувала звідти. Стаття ReAct (Yao et al., 2022) формалізувала це як цикл Thought-Action-Observation. Модель міркує, що робити, виконує дію (викликає інструмент), спостерігає результат і повторює. Кожен серйозний AI-агент у 2026 році працює на певній версії цього патерну.

Цикл

Claude Code, OpenClaw, Codex, Devin і десятки інших агентних систем працюють однаково. Викликати інструмент, спостерігати результат, вирішити, що робити далі, повторити. Simon Willison добре це сформулював: «LLM-агент запускає інструменти в циклі, щоб досягти мети».

Claude Code, наприклад, використовує однопотоковий головний цикл без мультиагентного рою або складного графа оркестрації: while(tool_call) -> execute -> feed results -> repeat.

Дослідження Anthropic про автономність агентів показує, що тривалість ходів у Claude Code майже подвоїлася за три місяці, з 25 до понад 45 хвилин. Користувачі дедалі більше довіряють циклу працювати самостійно. Дані показують, що досвідчені користувачі переривають частіше (переходячи від схвалення кожної дії до стратегічного моніторингу), тоді як сам агент просить уточнення більш ніж удвічі частіше, ніж користувачі його переривають.

Цей патерн циклу трапляється всюди: в агентах для програмування, ботах підтримки клієнтів і контролерах роботів.

Що вважається інструментом?

LLM дають нам значну свободу у виборі рівня абстракції, на якому має працювати інструмент. На одному полюсі є дуже конкретні API endpoint: «створити контакт HubSpot із цими 12 полями». На іншому є інструменти на кшталт «запусти цю bash-команду» або «виконай цей Python-код», які фактично означають «роби що завгодно».

Devin працює з трьома інструментами: shell, редактор коду, браузер. Основним інструментом Claude Code також є shell. OpenClaw використовує динамічну систему плагінів-навичок (skills). Тренд в агентних інструментах для програмування зміщується до меншої кількості, але більш загальних інструментів, а не до багатьох спеціалізованих.

Simon Willison зауважив, що MCP «спочатку різко набрав популярність, але потім став здаватися менш центральним» для агентів, що пишуть код, тому що bash є універсальним інструментом. Файли й скрипти є примітивом із меншими накладними витратами, ніж повні реалізації MCP-серверів. Якщо агент може писати й виконувати код, він може зробити майже все без потреби в окремому визначенні інструмента.

Але інструменти загального призначення працюють для агентів загального призначення. Для доменних AI-агентів (підтримка клієнтів, продажі, внутрішні операції) потрібні доменні інструменти. Ваш агент підтримки не повинен писати Python, щоб перевірити статус замовлення. Він має викликати чітко визначений API endpoint із зрозумілими параметрами та передбачуваними відповідями. Проєктування набору інструментів стає продуктовим рішенням.

Що тепер означає API endpoint

Для AI-агентів API endpoint функціонує як декларація можливості. Публікація endpoint означає, що ви (або ваш AI-агент) тепер можете зробити щось, що раніше було неможливим.

Це працює в обидва боки. Постачальник програмного забезпечення публікує API, щоб інші могли інтегруватися з його продуктом. Але AI-агент також може самостійно знаходити endpoint, шукаючи в документації, читаючи специфікації OpenAPI або буквально гуглячи, як виконати завдання.

MCP-сервер — це кураторський пакет API endpoint із попереднім уявленням про те, як їх слід використовувати. Автор MCP уже ухвалив рішення про те, які endpoint відкрити, як їх назвати, які параметри показати і, неявно, які робочі процеси підтримувати. Ця кураторська робота є і сильною стороною (зручність, стандартизація), і слабкою (жорсткість, нав’язані межі функціональності). Сервер Notion є конкретним прикладом: він публікує 28 інструментів, а агенту довідкового центру потрібні чотири з них, розділені між двома підключеннями.

MCP обмінюють контроль на простоту використання. У 2026 році AI пише більшість інтеграційного коду. Якщо агент може прочитати API-документацію й сам написати інтеграцію, аргумент про «простоту використання» для MCP слабшає. Шар MCP може бути найважливішим у перехідний період, доки інструменти ще не наздогнали можливості моделі. Посібник Anthropic з патернів проєктування використання інструментів є практичним довідником для структурування схем інструментів незалежно від того, використовуєте ви MCP чи окремі endpoint.

Ще одна пов’язана тенденція: llms.txt — це запропонований стандарт, за яким вебсайти публікують файл /llms.txt, щоб спрямовувати AI-моделі до ресурсів із високою цінністю. Anthropic, Cloudflare, Docker і Stripe вже його впровадили. MCP стандартизує виклик інструментів; llms.txt стандартизує виявлення документації. Обидва підходи намагаються зробити інтернет зрозумілішим для машин, але з різних боків.

Що таке API endpoint у контексті AI-агентів?

API endpoint — це конкретна URL-адреса, яка приймає структуровані вхідні дані й повертає структуровані вихідні дані. Для AI-агентів кожен endpoint представляє окрему можливість, тобто те, що агент може зробити в реальному світі. Опис endpoint, визначення параметрів і відповіді з помилками слугують інструкцією для агента. Що краще задокументований endpoint, то надійніше агент може ним користуватися.

На відміну від розробників-людей, які можуть читати навчальні посібники і виконувати ітеративне налагодження, агент покладається на схему й опис endpoint, щоб зробити один правильний виклик. Саме тому API-документація, розроблена для споживання AI, важливіша, ніж будь-коли. Лише 24% розробників зараз проєктують API з урахуванням AI-агентів, попри те, що 89% використовують AI у своїх робочих процесах.

Що таке MCP (Model Context Protocol)?

MCP — це відкритий протокол, представлений Anthropic, який стандартизує те, як AI-агенти підключаються до зовнішніх інструментів і джерел даних. Це щось на кшталт USB-C для AI. Єдиний конектор, який може реалізувати будь-який постачальник інструментів і який може використовувати будь-який AI-агент. MCP-сервер відкриває набір інструментів (по суті, API endpoint) зі стандартизованими схемами, а MCP-клієнт (агент) може знаходити й викликати їх без власного інтеграційного коду. Докладніше технічне пояснення див. у нашій статті Пояснення MCP. Практичний опис MCP у продакшені див. у нашому аналізі реальних викликів побудови на MCP Shopify.

Спектр контролю в Quickchat AI

Quickchat AI дає три способи надати AI Agent зовнішні інструменти. Вони розташовані на спектрі від найбільш автоматизованого до найбільш контрольованого. Кожен підхід має інший компроміс між швидкістю налаштування й точністю поведінки.

Remote MCP: підключити й запустити

Remote MCP — це найшвидший спосіб підключити AI Agent до зовнішньої функціональності. Ви надаєте URL MCP-сервера, Quickchat AI підключається до нього, знаходить усі доступні інструменти й дає вам вибрати, які з них має використовувати агент.

Як це налаштувати:

1. Перейдіть до AI Actions у панелі керування Quickchat AI
2. Натисніть “Add Remote MCP”
3. Вставте URL MCP-сервера (наприклад, https://mcp.example.com/sse)
4. За потреби додайте токен автентифікації або власні заголовки (ці два варіанти взаємовиключні)
5. Натисніть “Connect”. Quickchat AI знайде всі доступні інструменти й покаже їхні назви
6. Увімкніть або вимкніть окремі інструменти, щоб контролювати, які з них може використовувати агент
7. Встановіть прапорець “default tool is active”, щоб контролювати, чи будуть новознайдені інструменти автоматично ввімкнені або вимкнені

Що відбувається під капотом:

Коли ви натискаєте Connect, Quickchat AI автоматично визначає транспортний протокол за URL. Якщо URL містить sse, використовується транспорт SSE; інакше за замовчуванням використовується streamable_http. Коли ви надаєте токен автентифікації, його надсилають як токен Bearer у заголовку Authorization.

Фільтрація інструментів працює через трирівневу систему. Кожен інструмент з MCP-сервера перевіряється за двома наборами: явно ввімкнені інструменти завжди включаються, явно вимкнені інструменти завжди виключаються, а будь-який інструмент, якого немає в жодному наборі, використовує вибране вами налаштування “default tool is active”. Це означає, що коли MCP-сервер додає нові інструменти, ви контролюєте, чи вони автоматично доступні вашому агенту, чи потребують явної активації.

Під час виконання, коли починається розмова, завантажуються всі активні підключення Remote MCP для агента. Інструменти отримуються й фільтруються відповідно до конфігурації кожного підключення, а унікальність назв інструментів перевіряється серед усіх джерел (із попередженням, якщо знайдено дублікати).

Компроміс: ви отримуєте негайний доступ до всього, що відкриває MCP, але маєте обмежений контроль над описами інструментів, визначеннями параметрів або тим, як агент вирішує їх використовувати. Як ми з’ясували під час побудови AI Agent на MCP Shopify, перехід від демо до продакшену потребує ретельного налаштування, яке пакетний підхід MCP може ускладнювати.

Див. також: підключіть свого агента до віддаленого MCP-сервера, Як запустити Quickchat AI MCP, міркування щодо безпеки MCP, документація Quickchat AI: канал MCP.

AI Actions (HTTP Request): один endpoint, повний контроль

AI Action у Quickchat AI — це один HTTP API endpoint, який ви налаштовуєте окремо для свого AI Agent. Якщо MCP імпортує пакет інструментів одразу, кожна AI Action дає повний контроль над однією конкретною можливістю. Повний практичний приклад із чотирма діями, які створюють і збагачують контакти, логують угоди й відкривають тікети в CRM, див. у посібнику з HubSpot AI Actions.

Для власного REST API створюйте й оновлюйте звернення у власній CRM, зберігаючи повернений ID запису для наступних AI Actions у тій самій розмові.

Налаштування AI Action:

1. Name (макс. 64 символи): це стає назвою інструмента, яку бачить LLM. Назва нормалізується до валідного ідентифікатора (наприклад, “Check Order Status” стає Check_Order_Status)
2. Description (макс. 1 000 символів): це найважливіше поле. Опис повідомляє LLM, коли використовувати цей інструмент. Хороші описи вказують, за яких обставин у розмові його викликати, яку інформацію спершу зібрати від користувача і як повідомляти результати назад
3. HTTP method: GET, POST, PATCH, DELETE або PUT
4. URL (макс. 10 000 символів): може містити плейсхолдери {{parameter_name}} для динамічних значень
5. Headers: пари ключ-значення для автентифікації та типу вмісту
6. Body items / Body JSON: тіло запиту з підстановкою параметрів
7. Query parameters: значення рядка запиту URL
8. Parameters (макс. 10): кожен має name, description (макс. 500 символів), type (str, int, float, bool або custom), прапорець required і необов’язкове default value

Плейсхолдери {{parameter_name}} є ключовим механізмом. Коли LLM викликає інструмент, він надає значення для кожного параметра на основі контексту розмови. Потім Quickchat AI підставляє ці значення в URL, заголовки, тіло й шаблони рядка запиту перед виконанням HTTP-запиту. Також є чотири вбудовані змінні, які можна підставляти таким способом: scenario_id, conversation_id, conversation_channel і conversation_url.

AI Action, налаштована для перевірки статусу замовлення, з шаблоном URL із плейсхолдером параметра, заголовками та визначеннями параметрів.

Під капотом: Quickchat AI динамічно будує типізовану схему з ваших визначень параметрів для кожної AI Action. П’ять підтримуваних типів (str, int, float, bool, custom) відображаються на відповідні нативні типи, і ця схема використовується для перевірки вхідних даних LLM перед виконанням HTTP-запиту.

Приклад AI Action для перевірки статусу замовлення:

{
  "name": "check_order_status",
  "description": "Коли користувач запитує про статус свого замовлення і надав номер замовлення, викличте цей endpoint, щоб отримати поточний статус. Повідомте користувачу статус, орієнтовну дату доставки та номер відстеження (якщо доступний).",
  "method": "GET",
  "url": "https://api.example.com/orders/{{order_id}}",
  "headers": [
    { "name": "Authorization", "value": "Bearer YOUR_API_KEY" },
    { "name": "Content-Type", "value": "application/json" }
  ],
  "parameters": [
    {
      "name": "order_id",
      "description": "ID замовлення, наданий користувачем (наприклад, ORD-12345)",
      "type": "str",
      "is_required": true
    }
  ]
}

Тестування: у панелі керування є кнопка “Test”, яка дає змогу надати приклади значень параметрів і побачити фактичний HTTP-запит (включно зі згенерованою командою curl) і відповідь до розгортання.

Поради щодо написання ефективних описів AI Action:

• Чітко вкажіть, коли агент має її викликати: «Коли користувач запитує про статус свого замовлення і надає номер замовлення, викличте цей endpoint»
• Згадайте, яку інформацію спершу потрібно зібрати: «Перед викликом переконайтеся, що у вас є email-адреса користувача та ID замовлення»
• Опишіть, як обробляти відповідь: «Якщо статус „shipped“, повідомте користувачу номер відстеження з відповіді»
• Для багатокрокових робочих процесів описуйте послідовність в основному системному промпті агента, а не в описах окремих дій, і щоб передати значення між діями та зробити запис залежним від нього, використовуйте Save to memory плюс run-condition

Практичний приклад: покрокову AI Action, яка записує ліди, запитання без відповіді та запити на демо прямо в таблицю, див. у статті як підключити AI-агента до Google Sheets.

Generate from Text: дозвольте AI розібратися

Третій варіант призначений для користувачів, які знають, що має робити їхній агент, але не знають, який API endpoint (або навіть який сервіс) використовувати.

Як це працює:

1. Ви вводите опис природною мовою того, що хочете, наприклад: «Я хочу, щоб мій AI Agent міг запускати Tesla користувача, коли той попросить»
2. Quickchat AI надсилає це до LLM з увімкненим інструментом web_search
3. Модель шукає в інтернеті потрібний API, читає офіційну документацію і генерує повну специфікацію AI Action, включно з URL, методом, заголовками, параметрами й вимогами до автентифікації
4. Результат повертається з повною конфігурацією дії, цитуваннями використаної документації та пояснювальним повідомленням з припущеннями й прогалинами
5. Ви переглядаєте, заповнюєте свої облікові дані і активуєте

Введення опису бажаної можливості природною мовою.

Згенерована конфігурація AI Action із цитуваннями використаної API-документації.

Автоматизована генерація AI Action структурована навколо трьох пріоритетів:

• Пріоритет 1: зрозуміти намір. Визначити точну можливість, яку хоче розробник, і конкретний API endpoint, який її надає
• Пріоритет 2: спиратися на документацію. Використати вебпошук, щоб знайти офіційну документацію постачальника, а не припущення
• Пріоритет 3: проєктувати семантику, орієнтовану на розмову. Згенеровані name і description мають описувати, коли в розмові використовується цей інструмент, а не лише що API робить технічно

Промпт використовує дві конвенції плейсхолдерів. {{param}} позначає параметри часу виконання, які LLM заповнює з контексту розмови. [[secret_name]] (подвійні квадратні дужки) позначає константи розробника, як-от API-ключі та ID облікових записів, які потрібно налаштувати вручну перед активацією. Кожна назва параметра має з’явитися як плейсхолдер {{that_exact_name}} десь у визначенні запиту, і плейсхолдери без відповідного параметра не допускаються.

Система використовує політику fail-closed. Якщо модель не може підтвердити критично важливу інформацію з документації (HTTP-метод, URL, схему автентифікації або обов’язкову структуру payload), дія не створюється. Натомість система повертає стислий опис того, чого бракує, а не робить припущення.

Саме тут філософська теза про те, що AI-агенти знаходять API, пов’язується з конкретною продуктовою функцією. Функція Generate from Text буквально є AI-агентом (LLM із вебпошуком), який будує визначення інструмента для іншого AI-агента (агента Quickchat AI, який використовуватиме його в розмовах).

Практичний приклад: повний посібник, який перетворює два введені речення на дві робочі протестовані дії (пошук погоди без ключа та NASA з ключем, включно з відмовою за принципом fail-closed), див. у статті як підключити AI-агента до будь-якого API простими словами.

Під час виконання всі ці типи інструментів збираються разом. Quickchat AI збирає інструменти AI Action типу HTTP request, інструменти Shopify MCP, інструменти бази знань, інструменти remote MCP, інструменти Discord та інші власні інструменти у колекцію, яку буде подано LLM. Модель не бачить між ними різниці. Інструмент Remote MCP і вручну налаштована AI Action виглядають однаково, коли потрапляють до списку інструментів.

Відкриті API як нове SEO

Якщо AI-агенти автономно знаходитимуть і використовуватимуть API, тоді добре задокументований і простий у використанні API стає активом дистрибуції. Gartner прогнозує, що понад 30% зростання попиту на API до 2026 року припаде на AI-агентів.

Компанії з відкритими API та мінімальними бар’єрами доступу можуть виявити, що їхні API стали найкращим каналом залучення. Замість показів у пошуку Google «показами» стають AI-агенти, які обирають ваш сервіс замість сервісу конкурента.

Та сама логіка застосовується на рівень вище. AI-агент, який відповідає на основі вашої документації, сам може бути відкритий як MCP-сервер, який ChatGPT, Claude і Cursor викликають як інструмент, що робить ваші знання, а не лише ваш API, доступними для виявлення в агентному вебі.

Якість вашої API-документації визначає, чи зможе AI-агент успішно інтегруватися з вами з першої спроби. Описи параметрів, повідомлення про помилки та приклади відповідей виконують ту саму функцію, що й метаописи та структуровані дані в традиційному SEO. Незрозуміла відповідь із помилкою або незадокументоване обов’язкове поле означають, що агент зазнає невдачі, і на іншому боці не буде людини, яка це налагодить.

Компанії, чиї API не задокументовані або закриті важкими вимогами до облікових даних, можуть стати невидимими для агентного вебу, так само як компанії без вебсайтів стали невидимими для Google у 2000-х.

Computer Use проти API

Є значні інвестиції в навчання AI-моделей “computer use” (натискати кнопки, заповнювати форми, навігувати UI). Anthropic, OpenAI (Operator) і open-source проєкти на кшталт Browser Use пропонують свої версії цього.

Але використання браузера — це обхідний шлях для відсутнього API. Виклик POST /orders займає мілісекунди й повертає структуровані дані. Браузерний агент, який проходить процес оформлення замовлення, витрачає хвилини й може зламатися, коли кнопка зміщується на три пікселі вліво. API швидші, детермінованіші й дешевші у виконанні.

Контраргумент реальний: API існують не для всього. Застарілі системи, корпоративне програмне забезпечення без API, фізичні пристрої, керовані через GUI. Computer use справді заповнює прогалину в таких випадках.

Кращою довгостроковою відповіддю на «у нас немає API для цього», імовірно, буде створення API, а не навчання AI користуватися GUI. Оскільки дедалі більше програмного забезпечення пишеться AI-агентами для AI-агентів, вартість створення й підтримки API знижується. Економічний розрахунок, який робив скрейпінг інтерфейсу дешевшим за побудову API, змінюється.

Є також аспект безпеки. «Летальна тріада» Simon Willison описує небезпечне поєднання доступу до приватних даних + контакту з недовіреним контентом + зовнішньої комунікації. Це стосується обох підходів, але інструменти на основі API легше аудитувати й обмежувати. Ви можете логувати кожен API-виклик, перевіряти кожен параметр й обмежувати частоту запитів до кожного endpoint. Зробити еквівалент для браузерного агента, який може натиснути будь-що, значно складніше.

Інструменти для фізичного світу

Усе, що обговорювалося досі, стосується програмного забезпечення. Такий самий патерн з’являється у фізичному світі.

RT-2 від Google DeepMind і Gemini Robotics використовують ту саму архітектуру, але інструменти надсилають команди актуаторам замість API. Фреймворк SPCA (Sense-Plan-Code-Act) формалізує це для робототехніки: сканувати середовище, спланувати підхід, згенерувати виконуваний код, виконати його, спостерігати результати.

Немає API для «пересунь рослину на моєму столі праворуч». Але робот із камерою міг би на льоту визначити move_object(object_id="plant_01", direction="right", distance_cm=15) як інструмент, а потім викликати його. Визначення інструмента слугує інтерфейсом між шаром міркування і шаром фізичного виконання, так само як API endpoint у програмному забезпеченні.

Архітектура LLM + інструменти + цикл є загального призначення. Сьогодні її найпростіше реалізувати в програмному забезпеченні, але робототехніка наздоганяє.

API, написані AI для AI

Приблизно за два роки (з 2024 до 2026) ми перейшли від ситуації, де більшість коду писали люди, до ситуації, де більшість коду пише AI. Це добрий момент, щоб переосмислити, чим є API endpoint. Дедалі частіше endpoint — це декларація можливості, призначена для виявлення й виконання машинами, а не технічний інтерфейс, про який людські розробники читають документацію, а потім інтегрують вручну.

MCP є корисним шаром стандартизації, але також і шаром кураторства, який вносить упередження. Автор MCP вирішує, які інструменти відкрити і як їх подати. Для AI-агентів у продакшені таке подання може не відповідати вашим реальним потребам. (Ми докладно писали про це, аналізуючи виклики з MCP Shopify.)

Спектр, який ми розглянули в Quickchat AI Agents, відображає ширший принцип. Правильний рівень контролю залежить від вашого сценарію використання. Remote MCP добре працює для швидкого прототипування. Окремі AI Actions дають детальний контроль для агентів у продакшені, які працюють із клієнтами. Generate from Text дає AI змогу дослідити API й побудувати визначення інструмента для вас, коли ви ще досліджуєте варіанти.

І на кожному рівні базовий патерн той самий. LLM, набір інструментів, цикл. Незалежно від того, чи інструменти є bash-командами, API endpoint, MCP-серверами або актуаторами робота, усе зводиться до інструментів на кожному рівні.