AI-агенти на кшталт Claude, Codeex, Cursor чи Windsurf стають справді корисними лише тоді, коли вміють працювати з реальними робочими інструментами — від Gmail і Google Drive до Salesforce, HubSpot чи Slack. Канал Tech With Tim показує це на практиці, використовуючи сервіс Composio як єдиний MCP‑конектор, що під’єднує штучний інтелект до десятків і навіть сотень зовнішніх застосунків.
За цим стоїть не просто зручність, а цілком конкретна архітектурна перевага над нативними конекторами Claude. Йдеться про масштабованість, точність виклику інструментів, економію токенів і можливість переносити одну й ту саму конфігурацію між різними AI‑платформами.
Коли нативних конекторів стає забагато
Сучасні AI‑платформи вже мають офіційні інтеграції з популярними сервісами. У Claude це цілий список схвалених конекторів, які можна вмикати безпосередньо в налаштуваннях. Для одного‑двох інструментів такий підхід працює безболісно. Проблеми починаються, коли бізнес або окремий користувач хоче підключити десятки сервісів.
Перше обмеження — один обліковий запис на сервіс. Нативні конектори Claude сьогодні дозволяють прив’язати лише один акаунт Gmail, один Google Drive, один Salesforce тощо. Для багатьох користувачів це не відповідає реальності: окремі поштові скриньки для особистих листів, роботи, фрилансу; кілька робочих просторів у Google Drive; різні інстанси CRM для різних проєктів. Якщо таких акаунтів п’ять, доводиться обирати один, а решту просто ігнорувати.
Друге — так званий context bloat, або роздуття контексту. Щоразу, коли Claude отримує запит, у системний промпт моделі передається опис усіх доступних інструментів. Якщо користувач підключив десять конекторів, а кожен із них експонує по 50 окремих функцій, модель бачить уже 500 інструментів.
Це має два прямі наслідки. По‑перше, різко зростає кількість токенів, які витрачаються на кожен запит: модель щоразу «читає» довгий перелік можливих дій, навіть якщо в конкретному діалозі потрібен лише один інструмент. По‑друге, падає точність виклику інструментів. LLM, якій пропонують сотні чи тисячі можливих дій, гірше орієнтується, частіше обирає не той інструмент або взагалі уникає виклику, навіть коли він доречний. Це добре задокументована проблема для великих мовних моделей.
У підсумку користувач платить більше за кожен запит, отримуючи при цьому менш надійний і менш передбачуваний інструментальний шар. Саме на цьому тлі стає зрозуміло, чому архітектура «один MCP‑конектор до всього» виглядає привабливою.
Composio як єдиний MCP‑шлюз до тисячі застосунків
Composio пропонує іншу модель: замість того, щоб підключати до Claude десятки окремих конекторів, користувач додає лише один — MCP‑конектор Composio. Усе інше відбувається вже всередині самого сервісу.
Через цей єдиний конектор можна під’єднати приблизно тисячу різних застосунків. Серед них — Instagram, YouTube, Slack, Reddit, Monday, Figma, Salesforce, HubSpot, Gmail, Google Drive та багато інших. Користувач працює з ними через веб‑дашборд Composio: обирає потрібний сервіс, проходить OAuth‑авторизацію, а далі всі сесійні токени та оновлення доступу бере на себе Composio, а не Claude чи інша AI‑платформа.
Ключова відмінність — підтримка кількох акаунтів одного й того самого сервісу. У випадку з Gmail можна підключити одразу кілька поштових скриньок, дати кожній зрозумілу назву й тримати всі активними одночасно. Те саме стосується Google Drive чи інших сервісів, де в користувача може бути кілька робочих просторів. Замість того щоб обирати «єдиний головний» акаунт, AI‑агент отримує доступ до всієї реальної структури роботи користувача.
Це змінює саму логіку взаємодії з агентом. Замість запитів на кшталт «переглянь мій Gmail» можна формулювати завдання точніше: «перевір останні листи в робочій скриньці» або «знайди контракт у Google Drive для клієнта X у папці з юридичними документами». За рахунок іменованих підключень і мультиакаунтності агент має змогу працювати з кількома джерелами одночасно, не втрачаючи контексту.
Як Composio бореться з context bloat і підвищує точність інструментів
Найцікавіша частина архітектури Composio — це on‑demand tool discovery, або пошук інструментів на вимогу. Замість того щоб «засипати» Claude сотнями описів інструментів, Composio експонує до моделі лише невеликий набір метаінструментів.
У конфігурації Claude це виглядає як кілька функцій: пошук інструментів, отримання схем інструментів, multi‑execute для виконання кількох дій, інструменти для віддаленого bash чи workbench, wafer‑підключення, керування конекціями. Цього достатньо, щоб модель могла дізнатися, які конкретні можливості їй потрібні в кожній окремій ситуації.
Механіка роботи така. Користувач формулює запит, наприклад: «Надішли команді підсумковий лист про сьогоднішній стендап». Claude бачить лише один релевантний метаінструмент — пошук інструментів — і викликає його. Composio отримує цей виклик, виконує семантичний пошук по всіх доступних інструментах і повертає невеликий, цільовий список варіантів: скажімо, інструмент для отримання листів із Gmail, інструмент для надсилання листів, можливо, інтеграцію зі Slack, якщо команда працює там.
Claude вже працює не з сотнями можливостей, а з кількома релевантними. Модель обирає потрібний інструмент — наприклад, «Gmail send email» — викликає його через Composio, отримує результат і формує відповідь користувачеві. Якщо потрібно, може бути задіяний multi‑execute: спочатку отримати дані, потім створити чернетку листа, потім надіслати його.
Такий підхід різко скорочує обсяг контексту, який модель має тримати в пам’яті. Замість довгого списку інструментів у системному промпті Claude бачить лише кілька метаінструментів Composio. Решта інформації з’являється лише тоді, коли вона справді потрібна. Це зменшує витрати токенів і водночас підвищує точність: модель рідше «плутається» в інструментах, оскільки працює з невеликими, релевантними підмножинами.
Ще один важливий елемент — обрізання результатів виклику інструментів. Відповіді від зовнішніх сервісів можуть бути великими: довгі списки листів, детальні об’єкти з CRM, великі документи. Якщо передавати їх у Claude повністю, контекст знову роздувається. Composio автоматично тримає це під контролем, обрізаючи або агрегуючи результати так, щоб вони залишалися корисними для моделі, але не перевантажували промпт. Це знову ж таки економить токени й допомагає моделі краще фокусуватися на суті завдання.
Єдина конфігурація для Claude, Codeex, Gemini та інших
Ще одна системна перевага Composio — відокремлення рівня інтеграцій від конкретної AI‑платформи. Усі підключення, OAuth‑сесії, кілька акаунтів одного сервісу, назви конекцій — усе це належить Composio, а не Claude чи будь‑якому іншому агенту.
На практиці це означає, що після того, як користувач один раз налаштував усі потрібні інструменти в дашборді Composio, цю ж конфігурацію можна використовувати в різних середовищах. Claude, Codeex, Gemini, інші агенти — усі вони можуть підключатися до того самого MCP‑конектора Composio й отримувати доступ до однакового набору інструментів.
Це особливо важливо для команд, які експериментують із різними моделями або використовують кілька агентів для різних задач. Замість того щоб повторювати одну й ту саму роботу — підключати Gmail, Google Drive, Slack, CRM у кожній платформі окремо — достатньо один раз пройти OAuth‑флоу в Composio. Далі кожна нова платформа просто «вказує» на вже готову конфігурацію.
Крім того, саме Composio бере на себе керування аутентифікацією: зберігає сесійні токени, автоматично оновлює їх, зменшуючи ризик того, що в якийсь момент інтеграція «відвалиться» і агент раптово втратить доступ до сервісу. Це контрастує з нативними конекторами, де користувачеві нерідко доводиться періодично перепідключати акаунти, коли токени протерміновуються.
Досвід користувача: від дашборда до прав доступу
З погляду користувача, Composio починається з веб‑дашборда. Після реєстрації можна переглянути каталог доступних інструментів, перевірити, чи підтримується потрібний сервіс, і підключити його через знайомий OAuth‑процес: вибір акаунта, підтвердження прав, повернення в дашборд.
У цьому ж інтерфейсі можна керувати підключеннями: додавати нові акаунти до вже підключеного сервісу, перейменовувати їх, щоб легше орієнтуватися, або відключати ті, що більше не потрібні. Наприклад, для Gmail можна бачити список усіх доступних інструментів, пов’язаних із поштою, і паралельно тримати активними кілька скриньок.
Інтеграція з Claude Co‑Work відбувається через додавання кастомного конектора. У налаштуваннях Claude користувач створює новий конектор, вставляє URL, який надає Composio, і підтверджує підключення в браузері. Після авторизації Claude бачить лише невеликий набір метаінструментів Composio, а не повний список усіх підключених сервісів.
У налаштуваннях можна тонко керувати правами доступу. Наприклад, дозволити Claude завжди виконувати лише читальні дії, тоді як операції запису або видалення вимагатимуть явного підтвердження користувача. Це дозволяє поєднати зручність автоматизації з базовими вимогами безпеки: агент може вільно шукати потрібні інструменти й читати дані, але не зможе, скажімо, видалити файли чи надіслати лист без згоди людини.
У такій конфігурації стають можливими сценарії, які раніше вимагали ручної роботи. Наприклад, агент може отримати останні три листи з Gmail, підсумувати їх і повернути користувачеві короткий огляд важливих моментів. Або, використовуючи ланцюжок інструментів, спочатку обробити вхідні листи, потім створити документ у Google Docs із підсумком, зберегти його в Google Drive і повернути посилання. Усе це відбувається через один MCP‑конектор, без необхідності окремо налаштовувати кожен сервіс у Claude.
Висновок: інфраструктура, а не просто «ще один конектор»
На перший погляд Composio може здаватися просто зручним способом підключити багато сервісів до Claude чи іншого AI‑агента. Але за цим стоїть глибша зміна архітектури: замість десятків нативних конекторів, кожен із власними обмеженнями й токен‑витратами, користувач отримує єдиний інфраструктурний шар, який:
по‑перше, підтримує близько тисячі застосунків і дозволяє підключати кілька акаунтів одного сервісу одночасно;
по‑друге, зменшує context bloat завдяки on‑demand tool discovery й обрізанню результатів, що економить токени й підвищує точність виклику інструментів;
по‑третє, відокремлює конфігурацію інструментів від конкретної AI‑платформи, дозволяючи використовувати один і той самий набір підключень у Claude, Codeex, Gemini та інших середовищах без повторної настройки.
У світі, де AI‑агенти дедалі більше нагадують універсальних цифрових співробітників, саме така інфраструктура визначатиме, наскільки вони будуть справді корисними в реальних робочих процесах, а не залишаться розумними, але ізольованими чатботами.