У промові на каналі AI Engineer інженер Anthropic Девід Сорія Парра окреслює наступний крок еволюції протоколу Model Context Protocol (MCP). Якщо раніше MCP сприймали переважно як спосіб підключати інструменти й API до агентів, тепер мова йде про повноцінні додатки з власним інтерфейсом, які «приходять» разом із сервером MCP і однаково працюють у хмарі, ChatGPT, VS Code чи Cursor. Це не плагіни, не SDK‑віджети й не UI, який модель імпровізує на клієнті, а застосунки, що реально сервляться з MCP‑сервера.
Ця зміна ставить MCP у зовсім іншу площину: від «протоколу для тулів» до універсального способу доставляти агентні застосунки з багатим інтерфейсом на будь‑який клієнт, який розуміє спільну семантику.
Від інструментів до повноцінних застосунків
Ключова ідея MCP‑додатків полягає в тому, що сервер MCP більше не обмежується набором інструментів для моделі. Він може постачати повноцінний застосунок із власним UI, логікою й довготривалими задачами, який клієнт відображає не як «довільний текст від моделі», а як структурований інтерфейс.
Це принципово відрізняється від кількох звичних підходів до інтеграції:
По‑перше, MCP‑додатки — це не плагіни у традиційному сенсі. Немає окремої плагінної системи кожного клієнта, де розробник має писати специфічний код під кожну платформу. Замість цього є один сервер MCP, який описує і функціональність, і інтерфейс, а клієнти, що підтримують протокол, можуть його підхопити.
По‑друге, це не SDK‑віджети. Розробнику не потрібно вбудовувати у свій застосунок спеціальні UI‑компоненти з конкретного SDK. Весь UI постачається з MCP‑сервера як частина протоколу, а клієнт знає, як його інтерпретувати та відрендерити.
По‑третє, це не інтерфейс, який модель «вигадує на льоту» у відповідях. У багатьох сучасних системах UI по суті є побічним продуктом генерації: модель описує, що показати, а клієнт намагається це інтерпретувати. У випадку MCP‑додатків інтерфейс є частиною формального протоколу, а не вільного тексту, тож клієнт і сервер мають спільне, чітке уявлення про структуру UI.
У результаті MCP‑сервер стає носієм одразу двох шарів: людського інтерфейсу, з яким працює користувач, і набору інструментів, з якими працює модель. Людина взаємодіє із застосунком через UI, агент — через інструменти того ж сервера. Обидві взаємодії відбуваються над однією й тією ж логікою, але різними «фасадами». Це створює незвичну, але потужну конфігурацію: агент і людина працюють із тим самим застосунком, але кожен у своєму режимі.
Один сервер — багато клієнтів: справжня мультиплатформеність
Одна з найбільш практичних властивостей MCP‑додатків — можливість запускати один і той самий застосунок у різних клієнтах без змін у коді. Сервер MCP, який постачає UI й інструменти, можна підключити до хмарного середовища, до ChatGPT, до VS Code, до Cursor — і він «просто працює».
Це означає, що розробник:
не пише окремий плагін для кожного редактора коду чи чат‑клієнта;
не підтримує різні UI‑фреймворки під кожну платформу;
не дублює логіку інтеграцій у кількох SDK.
Уся бізнес‑логіка, інтерфейс і набір інструментів живуть на MCP‑сервері. Клієнт лише реалізує підтримку протоколу й уміє відобразити описаний у ньому UI. Фактично MCP виступає як «універсальний транспорт» для агентних застосунків, а клієнти — як багаторазові «термінали» до цих застосунків.
Це особливо важливо на тлі того, як швидко розростається MCP‑екосистема. За останні 12–18 місяців вона пройшла шлях від невеликої локальної специфікації з кількома SDK до великої мережі серверів та інтеграцій. Anthropic за цей час розширила MCP з локального протоколу до системи з віддаленими можливостями, централізованою авторизацією, новими примітивами на кшталт elicitation і tasks та експериментальними MCP‑додатками.
Сьогодні MCP‑пов’язані пакети сумарно мають близько 110 мільйонів завантажень на місяць. Ця цифра включає використання в SDK агентів OpenAI, SDK Google, LangChain та багатьох інших фреймворках і інструментах, які підтягують MCP як залежність. Для порівняння, одна з найуспішніших фронтенд‑бібліотек — React — виходила на подібний рівень завантажень приблизно вдвічі довше.
За цими цифрами стоїть не лише публічна екосистема. Значна частина MCP‑серверів працює в приватних середовищах, де компанії з’єднують внутрішні системи з агентами й AI‑застосунками. Саме в таких сценаріях мультиклієнтність MCP‑додатків стає особливо цінною: один і той самий внутрішній застосунок можна підключити до різних робочих середовищ співробітників без дублювання інтеграцій.
Чому потрібен семантичний шар, а не просто «ще один протокол»
Можливість доставляти повноцінні застосунки через MCP вимагає значно більшого, ніж просто «викликати інструмент» або «пробросити HTTP‑запит». Ключова вимога — багаті спільні семантики між клієнтом і сервером.
Семантика в цьому контексті означає, що обидві сторони не лише обмінюються байтами, а й розуміють структуру та значення переданих об’єктів. Коли сервер надсилає опис UI, клієнт має знати, що це саме UI, як його рендерити, які елементи є інтерактивними, як пов’язати їх із діями та інструментами. Коли сервер описує довготривалу задачу, клієнт має розуміти її життєвий цикл, стани, можливі дії користувача.
Багато існуючих підходів в екосистемі агентів цього не дають. Вони дозволяють:
оголошувати інструменти з простими сигнатурами;
викликати REST‑ендпоінти;
описувати схеми параметрів.
Але вони не надають спільної, формалізованої моделі для UI, ресурсів, задач і взаємодії людини та агента над однією й тією ж системою. У результаті кожен клієнт змушений вигадувати власні способи інтерпретації відповідей моделі, а розробники — підлаштовуватися під конкретні платформи.
MCP намагається закрити саме цю прогалину. Протокол не обмежується «викликом інструменту», а вводить примітиви для:
ресурсів, з якими працює агент;
задач, які можуть бути довготривалими й мати стани;
elicitation — керованого збору додаткової інформації;
авторизації та політик управління;
і, в експериментальному режимі, MCP‑додатків як структурованих UI.
Щоб MCP‑додаток міг однаково працювати в хмарному клієнті, у ChatGPT, у VS Code чи Cursor, усі ці клієнти мають розуміти одні й ті ж семантичні конструкції. Саме це робить можливим сценарій, коли один сервер MCP «постачає» застосунок, а різні клієнти лише відображають його відповідно до своїх можливостей, не змінюючи сам застосунок.
Це також пояснює, чому багато нинішніх рішень не можуть легко підтримати подібний стиль портативних UI. Вони не мають спільного семантичного шару, на який могли б спертися різні клієнти. Без нього UI залишається або жорстко зашитим у конкретний продукт, або імпровізованим текстом від моделі, який важко відтворити й перенести.
MCP як «UI‑транспорт» у стосунку до інших способів підключення
У баченні Anthropic 2026 рік має стати роком, коли агенти масово підуть у продакшн. Якщо 2024‑й був роком демонстрацій, а 2025‑й — роком «кодингових» агентів, то далі очікується перехід до загальних агентів для знаннєвої роботи: фінансового аналізу, маркетингу, роботи з кількома SaaS‑сервісами й спільними сховищами.
У такому світі підключення стає головною проблемою. Але, як підкреслює Сорія Парра, не існує єдиного способу підключення, який підходив би для всього. Замість цього формується стек із трьох основних компонентів: skills, MCP і CLI/computer use. Кожен із них має свою нішу.
Skills — це доменне знання, упаковане в прості, переважно багаторазові файли. Вони добре підходять для передачі специфічних знань моделі без складної інфраструктури.
CLI‑підключення ідеальне для локальних кодингових агентів. Там, де є пісочниця й середовище виконання коду, де можна викликати компілятор, а багато інструментів на кшталт git уже присутні в пре‑тренінгу моделі, командний рядок стає природним інтерфейсом.
MCP, своєю чергою, виявляється потрібним тоді, коли виникає потреба в багатих семантиках, UI, довготривалих задачах, роботі з ресурсами, платформній незалежності чи корпоративному управлінні. Саме в цих сценаріях MCP‑додатки розкриваються повною мірою: вони дозволяють не просто «підключити інструмент», а доставити повноцінний застосунок, який однаково працює в різних клієнтах.
У корпоративному контексті це означає, що:
інтерфейси для знаннєвих працівників не прив’язані до одного робочого середовища;
агенти можуть працювати з тими ж системами, що й люди, через один і той самий MCP‑сервер;
політики авторизації та управління застосовуються централізовано, незалежно від клієнта.
MCP у цьому сенсі стає «UI‑транспортом» для агентних застосунків: він переносить не лише функції, а й інтерфейси, і робить це поверх спільного семантичного шару.
Людина й агент в одному застосунку: подвійний інтерфейс MCP‑додатків
Одна з найцікавіших властивостей MCP‑додатків — їхня здатність одночасно обслуговувати людину й агента. MCP‑сервер може:
постачати UI, з яким працює користувач;
експортувати інструменти, з якими працює модель.
Це створює подвійний інтерфейс до однієї й тієї ж логіки. Людина бачить форми, таблиці, панелі, кнопки. Агент бачить функції з параметрами, ресурси, задачі. Обидва працюють над одними й тими ж даними й процесами.
У традиційних системах інтеграцій ці два шари часто розведені. Є «людський» веб‑інтерфейс і окремий API для машин. Вони можуть відрізнятися за можливостями, мати різні моделі даних, різні обмеження. MCP‑додатки натомість намагаються об’єднати ці два світи в одному протоколі.
Це відкриває кілька практичних сценаріїв.
По‑перше, агент може виконувати рутинні дії в тому ж застосунку, де працює людина, а користувач бачить прогрес і результати в знайомому інтерфейсі. Немає потреби «пересаджувати» користувача в окремий AI‑клієнт.
По‑друге, людина може втручатися в роботу агента, коригувати параметри, переглядати проміжні стани задач, не виходячи з MCP‑додатку. Це важливо для довіри й контролю, особливо в корпоративних сценаріях.
По‑третє, розробник проектує один застосунок, який одразу враховує обидва типи користувачів — людського й агентного. Це змінює підхід до дизайну: замість «API плюс окремий UI» з’являється «MCP‑додаток як спільний простір взаємодії».
Щоб це працювало, MCP має забезпечити не лише передачу UI, а й чітке описання того, як дії користувача й виклики інструментів пов’язані між собою, які ресурси вони змінюють, як відстежуються стани задач. Саме тут семантичний шар протоколу стає критичним.
Висновок: MCP‑додатки як наступний рівень агентних платформ
За півтора року MCP пройшов шлях від локального протоколу з «трохи більше, ніж інструментами» до інфраструктури з віддаленими можливостями, централізованою авторизацією, примітивами для задач і elicitation та експериментальними MCP‑додатками. На цьому тлі ідея «агента, який постачає власний інтерфейс» виглядає логічним наступним кроком.
MCP‑додатки пропонують кілька важливих властивостей:
вони дозволяють серверам MCP постачати повноцінні застосунки з UI, а не лише інструменти;
вони не є плагінами, SDK‑віджетами чи імпровізованим UI від моделі, а сервляться безпосередньо з MCP‑сервера;
один і той самий MCP‑додаток може працювати в різних клієнтах — хмарі, ChatGPT, VS Code, Cursor — без змін у коді;
вони вимагають багатого спільного семантичного шару між клієнтом і сервером, який більшість нинішніх рішень не надає;
вони поєднують людський інтерфейс і агентні інструменти в одному застосунку, створюючи спільний простір роботи людини й агента.
У міру того як агенти виходять за межі локальних кодингових сценаріїв і переходять до знаннєвої роботи з багатьма SaaS‑сервісами й корпоративними системами, саме така модель — «застосунок поверх протоколу з багатою семантикою» — може стати базовою. MCP у цьому баченні не просто ще один спосіб викликати інструменти, а транспортний і семантичний шар для портативних агентних UI, які працюють однаково в різних клієнтах.
Якщо ця траєкторія збережеться, то в найближчі роки поняття «MCP‑додаток» може стати таким же звичним для агентних систем, як «веб‑додаток» для браузера.