Головна / Статті / Плагіни агента судна, а не просто сервери MCP

Плагіни агента судна, а не просто сервери MCP

Пакет інструментів MCP з навичками, дозволами та метаданими встановлення, щоб хости отримували необхідні функції, а не незавершені адаптери.

2488 слів

Плагіни для агентів, а не окремі сервери MCP

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

Що вирішив MCP

MCP дав відповідь на питання «з чим може під’єднатися агент?» — це були текстові інструменти, хости та межі протоколу, що дозволили Cursor, Claude Desktop та користувацьким середовищам використовувати однакові адаптери.

skills/
└── architecture-review/
    ├── SKILL.md
    ├── references/
    │   └── architecture-checklist.md
    └── scripts/
        └── validate_diagram.py

Що вирішили скілли

Скілли дали відповідь на питання «як агент повинен виконувати роботу?» — це були процедури, чек-лісти та приклади, які стояли над базовими інструментами, щоб модель не винаймала процес роботи заново щоразу під час сеансу.

Очевидна наступна прогалина

Інструменти без посібників є небезпечними; посібники без інструментів — це лише театр. Команди все ще розповсюджують їх окремо: один репозиторій для серверів, інший — для команд, вікі з кроками встановлення. Плагіни агентів усувають це розділення.

Що таке плагін агента

Це версійований пакет, який визначає:

Сервери MCP (або еквівалентні інструментальні бекенди), які він потребує
Навички/інструкції системи для правильного використання
Метадані: дозволи, необхідні секрети, сумісність з хостом
Інструкції з встановлення, які може автоматизувати маркетплейс чи CLI

customer-research/
├── plugin.json
├── skills/
│   └── customer-research/
│       ├── SKILL.md
│       └── references/
│           └── report-template.md
└── mcp.json

Чому це більше, ніж „ще одна система плагінів“

Розширення браузера та плагіни IDE переважно додають інтерфейс користувача. Плагіни агентів додають функціональність: обмеження щодо облікових даних, інструменти з побічними ефектами та правила поведінки. Це підвищує вимоги до підписування, перевірки та принципу мінімальних прав.

Практична форма

Уявіть собі плагін для «тріажу підтримки»: сервер MCP для обробки заявок, інструмент пошуку в CRM та функцію, яка змушує вказувати ID заявки перед її закриттям. Встановлення цього плагіна об’єднує всі три елементи, замість того щоб потрібно було створювати три окремі інструкції з налаштування.

my-plugin/
├── plugin.json          # portable
├── skills/              # portable
├── mcp.json             # portable
└── com.vendor.client/   # vendor-specific extension
    └── hooks/

Опублікувати та встановити

Опублікування полягає у пакуванні метаданих та результатів роботи, підписуванні файлів та їх розміщенні у реєстрі, якому довіряє хост. Встановлення має бути одним командним запитом, який вирішує проблеми з залежностями, запитує потрібні дані та реєструє елементи MCP — а не списком кроків із копіювання та вставки JSON-даних.

Обмеження переносимості

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

Ментальна модель для продакшну

Ставіться до плагінів як до бібліотек із ефектами під час виконання:

Фіксація версій.
Розділення процесу виявлення та авторизації — розміщення плагіну не означає надання облікових даних для продакшну.
Інструменти в сандбоксі, які можуть здійснювати операції запису чи витрачання грошей.
Логування викликів інструментів з ідентифікатором та версією плагіну для аудиту.

Виявлення ≠ авторизація

Маркетплейси відображатимуть можливості інструментів. Лише політика організації має дозволяти використання конфіденційних даних та доступ до мережі. Таке розділення запобігає ситуації, коли встановлення інструменту автоматично означає отримання доступу до продакшну.

Місце MCP та skills

MCP залишається протоколом зв’язку для інструментів, а skills — це шар поведінкових функцій. Плагіни є одиницею розповсюдження, яка постачає як сам інструмент, так і метадані. Не відмовляйтеся від MCP; просто інтегруйте його.

Що не варто робити

Не вставляйте необмежені інструменти шеллу до публічних плагінів. Не вбудовуйте конфіденційні дані клієнтів у пакет інструментів. Не пропускайте версіонування лише через те, що це „лише запити“.

Більша зміна

Ринок переходить від каталогу інструментів до ринку можливостей: ретельно підібрані робочі процеси із чітким описом ризиків. Хронологія: сирі API → адаптери MCP → навички → підписані плагіни з політикою.

Остаточні висновки

Якщо ви все ще публікуєте лише простий сервер MCP, очікуйте заявок на підтримку щодо відсутності навичок та конфігурації хоста. Розробляйте можливості у вигляді плагінів: інструменти, інструкції, дозволи та шлях встановлення — потім ставтеся до оновлень як до випусків програмного забезпечення.

Версіонування маніфестів плагінів відбувається так само, як і версіонування API; порушення схем інструментів вимагають значних оновлень.

Версіонування плагінів має відбуватися так само, як і версіонування API; зміни схем інструментів, які порушують цілісність, вимагають суттєвих оновлень.

Версіонування плагінів має відбуватися так само, як і версіонування API; зміни схем інструментів, які порушують функціонал, вимагають суттєвих оновлень.

Версіонування плагінів відбувається так само, як і версіонування API; зміни схем інструментів, які порушують функціональність, вимагають суттєвих оновлень.

Усі статті Надіслати бриф