Plugins, Model Context Protocol (MCP), Skills і connectors: оберіть потрібний шар

У попередніх главах ми розібрали окремо інструкції репозиторію, Skills, hooks, MCP та субагентів у двох екосистемах. Тепер важливо побачити, як ці речі поєднуються і чому схожі назви в різних продуктах не означають однакової поведінки.

Уявімо запит: «Агент має перевірити Jira-задачу й пов’язаний PR (Pull Request — запит на включення змін), зіставити їх із критеріями приймання та повідомити, чи можна зливати». Для цього може знадобитися доступ до Jira й GitHub, процедура перевірки та, можливо, спосіб поширити цю процедуру на команду. Це чотири різні потреби. Один плагін не обов’язково розв’яже їх усі.

Після цієї глави читач уміє відокремлювати технічну можливість від дозволу й знання процедури, розуміє життєвий цикл інтеграції та може вибрати найменший достатній механізм. Потрібна базова знайомість із главами 29–38; назви конкретних поверхонь і версій далі позначено як перевірені станом на 24 вересня 2026 року.

39.1. Чотири різні питання, які легко змішати

Host — застосунок, який веде взаємодію з моделлю та надає їй інструменти. Tool — машинно-виконувана операція з назвою, аргументами й результатом. Skill — пакет інструкцій для повторюваної процедури; plugin — спосіб згрупувати й поширити компоненти. Connector або app — назва продуктової інтеграції із зовнішнім сервісом.

Під час вибору інструмента дайте чотири окремі відповіді.

Питання	Що саме шукаємо	Приклад
Можливість	Яку дію або дані host може отримати?	Прочитати опис Jira-задачі й поточний diff PR
Дозвіл	Хто, від імені якого облікового запису, у яких межах може це зробити?	Користувач має читання проєкту; запис коментаря заборонено
Процедура	Який порядок дій дає корисний і перевірний результат?	Зіставити критерії задачі з файлами diff і назвати відсутні докази
Пакування	Як зібрати та поширити конфігурацію і процедуру?	Командний плагін, що містить Skill та підключення до сервісу

Ці шари відповідають різним механізмам. API (application programming interface — прикладний програмний інтерфейс) задає спосіб, яким програма викликає іншу програму. MCP (Model Context Protocol — протокол підключення контексту й інструментів до модельного застосунку) стандартизує частину взаємодії між host і сервером. Конкретний host вирішує, як показувати й контролювати виклики, а назви connector/app залежать від продукту.

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

У попередніх главах Skills пояснено докладно для Claude й OpenAI, MCP — для Claude Code, а Codex-субагенти — окремо. Тут ми не повторюємо створення цих компонентів. Ми з’ясовуємо, коли їх поєднувати, які права потрібні та де саме їх поєднання працюватиме.

Можливість не дорівнює дозволу

Модель може бачити опис інструмента, але виклик ще може бути заборонений політикою host, користувацьким підтвердженням, робочим простором або зовнішнім сервісом. Сервер MCP може оголосити інструмент запису, але запит користувача може мати лише читання. Skill може вимагати злиття PR, але текст процедури не надає такого повноваження.

Зворотне теж можливе: обліковий запис має доступ, але агент не знає, як правильно ним скористатися. Наприклад, токен GitHub дозволяє прочитати PR, але коректний review усе одно має зіставити diff із конкретними критеріями, відрізнити факт від припущення та перевірити HEAD (поточний commit гілки), до якого належать докази.

Отже, перевіряйте дві незалежні речі: чи може система виконати дію та чи має конкретний виклик право на неї. Окремо перевіряйте третю: чи дає процедура достатні кроки, щоб результат був правильним. Саме це розрізнення лежить в основі всіх прикладів нижче.

39.2. Tool, API, MCP і connector — не синоніми

Tool — це доступна host-у операція з назвою, аргументами та результатом. Наприклад, інструмент може знайти задачу за ключем або прочитати список файлів у PR. Опис і схема аргументів допомагають моделі вирішити, який виклик запропонувати. Вони самі не гарантують, що сервер перевірить кожну бізнесову умову так, як очікує користувач.

API — ширший програмний контракт. У типовому прикладі з function calling модель повертає назву функції та аргументи, а код застосунку розробника вирішує, як виконати дію й повернути результат моделі. Оголошення функції в API не створює доступ до Jira чи GitHub, якщо автор застосунку не реалізував це з’єднання і не налаштував облікові дані OpenAI про виклик функцій.

MCP — відкритий протокол інтеграції, а не окремий хмарний сервіс чи дозвіл. У його моделі host керує клієнтами, клієнт з’єднується із сервером, а сервер може оголошувати tools, resources або prompts. Tool призначений для виклику операції; resource надає дані; prompt може бути шаблоном взаємодії. Конкретні host-продукти підтримують різні набори примітивів і транспортів, тому наявність можливості у специфікації не доводить, що її показує кожен клієнт MCP, специфікація 2026-07-28.

Коли host підключає віддалений сервер MCP, він може отримати список доступних tool-визначень і передавати серверу вибрані виклики. На виконанні сервер має перевіряти аргументи й застосовувати власну модель авторизації, якщо цього потребують його дані чи операції; сам протокол не нав’язує всім інтеграціям один спосіб входу. MCP не доводить, що сервер безпечний, а опис tool не є довіреною інструкцією.

Connector/app — переважно термін продуктового інтерфейсу. У поточному керуванні інтеграціями OpenAI назва «app» охоплює підключений сервіс або сервер MCP; користувач бачить доступність інтеграції й дозволені дії у своїй поверхні. У Claude chat назва connector часто стосується інтеграції з сервісом чи віддаленим сервером MCP. Це не тотожне протокольному терміну «client»: у специфікації MCP client — компонент усередині host, який спілкується із сервером керування apps і connectors в OpenAI, огляд MCP в Anthropic.

Підключений сервіс не обов’язково використовує MCP у кожній реалізації. Інтеграція може викликати API постачальника напряму або використовувати внутрішній адаптер. Не робіть висновок про протокол лише з того, що в меню написано «app» чи «connector».

39.3. Skill задає процес, plugin пакує компоненти

Skill зберігає інструкції, за якими host намагається виконати повторювану роботу: коли застосувати процес, які джерела прочитати, у якому порядку діяти, що перевірити та який звіт повернути. Його текст може посилатися на tools, але не створює ці tools, користувацький обліковий запис або доступ до мережі. Перевірені формат і межі Skills описані у главах 31 і 37 та у документації Skills OpenAI.

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

Plugin — спосіб зібрати й поширити сумісну з певною екосистемою конфігурацію. За поточною схемою Agent Plugins OpenAI пакет може містити Skills, сервер MCP, ресурси, а також необов’язкові hooks; hooks виконуються лише в підтриманому Codex-середовищі виконання, а наявність пакета у веб-каталозі не встановлює локальні скрипти. Плагіни для Claude Code мають власний manifest і можуть упаковувати Skills, subagents, hooks, MCP-сервери, Language Server Protocol (LSP — протокол інтеграції мовних серверів) та налаштування. Компоненти, які приймає імпортер OpenAI з плагіна Claude, не тотожні всьому, що може описати Claude manifest: офіційний конвертер перетворює команди й агентні процедури на Skills, а hooks треба адаптувати до runtime Codex; частина специфічних налаштувань Claude відкидається. Тому перевіряйте, що саме було перенесено архітектура плагінів OpenAI, формат пакування OpenAI, плагіни Claude Code, конвертація Claude plugin для OpenAI.

Manifest — структурований опис пакета, за яким host знаходить його назву, компоненти й налаштування; у цих прикладах це файли JSON (JavaScript Object Notation — нотація об’єктів JavaScript). Нинішній переносний формат Agent Plugins має кореневий <code>plugin.json</code>, директорію <code>skills/</code> і, якщо потрібен сервер, <code>mcp.json</code>; OpenAI-специфічні поля можна оголосити окремо в <code>extensions.com.openai</code>. Коли цей кореневий overlay присутній, його OpenAI-поля замінюють legacy overlay із <code>.codex-plugin/plugin.json</code>, а не зливаються з ним. Старий файл лишається fallback-схемою сумісності. Claude Code натомість використовує <code>.claude-plugin/plugin.json</code>, а його MCP-конфігурація може бути в <code>.mcp.json</code>. Документація OpenAI прямо підтримує окремий шлях імпорту Claude manifest, але це перетворення з правилами й обмеженнями, не обіцянка ідентичного виконання в усіх продуктах OpenAI: пакування plugin, Claude Code: плагіни, конвертація Claude plugin для OpenAI.

Під час імпорту плагіна Claude з MCP-сервером OpenAI вимагає стабільну публічну HTTPS-адресу сервера зі Streamable HTTP. Якщо сервер локальний, його треба розгорнути за такою адресою; коли це неможливо, документація пропонує звернутися щодо підтримки локального MCP. Уже зареєстроване MCP-підключення не переноситься простим копіюванням посилання. Порівняйте вихідний і перетворений пакети та окремо перевірте, які компоненти й налаштування реально перенесені посібник з імпорту Claude plugin.

Конкретний зафіксований приклад дає GitHub-репозиторій OpenAI: у зрізі commit <code>1dc195897af4161d039b80d8471ec0a10c9bbc89</code> пакет GitHub має <code>.codex-plugin/plugin.json</code>, посилається на <code>.app.json</code> і оголошує метадані інтерфейсу. Це сумісний layout конкретного прикладу Codex, а не доказ, що той самий каталог імпортується Claude Code чи будь-яким іншим host manifest GitHub plugin у openai/plugins.

Приклад форми пакета — це не універсальна схема

Уявна директорія пакета може містити короткі інструкції, окремий MCP-конфіг і файли довідки. Це лише пояснювальна структура:

team-review-package/
  <manifest, який розуміє вибраний host>
  skills/
    evidence-review/
      SKILL.md
      references/
  <необов’язкова конфігурація MCP, якщо host її підтримує>

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

39.4. Продукт і поверхня визначають значення

Однакове слово може вказувати на різний рівень. ChatGPT, Codex і OpenAI API — три різні продукти. Claude chat, Claude Desktop, Claude Code і Anthropic Messages API також мають різні моделі підключення та виконання. Поведінку треба підтверджувати для конкретної комбінації продукту, host і версії.

Поверхня	Що тут означає механізм	Де проходить важлива межа
ChatGPT app / connector	Підключений сервіс, яким можна скористатися в чаті в межах доступної дії	Наявність у робочому просторі, підключення облікового запису, ролі користувача, підтвердження дій та правила адміністратора можуть обмежувати можливість
OpenAI plugin	Пакет, який може поєднати Skills, MCP-сервер та інші підтримувані компоненти	Документація описує plugins у Chat і Work на ChatGPT web, desktop і mobile, у Codex desktop та в CLI (command-line interface — інтерфейсі командного рядка) plugin browser; IDE (integrated development environment — інтегроване середовище розробки) extension не підтримує plugins. Окремі компоненти мають вужчу сумісність
Codex-runtime hooks	Автоматизація подій у середовищі Codex, зокрема ChatGPT Work	Працюють лише якщо скрипт доступний у середовищі виконання і його визначення схвалене; hooks не запускаються у звичайному ChatGPT Chat
OpenAI API	Оголошені функції, вбудовані tools або підключення MCP у конкретному API-запиті	Розробницький застосунок відповідає за власний код функцій; віддалений MCP має окремі сервер, авторизацію та політику схвалення
Claude connector у чаті	Підключення до вбудованої інтеграції чи сумісного віддаленого сервера	Організація може вимагати попередню конфігурацію; користувач може окремо під’єднати або ввімкнути connector
Claude Code plugin / MCP	Локальні чи командні компоненти Claude Code з власними налаштуваннями й дозволами	Довіра до репозиторію, джерело plugin, вид транспорту та правила виклику важать окремо
Anthropic Messages API	API-функція для роботи із сумісними віддаленими серверами MCP	Клієнт API керує токеном OAuth (Open Authorization — стандарту делегованої авторизації) та його оновленням; поточний connector API підтримує tool-виклики, а не весь набір можливостей MCP

Це навмисно не каталог тарифів або кнопок: доступність залежить від плану, регіону, налаштувань організації, способу входу та поточної версії. Каталог plugins OpenAI спільний для ChatGPT і Codex, але документація окремо визначає поверхні, де працює пакет, та де доступна кожна його можливість. Зокрема, plugins описані для Chat і Work у ChatGPT web, desktop і mobile, у Codex desktop та CLI plugin browser; IDE extension не підтримує plugins. Hooks запускаються лише у Codex runtime, зокрема в ChatGPT Work, коли скрипт доступний у середовищі й визначення hook схвалене; звичайний ChatGPT Chat не виконує hooks архітектура plugins OpenAI, пакування plugins та вимоги до hooks, керування plugins у робочому просторі, імпорт Claude plugin. Документація ChatGPT описує керування custom MCP apps і підтвердженнями окремо від вбудованих інтеграцій; документація Anthropic розрізняє хмарні connectors, локальний MCP у Desktop, сервери Claude Code і API connector режим розробника ChatGPT та MCP apps, підключення MCP у Claude Code, Claude Messages API MCP connector.

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

У Claude Code локальний сервер через standard input/output (stdio — стандартні потоки вводу й виводу) запускається як локальний процес; віддалене підключення працює через мережевий транспорт. Це відрізняється від Claude chat custom connector, який звертається до сервера з інфраструктури Anthropic і потребує доступного ззовні endpoint-а. У Claude Messages API розробницький застосунок передає потрібні дані автентифікації й керує життєвим циклом токенів. Не переносьте властивості одного з цих шляхів на інший Claude Code MCP, custom connectors в Claude, Messages API MCP.

Підтримку перевірено за поточною документацією, доступною 24 вересня 2026 року. Перед поширенням повторно перевірте клієнт і компоненти: наявність одного plugin у каталозі не означає, що його MCP-сервер, Skill, app або hook працюватиме на кожній поверхні. Зокрема, не плутайте plugins у Codex desktop із підтримкою plugin-пакетів у IDE extension; окремо налаштований MCP може мати власні правила керування plugins у робочому просторі, пакування plugins та вимоги до hooks.

39.5. Від пошуку до перевіреного результату

Уточнюйте поверхню, на якій встановлюється саме plugin із hooks: актуальна документація пакування OpenAI називає lifecycle hooks для plugin-ів, установлених вручну в Codex desktop. Це вужче за загальну підтримку Codex runtime hooks у ChatGPT Work та Codex. Не робіть висновок, що кожен plugin із каталогу несе або запускає свої hooks; також вебустановка не розгортає скрипти в середовище виконання.

Слово «встановлено» скорочує кілька різних станів. Для надійної діагностики розгляньте послідовність:

1. Виявлено. Людина або host знає, що пакет, app чи сервер існує. Це ще не означає, що він у каталозі цього користувача.
2. Встановлено або налаштовано. Файли пакета з’явилися в потрібному місці або host отримав адресу сервера. Для app це ще не обов’язково означає, що під’єднано обліковий запис.
3. Дозволено політикою. Користувач чи адміністратор дозволив потрібну категорію використання. Організаційне правило може заборонити компонент, який користувач може локально бачити.
4. Підключено й автентифіковано. Мережа доступна, сервер відповідає, а потрібна ідентичність пройшла перевірку. Для сервера без автентифікації цей крок має іншу форму; MCP не вимагає одного глобального способу входу.
5. Можна викликати. Skill знайдений за описом або викликаний користувачем; tool перелічено host-ом; дія не заблокована політикою чи відсутністю інструмента.
6. Виконано й перевірено. Виклик отримав результат; агент перевірив його повноту, дату, потрібну ревізію та побічний ефект, якщо він був.

Це діагностична модель, а не однакова система статусів у всіх продуктах. Наприклад, напис «connected» може означати, що OAuth авторизацію отримано, але не що конкретний tool доступний у цьому чаті. Список MCP tools також може змінитися після підключення. MCP передбачає механізми, через які сервер може оголосити зміни списку; отже, довіра до endpoint-а є довготривалим рішенням, а не одноразовою перевіркою manifest-а специфікація MCP 2026-07-28, безпека MCP.

Права утворюють кілька незалежних контрольних точок

У типовому інтеграційному виклику рішення може залежати від:

• чи доступний цей продукт і connector користувачу;
• чи авторизовано правильний зовнішній обліковий запис;
• які області даних і операцій охоплює його доступ;
• чи дозволяє host конкретний tool;
• чи треба показати підтвердження перед передаванням даних або записом;
• чи пропустить запит політика організації;
• чи перевірить сервер авторизацію ще раз на своїй стороні.

Це не надлишкове дублювання. Наприклад, host може заборонити використання MCP-сервера цілком, а сервер — не дозволити видалення в облікового запису з правом лише на читання. Не покладайтеся на одну широку «довіру до плагіна» як на заміну перевірці кожного рівня. Поточні рекомендації OpenAI та MCP наголошують на мінімальних правах, згоді, перевірці входу та розгляді результатів tool як потенційно недовірених OpenAI: безпека plugins, MCP: рекомендації безпеки.

39.6. Три повні приклади вибору

Приклад 1. Review Jira-задачі та PR без права злиття

Ситуація. Команда хоче, щоб агент перевіряв, чи відповідає PR вимогам Jira, і повертав findings із доказами. Для навчального прикладу обидва підключення надають лише читання.

Проблема. Прохання «перевір Jira і PR» саме по собі не дає способу знайти задачу, прочитати diff чи визначити, чи змінився PR після перевірки. А доступ до сервісів не підкаже, як відрізняти blocker від питання до автора.

Варіанти. Якщо в робочому host уже є дозволені Jira- і GitHub-apps, новий MCP-сервер нічого корисного не додасть. Якщо задача одноразова, достатньо чіткого prompt-а. Якщо такий review — звичайний командний процес, повторювані кроки доречно описати в Skill. Якщо іншим користувачам потрібне спільне встановлення, можна розглянути пакет, який поширює Skill і потрібну конфігурацію; це виправдано лише якщо вибраний host підтримує таку комбінацію.

Рішення. Команда лишає дозволені read-only apps як джерело даних і додає Skill, який описує послідовність:

1. Отримати точний ключ Jira-задачі й точний ідентифікатор PR.
2. Прочитати актуальні критерії та поточний HEAD PR; записати їхні ідентифікатори у звіті.
3. Прочитати diff, релевантні файли й за наявності — результати перевірок, які реально виконувалися.
4. Для кожного критерію вказати доказ, часткове покриття або брак доказу. Кожен finding має мати файл/рядок або інше перевірне посилання, умову й наслідок.
5. Повернути PASS (перевірено, blocker-ів не знайдено), MUST-FIX (обов’язкове виправлення до злиття) або PENDING EVIDENCE (висновок відкладено через брак доказів) за локальною шкалою команди. Якщо HEAD змінився під час review, повторно перевірити diff і checks перед висновком.
6. Завершити читанням і звітом. Цей Skill не пише Jira-коментар, не схвалює й не зливає PR.

Результат. Агент повертає таблицю «критерій → доказ → результат» і точний SHA (Secure Hash Algorithm — алгоритм криптографічного гешування) перевіреного HEAD. Якщо немає доступу до перевірок, позначає це як PENDING EVIDENCE, а не припускає зелену збірку.

Умовні дані й спостережуваний результат. У вигаданому навчальному PR demo-17 на HEAD 4f12c8a (скорочене умовне позначення commit) змінений src/jira-review.ts містить виклик GET /issues/{key}; у переглянутому diff запису до Jira не видно. Для вузького критерію «цей diff не додає Jira-запис» висновок — PASS. Статус CI (Continuous Integration — безперервна інтеграція) та поведінка незміненого коду не надані, отже щодо них — PENDING EVIDENCE.

Чому підходить. У системі вже є потрібні читальні capabilities, тому команда не створює зайвий сервер. Skill додає процедурне знання, якого немає в описі tool.

Межа. Skill не відкликає й не обмежує права зовнішнього сервісу. Щоб реально заборонити запис або merge, треба мати read-only доступ у провайдера чи відповідну політику host. Текст «не зливай» сам по собі не є технічним контролем.

Приклад 2. Release Skill є, production-доступу немає

Ситуація. Після review встановлено командний release Skill, який описує підготовку випуску сайту футбольної статистики: зафіксувати зміни, перевірити release notes і зібрати потрібні докази. Для реального production deployment потрібен окремий обліковий запис із відповідною роллю; поточне середовище його не має.

Проблема. Інструкція містить крок «запустити production deployment». Це не означає, що агент бачить відповідну кнопку, ключ, cloud account або право виконання. Наявність Skill і його успішний виклик не є доказом випуску.

Варіанти. Можна безпечно підготувати матеріали та передати їх уповноваженому реліз-менеджеру. Можна попросити адміністратора видати мінімально необхідний тимчасовий доступ за погодженою процедурою. Не можна підмінити відсутній доступ текстовою обіцянкою чи взяти випадковий production secret з репозиторію.

Рішення. Skill ділить роботу на підготовку та зовнішню дію. Агент перевіряє доступні release notes та фактичні результати pre-production перевірок, формує короткий план із версією і точним commit, а потім явно зупиняється на кроці deployment. У звіті пише: «Матеріали підготовлено; production deployment не запускався, бо немає підтвердженого доступу». Він не вгадує успіх за відсутністю помилки.

Результат. Команда отримує готовий пакет перевірених доказів і чітко позначену межу. Власник із дозволом може провести deployment, а потім передати агенту URL (Uniform Resource Locator — уніфікований локатор ресурсів) або ідентифікатор релізу для незалежної перевірки.

Умовні дані й спостережуваний результат. У цьому вигаданому навчальному пакеті release notes називають версію v1.4.0, а pre-production звіт має статус PASS для commit a7c219e (скорочене умовне позначення); ідентифікатора production deployment немає. Отже, зафіксовано готовність матеріалів і результат перевірки лише для вказаного commit; production deployment не підтверджено й не оголошено виконаним.

Чому підходить. Цей процес зберігає корисну автоматизацію там, де доступ справді існує, і не приховує відсутній дозвіл.

Межа. Якщо host не має навіть read-only доступу до release data, Skill не може підготувати перевірені матеріали звідти. Він має попросити безпечний доказ або позначити невідоме, а не вигадувати стан production.

Приклад 3. Перенесення workflow із Claude Code до Codex

Ситуація. Команда має Claude Code Skill для review міграцій даних і хоче користуватися тією самою процедурою в Codex.

Проблема. Файл із назвою <code>SKILL.md</code> може бути зрозумілим обом системам на рівні тексту, але його frontmatter, шляхи пошуку, правила виклику, MCP-конфігурація та hooks не обов’язково мають однакову семантику. Перенесення лише директорії може тихо втратити важливу умову або змінити права.

Варіанти. Можна залишити текст workflow у спільному нейтральному документі й зробити тонкий адаптер для кожного host. Або підтримувати два окремі Skills із посиланням на єдині правила. Якщо потрібне встановлення та версіонування разом із конфігурацією, команда може упаковувати адаптери окремо у Claude Code plugin та Codex/OpenAI plugin. Останнє збільшує супровідну вартість і потрібне не кожній команді.

Рішення. Команда перевіряє підтримуваний шлях конвертації Claude plugin у OpenAI, але порівнює вихідний пакет із вхідним перед використанням: конвертер може перетворити корисні команди й агентні інструкції на Skills, адаптувати деякі hooks і не перенести MCP-конфіг чи окремі settings. Команда переносить зміст процедури окремо від конфігурації:

• залишає спільні критерії review, класифікацію ризиків, формат доказу й стоп-умови в нейтральному Markdown-документі;
• перевіряє, як кожен host знаходить Skill і чи підтримує використані поля;
• замінює host-специфічні виклики, наприклад slash-command Claude Code або allowed-tools, на підтверджені механізми Codex; невідоме позначає для ручного рішення;
• окремо конфігурує підключення до Git-сервісу, його автентифікацію та права, не переносить токени чи конфігураційні секрети;
• повторює набір позитивних, негативних і межових тестових запитів на обох поверхнях та зіставляє висновки з очікуваним набором доказів.

Офіційний імпортер OpenAI має явні правила перетворення: Claude commands та agents можуть стати Skills; hooks потребують адаптації й довіри до коду в підтриманому середовищі; частина продуктоспецифічних налаштувань, серверних declarations або форматів не переноситься автоматично. Це корисний шлях міграції, але його результат треба перевірити за кожним компонентом OpenAI: submit a Claude Code plugin.

Результат. Команда має однакову логіку review, але два перевірені адаптери. Кожен має власний запис про версію host, шлях пошуку, доступні інструменти й фактичні результати перевірки. «Файл скопійований» більше не подається як доказ повної сумісності.

Чому підходить. Процедурне знання можна повторно використати, не зливаючи з ним продуктовий синтаксис і повноваження.

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

Свідчення несумісності — конкретний звіт, не універсальний закон

GitHub issue у Claude Code описав випадок, коли плагін зі стороннього marketplace було встановлено, але його Skills/commands/agents не виявлялися на заявленій автором версії 2.1.76. Практичний звіт іншого автора зафіксував схожу межу в Claude Code 2.1.224: пакет із portable-root <code>mcp.json</code> відкривав Skill, але MCP tool не з’являвся, доки автор не підлаштував конфігурацію під файл, який очікує Claude Code. Це результати конкретних перевірок, не доказ поточної поведінки кожного плагіна; вони показують, навіщо тестувати повний набір компонентів після імпорту Claude Code issue #38670, практичний звіт про portable plugin layout.

39.7. Як вибрати найменше достатнє рішення

Почніть із того, чого бракує:

Якщо бракує…	Спочатку розгляньте…	Не припускайте…
Одноразового пояснення чи плану	Prompt і доступні в сесії джерела	Що для кожного запиту потрібен Skill
Повторюваної процедури з тими самими доказами	Skill або короткий документ workflow	Що текст автоматично виконає API-виклик
Доступу до зовнішніх даних чи дій	Уже дозволений app/connector або існуючий tool	Що потрібно розробити власний сервер
Стандартизованого з’єднання з сервісом	MCP, коли його підтримують конкретні клієнт і сервер	Що протокол автоматично надає автентифікацію й потрібну роль
Детермінованої перевірки	Існуючий тест чи невеликий контрольований script	Що мовна інструкція надійніша за точну перевірку коду
Повторного командного встановлення компонентів	Підтримуваний plugin чи marketplace	Що будь-який plugin однаково працює у Claude, ChatGPT, Codex та API

Мінімально достатнє рішення не означає «використовувати менше безпеки». Воно означає не створювати новий механізм там, де дозволений наявний tool уже задовольняє вимогу. Якщо інтеграції немає, спершу підтвердьте точну потребу, власника доступу, джерело даних і межі запису. Лише потім вирішуйте, чи потрібна власна реалізація.

39.8. Постачання, довіра й оновлення

Plugin може бути лише пакетом інструкцій, а може містити виконуваний код, hooks чи конфігурацію віддаленого сервера. Перед встановленням перевірте:

1. Походження. Хто автор, з якого repository/tag/commit походить пакет, хто його публікує і чи має право розповсюджувати вкладені файли.
2. Код і конфігурацію. Прочитайте scripts, hooks, команди запуску, адреси серверів, конфігурацію підключення та те, які файли чи змінні середовища вони читають.
3. Права. Які читання/записи можливі, від чийого імені працюватиме server і чи можна видати вузькіший scope. Уникайте ключів, що дають значно ширший доступ, ніж потрібно.
4. Побічні ефекти. Чи може виклик створювати, редагувати або видаляти записи, надсилати дані третім сторонам, запускати shell чи виконувати реліз.
5. Зміни з часом. Чи оновлюється пакет автоматично; чи може оновлення змінити інструкцію, endpoint, залежність або список доступних tools; чи повторюється review після цього.

Популярність у marketplace не замінює перевірку джерела. Опис tool і текст із документа можуть містити недовірені дані або спробу вплинути на модель. Розглядайте їх як вхідні дані; не передавайте секрети лише тому, що tool чи Skill попросив це зробити. Офіційні рекомендації OpenAI й MCP радять мінімізувати доступ, перевіряти інструкції й аргументи, давати явне схвалення чутливим діям та оновлювати залежності OpenAI: security and privacy, MCP: security best practices.

Skill може назвати необхідну перевірку, але не перетворює її на enforcement. Навіть правило «ніколи не надсилай customer data» не блокує скрипт із мережею, якщо права та runtime цього допускають. Для гарантованого обмеження потрібні відповідні правила host, доступу до облікового запису, server-side авторизація або мережевий контроль.

39.9. Відключення й відкликання — різні операції

Вихід із workflow складається з кількох можливих дій:

• вимкнути plugin у host, залишивши його встановленим;
• видалити пакет або прибрати його джерело, щоб він не знаходився під час пошуку;
• від’єднати app у host;
• стерти локальний кеш чи OAuth token конкретного клієнта;
• окремо відкликати доступ облікового запису у зовнішнього провайдера;
• попросити адміністратора змінити організаційні ролі або політики.

Ці кроки не взаємозамінні. Видалення Skill прибирає інструкції; воно саме не відкликає GitHub чи Jira credentials. Вимкнення plugin не обов’язково скасовує дозволи OAuth, які зберігаються в provider account або іншому клієнті. Для припинення майбутнього доступу перевірте токени та авторизацію також у провайдера, якщо його документація це вимагає.

Операційний план виходу варто підготувати до встановлення: запишіть, хто володіє server endpoint-ом, де адмініструються scopes, який користувач підключив свій обліковий запис і як відкликаються його права. Після видалення зробіть перевірку з відповідної поверхні; видима відсутність плагіна не доводить, що всі токени та інтеграції зникли керування apps в OpenAI, Claude Code MCP і автентифікація, керування Claude connectors.

Окремо врахуйте конкретну поведінку продукту: у довідці OpenAI uninstall видаляє пакет, але окремо підключений MCP-сервер залишається з’єднаним у ChatGPT, доки користувач його не від’єднає. Отже, перевірте стан і пакета, і підключення; видалення одного не є відкликанням іншого OpenAI: керування plugins.

39.10. Підсумок

• Tool/API дає чи описує машинну дію; MCP стандартизує частину зв’язку host із сервером; app/connector є назвою конкретної продуктової інтеграції.
• Skill описує повторювану процедуру. Він не створює доступу й не примушує host виконувати кожне речення.
• Plugin — пакування та поширення компонентів у схемі конкретної екосистеми. Claude Code й OpenAI мають різні manifest-и, шляхи та життєві цикли.
• Перевіряйте окремо виявлення, встановлення, конфігурацію, політику, автентифікацію, виклик і фактичний результат.
• Мінімальне рішення починається з дозволеного наявного інструмента й повторно використаної процедури; власний plugin або MCP-сервер потрібен лише за наявності конкретної прогалини.
• Видалення пакета не доводить відкликання зовнішніх credentials. Плануйте оновлення та припинення доступу окремо.

Джерела та подальше читання

Мінливі продуктові сторінки та специфікацію перевірено 26 вересня 2026 року. Офіційні правила пакування, імпорту й керування підключенням MCP в OpenAI повторно перевірено 10 жовтня 2026 року.

1. OpenAI, Skills and plugins, поточна документація, доступ 2026-09-26. Підтримує різницю між Skill як інструкцією та plugin як пакетом і межі між поверхнями ChatGPT/Codex.
2. OpenAI, Plugin architecture, поточна документація, доступ 2026-09-26. Використано для складу plugin, його окремих компонентів і вибору Skill-only/MCP-only/комбінації.
3. OpenAI, MCP server concepts, поточна документація, доступ 2026-09-26. Пояснює host, client, server та tools, resources і prompts.
4. OpenAI, Package plugins, поточна документація, доступ 2026-09-26. Підтримує схему manifest-а й компонентів, виконання hooks у Codex runtime (включно з ChatGPT Work), вимогу доступного скрипту та окремого схвалення hook.
5. OpenAI, Function calling, поточна документація, доступ 2026-09-26. Підтримує розмежування оголошення функції моделлю та виконання функції кодом застосунку.
6. OpenAI, Apps and connectors for workspace administrators, поточна документація, доступ 2026-09-26. Використано для термінології app, MCP server, дій і політики, а також для поточного переліку поверхонь, де доступні workspace plugins, включно з обмеженням щодо IDE extension.
7. OpenAI, Developer mode and MCP apps in ChatGPT, поточна довідка, доступ 2026-09-26. Підтримує відмінність custom MCP apps та вбудованих інтеграцій, а також наявність контролю підтверджень.
8. OpenAI, Security and privacy, поточна документація, доступ 2026-09-26. Підтримує рекомендації щодо найменших прав, згоди, перевірки входу, секретів і залежностей.
9. OpenAI, Changelog, поточний журнал змін, доступ 2026-09-26. Використано лише як часовий контекст для розвитку plugins і доступних поверхонь, не як стабільну гарантію сумісності.
10. Anthropic, Claude Code plugins, поточна документація, доступ 2026-09-26. Підтримує manifest і компоненти Claude Code plugin та відмінність від окремих Skills.
11. Anthropic, Claude Code MCP, поточна документація, доступ 2026-09-26. Використано для локальних і віддалених серверів, конфігурації та автентифікації Claude Code.
12. Anthropic, Custom remote MCP connectors, довідка, оновлена 2026-08-11, доступ 2026-09-26. Підтримує поведінку remote connector у Claude chat і різницю з локальною конфігурацією.
13. Anthropic, MCP connector for the Messages API, поточна документація API, доступ 2026-09-26. Використано для обмеженого API connector, tool-викликів та відповідальності клієнта за OAuth.
14. Model Context Protocol, Specification 2026-07-28, версія 2026-07-28, доступ 2026-09-26. Підтримує ролі host/client/server, серверні примітиви й межу між протоколом та продуктовою реалізацією.
15. Model Context Protocol, Security best practices, поточні рекомендації для версії 2026-07-28, доступ 2026-09-26. Підтримує розгляд недовірених входів, least privilege і необхідність явної згоди.
16. Anthropic Claude Code, Issue #38670: third-party marketplace plugins cannot register skills/commands/agents, GitHub issue, відкрита 2026-03-25; звіт для Claude Code 2.1.76, доступ 2026-09-26. Використано як конкретний приклад можливої несумісності каталогу й host, не як доказ загальної поведінки.
17. OpenAI, Submit a Claude Code plugin to OpenAI, поточна документація, доступ 2026-09-26. Підтримує наявність конвертації Claude plugin і точні обмеження перенесення Skills, commands, agents, hooks, MCP та продуктоспецифічних файлів; також пояснює runtime, довіру до hook-скриптів і відсутність hook-handlers у звичайному ChatGPT Chat.
18. OpenAI, GitHub plugin manifest у openai/plugins, pinned commit <code>1dc195897af4161d039b80d8471ec0a10c9bbc89</code>, доступ 2026-09-26. Використано як приклад конкретного Codex-сумісного layout, метаданих plugin та посилання на його app-конфігурацію; не як універсальну схему.
19. Marius Bughiu, How to Package Skills and an MCP Server as One Agent Plugin, 2026-08-17, доступ 2026-09-26. Прочитаний як обмежене свідчення автора: експеримент з тим самим пакетом у portable layout і Claude Code 2.1.224; використано лише для пояснення, чому після конвертації слід перевірити, що host реально завантажив і Skill, і tool.
20. OpenAI, Plugins, довідка, доступ 2026-09-26. Використано для різниці між видаленням plugin і окремим від’єднанням MCP-сервера в ChatGPT.