Раніше для підключення N інструментів до M моделей було потрібно N×M шарів адаптації. MCP розділяє сторону інструментів і сторону моделей, тож кожній достатньо реалізувати протокол один раз. У статті пояснюються це архітектурне рішення, абстракції браузерних середовищ і дій на сторінці та питання, які досі не вирішені.
Коли Agent має справді виконувати роботу, він зазвичай зрештою переходить до браузера: входить в обліковий запис, публікує, збирає дані або заповнює форми. Технічна складність полягає не в тому, чи може він натиснути кнопку, а у вартості інтеграції під час передавання браузера Agent.
Пастка адаптацій N×M
Припустімо, що на ринку є N інструментів і M моделей. Постачальник інструмента має написати окрему інтеграцію для кожної моделі, а сторона моделі — окремий адаптаційний шар для кожного інструмента. Обидві сторони самостійно підтримують свої реалізації, тож загалом виходить N×M варіантів.
Проблема полягає в множенні. Додавання одного інструмента означає не одну додаткову роботу, а необхідність підключити його до кожної моделі. І навпаки, після зміни версії моделі вже підключені інструменти можуть потребувати повторної перевірки. Можливість може бути реалізована чудово, але без адаптера для конкретної моделі нею там не скористатися — інструмент застрягає на етапі поширення.
На ранньому етапі кожен був змушений будувати власну інтеграцію. Ті самі дії — отримати список середовищ, запустити браузер, прочитати сторінку — доводилося переписувати для нового виклику, а логіка часто відрізнялася: одні розміщували очікування в client, інші — у server.
Протокол розділяє обидві сторони
MCP (Model Context Protocol) став публічним наприкінці 2024 року. Його підхід полягає у стандартизації виявлення та виклику інструментів: протокол визначає, що саме відкривається, як описуються параметри та яка структура повертається.
Архітектура перетворюється на Agent, підключений до MCP Client. Client за протоколом підключається до кількох MCP Server, за якими знаходяться конкретні можливості. Обсяг реалізації зменшується з N×M до N+M: сторона моделі один раз реалізує клієнт, а сторона інструмента — сервер.
Ролей лише три. Host — застосунок, у якому працює модель і який запускає клієнт. Client — реалізація клієнта протоколу, зазвичай одна на кожен Server. Server створюється постачальником інструмента та відкриває можливості як стандартизовані інструменти.
Наразі є два способи зв’язку. Локальний режим використовує стандартне введення і виведення, а клієнт і сервер працюють на одній машині; шлях короткий, конфігурації мало, тому такий варіант часто застосовують в автоматизації. Віддалений режим використовує HTTP або WebSocket і підходить для розподілених розгортань, але потребує додатково продумати автентифікацію та мережеві межі.
У браузері відкриваються три рівні можливостей
Коли браузерне середовище підключається до протоколу, доступні можливості загалом поділяються на три рівні.
Найвищий рівень — середовище: отримати список середовищ облікового запису, створити нове за конфігурацією, запустити вибране середовище, прив’язати мережевий вихід і закрити після використання. Раніше ці операції були розкидані по API різних постачальників; тепер вони стають інструментами, які модель може виявляти й викликати. Після запуску зазвичай повертається endpoint для налагодження, наприклад порт або адреса WebSocket, яку можна передати драйверам на кшталт Selenium чи Puppeteer.
Середній рівень — сторінка: відкрити адресу, прочитати DOM або дерево доступності, перемкнути вкладку та зробити знімок екрана.
Нижній рівень — дії: натискання, введення, прокручування, очікування виконання умови та обробка спливних вікон.
Ключова зміна не в кількості дій. Середовище перестає бути кодом, який треба писати самостійно, і стає ресурсом, який Agent може сам обрати й використати. Достатньо чітко сформулювати мету; Agent може вирішити, створювати нове середовище чи повторно використати наявне, а також у якому порядку викликати інструменти. Особливо це помітно, коли кілька середовищ працюють паралельно: планування задається в prompt, а не жорстко кодується в script.
Що поки залишається невирішеним
Протокол вирішує підключення, а не коректність. Залишається кілька моментів, які легко не помітити.
Якість описів інструментів визначає результат викликів. Якщо параметри неправильні або вибрано не той інструмент, протокол цього не виправить. Коли інструментів стає більше, їхні описи також займають контекст, тому потрібно балансувати між кількістю та деталізацією. За надто грубої гранулярності моделі незрозуміло, скільки задач виконує інструмент; за надто дрібної контекст швидко заповнюється.
Права доступу й аудит поки на ранньому етапі. Багато Server працюють локально на одній машині, відразу мають значні привілеї та не забезпечують тонкої авторизації чи повних журналів викликів. У віддаленому режимі спочатку треба визначити, хто може підключатися і що може бачити.
Нестабільність сторінок також не зникає. Ненайдені елементи, нестабільна послідовність завантаження, прострочені сесії входу та CAPTCHA все одно потребують очікувань, повторних спроб і резервної логіки. Протокол лише уніфікує точку входу.
Зрілість екосистеми також нерівномірна. Різні Server не повністю збігаються за підтримуваними типами ресурсів, структурами відповіді та кодами помилок. Коли завдання поєднує кілька Server, логіку оркестрації часто все ще треба писати самостійно. Сам протокол продовжує розвиватися, тому варто враховувати відмінності поведінки між версіями.
Є ще одна межа, яку потрібно чітко відокремлювати: протокол визначає, як модель викликає інструменти, але не вирішує, чи відповідає саме завдання правилам. Чи дозволено збір даних, чи законною є мета використання облікового запису і чи не порушуються правила платформи — це окремі оцінки, не пов’язані з тим, наскільки гладко працює підключення.
У сценаріях із кількома середовищами ізоляція між ними та узгоджене налаштування мережевого виходу, часового поясу й мови часто впливають на результат сильніше, ніж спосіб інтеграції. На рівні ізоляції середовищ PurpleMark надає інтерфейси створення, запуску й мережевого налаштування, які можуть викликатися AI-інструментами та координуватися одним клієнтом.
Цей матеріал призначений лише для пояснення технічних принципів. Використовуйте відповідні протоколи та інструменти згідно з чинними законами й правилами.
