Локальні великі мовні моделі вже давно перестали бути екзотикою для ентузіастів. Завдяки таким інструментам, як Ollama, будь‑хто з достатньо потужним комп’ютером може запустити сучасну LLM у себе на машині, без хмарних API, підписок і передачі даних третім сторонам. Канал Tech With Tim показує, як зробити ще один крок далі — перетворити локальну модель не просто на «розумний чатбот», а на агента, здатного діяти у зовнішніх сервісах через Zapier MCP.
Цей підхід дозволяє локальній моделі працювати з Notion, Google Calendar, Facebook Ads та тисячами інших інтеграцій, залишаючи обчислення й дані під контролем користувача. Нижче — детальний розбір того, що саме відрізняє агента від звичайної LLM, як у цій схемі працює Zapier MCP, і чому OAuth‑автентифікація та модель з підтримкою tool calling є критичними елементами.
Від «розумного чатбота» до агента: ключова різниця
Базова LLM, запущена локально чи в хмарі, за своєю суттю є генератором тексту. Вона приймає текстовий запит і повертає текстову відповідь, іноді — з додатковими можливостями на кшталт генерації коду, зображень чи відео. Але все це залишається в межах одного середовища: модель не має власного доступу до вашого календаря, баз знань, CRM чи рекламних кабінетів.
Агент — це інша концепція. Він також використовує LLM як «мозок», але доповнює її шаром інструментів, які можна викликати. Саме через ці інструменти агент отримує можливість виконувати дії у зовнішніх системах. Модель не просто відповідає, що «варто створити подію в календарі», а реально викликає відповідний інструмент, передає параметри й створює подію.
У цьому підході LLM залишається ядром, яке:
формулює план дій на основі запиту користувача;
вирішує, який інструмент потрібно викликати;
генерує аргументи для виклику;
інтерпретує результат і повертає людині осмислену відповідь.
Але без підключення до зовнішніх сервісів навіть найпотужніша модель залишається ізольованою. Вона може порадити, як структурувати базу в Notion, але не зможе створити її за вас. Може запропонувати розклад зустрічей, але не внесе їх у Google Calendar. Саме тому шар інструментів — те, що перетворює «великий калькулятор тексту» на агента, який працює з реальними даними й сервісами.
Zapier MCP: універсальний «шлюз» до 8 000+ інтеграцій
Щоб не писати окремі інтеграції для кожного сервісу, у цій схемі використовується Zapier MCP server. Zapier давно відомий як платформа автоматизації, що з’єднує різні веб‑сервіси через «запи». MCP (Model Context Protocol) у цьому випадку виступає як стандартний спосіб, яким LLM може викликати інструменти, а Zapier MCP — як сервер, що надає ці інструменти моделі.
Ключова ідея полягає в тому, що замість десятків окремих конекторів до Google, Notion, Facebook Ads та інших сервісів, локальна модель працює лише з одним MCP‑сервером. А вже цей сервер, у свою чергу, має доступ до понад 8 000 інтеграцій, які підтримує Zapier. Для користувача це означає:
єдину точку підключення між моделлю та зовнішнім світом;
уніфікований спосіб виклику інструментів незалежно від того, чи це Google Calendar, Notion чи рекламний кабінет;
можливість масштабувати можливості агента, просто додаючи нові інтеграції в Zapier, без зміни самої моделі.
Zapier MCP доступний безкоштовно на старті: достатньо створити акаунт і налаштувати сервер. Важливий нюанс — кожен виклик MCP‑інструменту споживає ті самі task‑кредити, що й звичайні «запи» в Zapier. Тобто з точки зору тарифів це не окремий продукт, а ще один спосіб запускати автоматизації, тільки тепер ініціатором виступає не людина чи вебхук, а локальний AI‑агент.
Фактично Zapier MCP стає універсальним «адаптером», який дозволяє локальній LLM поводитися так, ніби вона інтегрована з усім вашим цифровим середовищем, хоча насправді вона спілкується лише з одним сервером, що вже вміє працювати з тисячами сервісів.
Вибір моделі: чому підтримка tool calling важливіша за «розумність»
Щоб локальна LLM могла працювати як агент через Zapier MCP, недостатньо просто запустити будь‑яку модель в Ollama. Потрібна модель, яка вміє викликати інструменти — так званий tool calling. Це не маркетинговий ярлик, а конкретна технічна можливість: модель повинна вміти повертати структуровані виклики функцій, які клієнтська програма інтерпретує як інструкцію «запусти ось цей інструмент з такими параметрами».
У бібліотеці Ollama не всі моделі це підтримують. Наприклад, деякі варіанти Llama 3 не мають позначки про підтримку tools. Такі моделі можуть працювати як чатботи, але не здатні коректно формувати виклики інструментів, а отже — не підходять для сценарію з агентами та Zapier MCP.
У демонстрації використовується модель Qwen 3.5, яка прямо позначена як така, що підтримує tools. Це критично: без цієї можливості навіть ідеально налаштований MCP‑сервер ідеально налаштованим не стане — модель просто не буде ініціювати виклики інструментів.
Далі постає питання розміру моделі. Qwen 3.5 у бібліотеці Ollama доступна в кількох варіантах — від сотень мільйонів до десятків мільярдів параметрів. Кількість параметрів безпосередньо впливає на:
обсяг дискового простору, який займає модель;
обсяг оперативної пам’яті (або VRAM), необхідний для її роботи;
швидкість відповіді;
якість результатів.
У демонстрації спочатку завантажується Qwen 3.5 35B — приблизно 23 ГБ. На машині з 32 ГБ уніфікованої пам’яті (M2 Max MacBook) така модель працює, але повільно: значна частина RAM зайнята лише під модель, а система й інші процеси також потребують ресурси. Qwen 3.5 122B, яка потребує близько 81 ГБ RAM, на такій конфігурації практично непридатна — її можна завантажити, але робота буде надто повільною.
У підсумку автор переходить на Qwen 3.5 27B як більш реалістичний компроміс для 32‑гігабайтної машини. При цьому наголошується, що для більшості користувачів практичним мінімумом є модель приблизно на 9 мільярдів параметрів: вона не досягає рівня топових хмарних моделей, але вже здатна виконувати корисні завдання й працювати з інструментами.
Важливий технічний контекст:
на нових Mac з Apple Silicon модель використовує уніфіковану пам’ять, тобто спільний пул RAM для CPU та GPU. Якщо у вас 32 ГБ, модель може займати 70–80% цього обсягу, але не більше;
на Windows і більшості Linux‑систем LLM зазвичай працюють на GPU і обмежені обсягом VRAM. Наприклад, відеокарта RTX 4090 має 24 ГБ VRAM, і модель може використовувати майже весь цей обсяг;
моделі можна запускати й на CPU‑only машинах, але швидкість буде настільки низькою, що практична користь від агента, який чекає хвилинами на кожну відповідь, стає сумнівною.
Усі ці обмеження важливі, тому що агент, який має викликати інструменти, повинен працювати достатньо швидко, щоб інтерактивна взаємодія з Notion чи Google Calendar не перетворювалася на очікування.
Як Zapier MCP перетворює локальну модель на агента для Notion
Однією з показових інтеграцій у цій схемі є Notion. Це типовий приклад сервісу, де зберігаються робочі бази знань, документи, таск‑менеджмент і проєктні структури. Підключення Notion через Zapier MCP дозволяє агенту не просто «радити, як краще організувати базу», а реально працювати з вашим робочим простором.
Сценарій виглядає так. Користувач підключає свій акаунт Notion до Zapier через стандартний OAuth‑процес. Це означає, що:
автентифікація відбувається на звичному екрані згоди Notion;
користувач явно підтверджує, до яких частин робочого простору надається доступ;
Zapier отримує токен доступу, але локальна модель не зберігає логін чи пароль.
Після цього в Zapier MCP з’являються інструменти, які відповідають діям у Notion: читання сторінок, створення записів у базах, оновлення властивостей тощо. Коли агенту потрібно, наприклад, знайти сторінку з технічним завданням або створити нову нотатку за підсумками розмови, модель формує виклик відповідного інструменту, передаючи параметри у структурованому вигляді.
MCP‑сервер отримує цей виклик, запускає відповідний «зап» у Zapier, який уже безпосередньо спілкується з API Notion, і повертає результат назад агенту. Для користувача це виглядає як діалог: ви просите агента «знайди в Notion останній план релізу й додай туди новий пункт», а через кілька секунд отримуєте підтвердження, що сторінку знайдено й оновлено.
Важливий момент — саме Zapier MCP виступає посередником між локальною моделлю та Notion. Модель не має прямого доступу до API Notion і не зберігає облікові дані. Уся автентифікація й авторизація відбувається на боці Zapier через стандартний OAuth, що знижує ризики безпеки й робить процес знайомим для користувачів, які вже працювали з інтеграціями в інших контекстах.
Інтеграція з Google Calendar: агент, який реально керує часом
Другий показовий приклад — Google Calendar. Це сервіс, де «дії» особливо відчутні: створення, зміна чи видалення подій безпосередньо впливають на розклад користувача. Підключення Google Calendar через Zapier MCP дозволяє агенту не просто пропонувати, коли краще провести зустріч, а реально створювати або змінювати події в календарі.
Як і у випадку з Notion, підключення відбувається через стандартний OAuth‑флоу Google. Користувач бачить звичний екран згоди Google, де вказано, що саме Zapier просить доступ до календаря. Після підтвердження Zapier отримує токен, а MCP‑сервер — можливість надавати моделі інструменти для роботи з календарем.
Далі агент може:
читати події в календарі за певний період;
створювати нові події з вказаними датою, часом, описом і учасниками;
оновлювати існуючі події, наприклад переносити зустрічі;
теоретично — виконувати інші дії, які підтримує інтеграція Zapier з Google Calendar.
З точки зору користувача це відкриває сценарії на кшталт: «заплануй зустріч із командою на наступний вівторок після обіду, знайди вільний слот і додай посилання на нотатку в Notion». Агент, маючи доступ і до Notion, і до Google Calendar через Zapier MCP, може:
знайти потрібну сторінку в Notion;
створити або оновити подію в Google Calendar, додавши посилання на сторінку;
повернути вам підтвердження з деталями події.
Знову ж таки, локальна модель не працює безпосередньо з API Google. Вона лише формує виклики інструментів, а вся взаємодія з Google Calendar відбувається через Zapier, який уже давно інтегрований з екосистемою Google і використовує стандартні механізми безпеки.
Безпека й контроль: OAuth як основа довіри до агента
Одне з головних питань, яке виникає при підключенні локального агента до реальних сервісів, — безпека. Користувачі справедливо не хочуть передавати свої логіни й паролі в якісь проміжні програми чи скрипти, особливо якщо йдеться про робочі дані, календарі, документи й рекламні акаунти.
У цій архітектурі критичну роль відіграє те, що Zapier MCP використовує стандартні OAuth‑флоу для підключення акаунтів Notion, Google Calendar та інших сервісів. Це означає, що:
автентифікація відбувається безпосередньо на стороні сервісу (Notion, Google тощо);
користувач бачить офіційний екран згоди, де чітко вказано, до чого саме надається доступ;
локальна модель і MCP‑клієнт не отримують і не зберігають паролі;
доступ можна відкликати в будь‑який момент через налаштування безпеки самого сервісу або в Zapier.
Таким чином, локальний агент, який працює через Zapier MCP, поєднує дві, на перший погляд, суперечливі вимоги: приватність обчислень (модель працює на вашій машині, без відправки промптів у хмару) і можливість діяти в зовнішніх сервісах, де дані зберігаються в хмарі, але доступ до них контролюється звичними механізмами OAuth.
Це не знімає всіх ризиків — як і будь‑яка автоматизація, агент може зробити небажану дію, якщо його неправильно сконфігурувати або сформулювати запит. Але з точки зору зберігання облікових даних і контролю доступу архітектура спирається на перевірені механізми, які вже давно використовуються в інтеграціях між сервісами.
Висновок: локальні агенти виходять за межі «іграшки для ентузіастів»
Комбінація локальної LLM в Ollama, моделі з підтримкою tool calling і Zapier MCP як універсального «шлюзу» до тисяч інтеграцій показує, що агенти більше не є виключно хмарною привілеєю великих платформ. На достатньо потужному комп’ютері можна побудувати систему, яка:
працює локально, зберігаючи приватність промптів і відповідей;
має доступ до Notion, Google Calendar, Facebook Ads та інших сервісів через Zapier;
використовує стандартні OAuth‑механізми для підключення акаунтів;
поводиться як повноцінний агент, здатний не лише відповідати текстом, а й виконувати дії у зовнішніх системах.
Ключовими елементами тут є правильний вибір моделі (з підтримкою tools і відповідним розміром під вашу апаратну конфігурацію) та розуміння ролі Zapier MCP як посередника, який перетворює текстові наміри моделі на конкретні API‑виклики.
У підсумку локальна LLM перестає бути ізольованим «чатботом» і стає центром персональної або робочої автоматизації, де ви контролюєте як обчислення, так і доступ до даних, а інтеграції з тисячами сервісів налаштовуються через знайомий інтерфейс Zapier.
Джерело
YouTube: How to Run LLMs Locally + Connect to Everything – Full Tutorial (Ollama)