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

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

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

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

Цикл

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

Claude Code, наприклад, використовує single-threaded master loop без multi-agent swarm або складного графа оркестрації: while(tool_call) -> execute -> feed results -> repeat.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

AI Action у Quickchat AI це один HTTP API endpoint, який ви налаштовуєте окремо для свого AI Agent. Якщо MCP імпортує пакет інструментів одразу, кожна AI Action дає повний контроль над однією конкретною можливістю. Повний розглянутий приклад із чотирма діями, які створюють і збагачують контакти, логують угоди й відкривають tickets у CRM, див. у tutorial HubSpot 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 символів): може містити placeholders {{parameter_name}} для динамічних значень
5. Headers: пари key-value для автентифікації та content type
6. Body items / Body JSON: тіло запиту з підстановкою параметрів
7. Query parameters: значення query string URL
8. Parameters (макс. 10): кожен має name, description (макс. 500 символів), type (str, int, float, bool або custom), прапорець required і необов’язкове default value

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

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

Під капотом: Quickchat AI динамічно будує типізовану схему з ваших визначень параметрів для кожної AI Action. П’ять підтримуваних типів (str, int, float, bool, custom) відображаються на їхні native equivalents, і ця схема використовується для перевірки вхідних даних 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
    }
  ]
}

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

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

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

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

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

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

Як це працює:

1. Ви вводите опис природною мовою того, що хочете, наприклад: “Я хочу, щоб мій AI Agent міг запускати Tesla користувача, коли той попросить”
2. Quickchat AI надсилає це до LLM з увімкненим інструментом web_search
3. Модель досліджує web, щоб знайти правильний API, читає офіційну документацію і генерує повну специфікацію AI Action, включно з URL, method, headers, parameters і authentication requirements
4. Результат повертається з повною конфігурацією дії, цитуваннями використаної документації та пояснювальним повідомленням з припущеннями й прогалинами
5. Ви переглядаєте, заповнюєте свої credentials і активуєте

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

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

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

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

Prompt використовує дві конвенції placeholders. {{param}} позначає runtime parameters, які LLM заповнює з контексту розмови. [[secret_name]] (подвійні квадратні дужки) позначає developer constants, як-от API keys і account IDs, які потрібно налаштувати вручну перед активацією. Кожна назва параметра має з’явитися як placeholder {{that_exact_name}} десь у визначенні запиту, і orphan placeholders не допускаються.

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

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

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

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

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

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

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

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

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

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

Computer Use проти API

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

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

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

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

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

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

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

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 у software.

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

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

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

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

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

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