Що таке MCP і навіщо він потрібен у вашому ChatGPT App

1. Навіщо взагалі потрібен окремий протокол

У цьому модулі ми нарешті розберемося, що таке MCP (Model Context Protocol), і як він вписується в стек ChatGPT App. Почнімо з базового: зафіксуємо місце MCP в архітектурі, порівняємо його з «типовим REST» і розглянемо основні сутності протоколу: tools, resources і prompts.

Уявіть, що ви пишете звичайний вебсервіс. За давньою доброю традицією ви піднімаєте REST API: у вас є /api/gifts, /api/users, /api/orders, і в кожного — свій формат входу й виходу, свої коди помилок і своя авторизація. Це звично, але є нюанс: кожному клієнту вам доводиться пояснювати, що саме й як ви реалізували. Документація, OpenAPI, приклади, SDK — усе це потрібно, адже формат API ви вигадали самі.

Із ChatGPT App ситуація ускладнюється. Вашим клієнтом стає не лише фронтенд, а й сама модель. Їй потрібно:

• дізнатися, які операції взагалі доступні;
• зрозуміти, які аргументи потрібні для кожної операції;
• викликати ці операції під час діалогу — іноді кілька разів і з різними параметрами;
• інтерпретувати структуровану відповідь і вирішити, що показати користувачеві, а що використати лише як контекст для наступної репліки.

Якщо кожен розробник вигадає власний формат API, модель опиниться в пеклі інтеграцій: під кожен App потрібен буде кастомний клієнт, купа обвʼязки й крихка логіка. Проблему розвʼязує сама ідея протоколу.

MCP (Model Context Protocol) — це відкрита специфікація стандартного способу, у який LLM‑клієнт (ChatGPT, IDE‑плагін, агент тощо) спілкується з вашим сервером інструментів і даних. Вона задає спільну мову: сервер оголошує свої інструменти, ресурси та промпти, а клієнт викликає їх і отримує результати.

Інтуїтивно MCP — це USB‑C‑порт для світу AI: якщо ви робите „флешку“ (сервіс, базу даних, CRM, пошуковий рушій), вам достатньо реалізувати один стандартний розʼєм. Тоді будь‑який „ноутбук“ (ChatGPT, інший агент, IDE) зможе підʼєднатися без кастомного кабелю.

2. Погляд зверху: де MCP в архітектурі ChatGPT App

Щоб зафіксувати загальну картину, згадаємо вже знайому архітектуру — але тепер із явним MCP‑шаром.

Цей уявний образ ви вже бачили: користувач спілкується з ChatGPT, усередині діалогу рендериться віджет (Apps SDK), а десь зовні живе ваш бекенд. Тепер додамо MCP і розкладемо все по шарах.

Ось спрощена схема:

Користувач
   ↓ (природна мова)
ChatGPT (модель + UI)
   ↓ (tool calls через MCP)
MCP‑клієнт всередині ChatGPT
   ↓ (JSON-RPC, MCP)
Ваш MCP‑сервер (бекенд)
   ↓
Ваша база даних / зовнішні API / черги

Під «MCP‑клієнтом усередині ChatGPT» тут маємо на увазі внутрішню частину платформи, яка розмовляє з вашим MCP‑сервером за протоколом: виконує discovery, викликає інструменти та читає ресурси.

З погляду Apps SDK мінімальний ChatGPT App складається з трьох компонентів. Перший — MCP‑сервер, який оголошує інструменти й віддає структуровані дані. Другий — UI‑бандл (віджет), який рендериться усередині ChatGPT і читає ці дані через window.openai. Третій — сама модель, яка вирішує, коли викликати який інструмент і як відповідати користувачеві.

Тут важливо побачити таке: у всіх попередніх модулях ви багато працювали на рівні Apps SDK і віджета, тобто у верхній частині схеми. Тепер ми спускаємося на рівень MCP‑сервера. Це ваша офіційна «мова спілкування» з ChatGPT і будь‑якими іншими клієнтами, які вирішать скористатися вашим App.

3. MCP проти «типового REST»: у чому різниця

На схемі вище ми зафіксували, де MCP розташований в архітектурі ChatGPT App. Тепер час акуратно порівняти підходи «власний REST» і MCP, щоб було зрозуміло, чому в контексті ChatGPT Apps другий варіант майже завжди виграє.

У REST‑підході ви проєктуєте ендпойнти, формати запитів і відповідей так, як вам зручно. Клієнту, щоб із вами працювати, потрібно знати URL‑адреси, методи, схеми та коди помилок. Іноді допомагає OpenAPI, іноді ви просто додаєте приклад запиту в README. Сама по собі модель нічого з цього не «розуміє»: їй потрібен шар коду, який перетворить «добери подарунок мамі на 50 років» на конкретний HTTP‑запит, а потім зробить зворотне перетворення — із JSON‑відповіді в дані, придатні для діалогу.

У MCP усе інакше. Протокол сам задає:

• як клієнт може дізнатися список ваших інструментів;
• як описати аргументи та результати через JSON Schema;
• як описати ресурси та промпти;
• як виглядають виклик інструмента та відповідь на нього.

Завдяки цьому ChatGPT та інші MCP‑клієнти можуть автоматично:

• виконати discovery — дізнатися, які у вас є tools/resources/prompts;
• побудувати внутрішню схему параметрів для кожного інструмента;
• викликати їх без зашитої в коді клієнта логіки;
• кешувати метадані та використовувати їх у пошуку й ранжуванні застосунків.

Відмінності можна звести до невеликої таблиці.

Якщо сказати емоційніше: REST — це «кожен сам за себе», а MCP — це «домовленість між усіма учасниками екосистеми про те, як спілкуватися з моделлю та даними».

4. Основні сутності MCP: tools, resources, prompts

Тепер назвімо на імʼя трьох головних героїв MCP: інструменти, ресурси та промпти.

Tools: дії, до яких ви вже звикли

Із tools ви вже стикалися в модулі 4: там ми описували інструмент, давали йому імʼя, опис і JSON Schema аргументів, а потім модель викликала його через callTool. На рівні MCP інструмент — це серверна операція з чітким контрактом:

• імʼя та опис (для моделі й для UX/discovery);
• JSON Schema для аргументів;
• JSON Schema або опис структури результату;
• додаткова метаінформація (наприклад, привʼязка до конкретного UI‑компонента в Apps SDK).

Сервер MCP має вміти щонайменше відповідати на «запит списку інструментів» і обробляти «виклик інструмента», повертаючи структурований результат.

У нашому навчальному застосунку Gift‑помічника вже є, скажімо, інструмент suggest_gifts, який приймає вік, стать, бюджет і кілька вподобань, а повертає список рекомендованих подарунків.

Умовний TypeScript‑скетч такого інструмента в коді MCP‑сервера може виглядати, наприклад, так (псевдокод/заглушка):

// Псевдокод, не фінальний API SDK
const suggestGiftsTool = defineTool({
  name: "suggest_gifts",
  description: "Підбирає ідеї подарунків за параметрами отримувача",
  inputSchema: z.object({
    age: z.number(),
    relation: z.enum(["friend", "partner", "parent"]),
    budgetUsd: z.number(),
  }),
  handler: async (input) => {
    // TODO: ваша бізнес-логіка
    return { items: [] };
  },
});

Реальні сигнатури ми розбиратимемо в наступних лекціях. Тут важлива сама ідея: інструмент — це не просто REST‑ендпойнт, а елемент протоколу з оголошеною схемою.

Ресурси (resources): дані, до яких можна звернутися за ID/URI

Ресурси (resources) у MCP — це спосіб описати доступні дані: файли, каталоги, записи БД, вікі‑сторінки, навіть результати пошукових індексів. Клієнт може:

• отримати список ресурсів;
• прочитати конкретний ресурс за ID/URI;
• іноді — виконати пошук по них.

На відміну від tools, які «щось роблять», resources зазвичай «щось зберігають». Наприклад, у Gift‑App ви можете подати каталог товарів як ресурс gift_catalog, до якого модель звертається, щоб дізнатися доступні категорії, фільтри, діапазони цін тощо.

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

const giftCatalogResource = defineResource({
  uri: "catalog://gifts",
  description: "Каталог подарунків, доступних для рекомендацій",
  read: async () => {
    // Повертаємо структуру каталогу
    return { categories: [], priceRanges: [] };
  },
});

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

Prompts: заготовлені підказки

Prompts у контексті MCP — це шаблони запитів або інструкцій, які сервер може надати клієнту. Наприклад, ви можете оголосити промпт gift_followup, який описує, як модель має уточнювати в користувача деталі про отримувача подарунка, перш ніж викликати інструмент.

Типовий приклад у дусі протоколу такий: сервер дає імʼя промпта, його призначення й іноді параметри. Клієнт може запросити список промптів, обрати потрібний і підставити в запит до моделі.

Навіщо це потрібно в ChatGPT App? По‑перше, це єдиний спосіб перевикористовувати складні підказки між різними клієнтами. По‑друге, MCP робить такі промпти явними й «контрактними», а не захованими у випадкових місцях коду.

Capabilities: оголошення того, що ви взагалі підтримуєте

Нарешті, є четвертий елемент — capabilities. Це проста декларація: сервер каже, які сутності він підтримує (tools, resources, prompts, нотифікації тощо) і які саме методи реалізує. Для клієнта це спосіб не вгадувати, що можна робити, а чого не можна, і акуратно підлаштовувати поведінку під можливості сервера.

На практиці ChatGPT, підʼєднуючись до вашого MCP‑сервера, спочатку виконує початкове узгодження, отримує список capabilities, а вже потім запитує: «Гаразд, покажи мені свої інструменти та ресурси».

5. Як MCP вбудовується у ваш поточний App

Усе це звучить трохи абстрактно. Але насправді ви вже стикалися з MCP через Apps SDK. Тож варто розібратися, як це поєднується з тим, що ви вже написали в межах Apps SDK. Звʼяжімо щойно введені сутності з тим, як зараз улаштований ваш шаблон App.

Згадаємо ланцюжок, який ви вже реалізували в шаблоні:

1. Віджет через window.openai або готові хуки викликає callTool з імʼям інструмента й аргументами.
2. Apps SDK усередині ChatGPT перетворює це на звернення до серверної частини App.
3. Сервер виконує інструмент і повертає ToolOutput, що включає structuredContent, content і _meta.
4. Віджет отримує ToolOutput і малює UI.

Секрет у тому, що кроки 2–3 реалізовано як діалог через MCP. Ваш Next.js‑шаблон містить ендпойнт (зазвичай app/mcp/route.ts або подібний), який і є MCP‑сервером. Він:

• реєструє ваші інструменти;
• описує їх через JSON Schema;
• реалізує обробники;
• відповідає ChatGPT на MCP‑запити list tools і call tool.

Тобто фактично навіть зараз, користуючись шаблоном, ви вже працюєте з MCP — просто «автоматично»: більша частина протокольної магії схована в SDK.

Модуль 6 потрібен для того, щоб перестати ставитися до MCP як до «магічного чорного ящика» і почати свідомо його проєктувати:

• додавати та версіонувати інструменти;
• використовувати resources і prompts, а не лише tools;
• читати й розуміти логи MCP;
• за потреби піднімати окремі MCP‑сервери поза Next.js‑шаблоном (наприклад, Python‑сервіс для роботи з ML‑моделлю або окремий сервіс доступу до корпоративної бази).

6. MCP з погляду різних ролей: продуктова команда vs розробка

Корисно окремо сформулювати, що дає MCP продуктовому менеджеру, а що — інженеру.

MCP для продуктового менеджера

З погляду продукту MCP — це спосіб зробити ваш сервіс «підʼєднуваним модулем» для цілого зоопарку клієнтів: ChatGPT, інших LLM‑клієнтів, IDE‑плагінів, власних агентів. Описавши один раз можливості сервера як набір tools/resources/prompts, ви дозволяєте будь‑якому клієнту:

• автоматично виявити ваш сервіс;
• зрозуміти, які задачі він розвʼязує;
• безпечно викликати потрібні операції.

У випадку з ChatGPT App це ще й підвищує імовірність того, що ваш застосунок буде обрано: модель використовує метадані про ваші інструменти, щоб вирішувати, коли пропонувати ваш App користувачеві та як правильно його представити.

Якщо зовсім коротко: MCP робить ваш сервіс стандартною «цеглинкою» екосистеми, а не кастомною інтеграцією для одного‑двох клієнтів.

MCP для розробника

З погляду інженера MCP — це контракт і протокол. Він відповідає на запитання:

• У якому форматі я маю оголосити інструмент?
• Як описати аргументи й повернути результат?
• Як клієнт зрозуміє, що я підтримую ресурси та промпти?
• Який JSON узагалі ходитиме мережею?

Коли у вас є такий протокол, стає простіше:

• писати сервери різними мовами (є офіційні SDK для TypeScript і Python);
• налагоджувати застосунок через MCP Inspector або подібні інструменти;
• ділити відповідальність між командами: одна команда робить MCP‑сервер із даними та інструментами, інша — віджет на Apps SDK, третя — може будувати своїх агентів поверх цього ж MCP‑сервера.

7. Невеличка практична перспектива: наш перший MCP‑сервер

У цій лекції ми свідомо не заглиблюємося в деталі формату повідомлень і реалізації сервера — це матеріал наступних тем. Але щоб ви заздалегідь розуміли, куди рухаємося, корисно побачити загальну структуру мінімального MCP‑сервера на TypeScript.

На практиці офіційна TypeScript‑бібліотека MCP дає вам примітиви для створення сервера, реєстрації tools/resources/prompts і запуску транспорту (зазвичай HTTP або SSE).

Умовний псевдоприклад може виглядати так:

// Це концептуальний приклад, API SDK ми розберемо пізніше
import { createServer } from "@modelcontextprotocol/sdk";

const server = createServer({
  name: "gift-genius",
  version: "1.0.0",
});

// Реєструємо інструмент
server.tool("suggest_gifts", {
  description: "Підбирає подарунки за вподобаннями отримувача",
  inputSchema: {/* ... */},
  handler: async (input) => {
    // ваша логіка
    return { items: [] };
  },
});

// Запускаємо транспорт (наприклад, HTTP)
server.listen(3001);

Важливий момент: тут ніде не згадується ChatGPT, Apps SDK або ваш конкретний фронтенд. MCP‑сервер самодостатній. Він просто вміє відповідати на MCP‑запити. А ChatGPT App — лише один із типів клієнтів, які можуть використовувати такий сервер.

У межах курсу ми триматимемося Next.js‑шаблону, де MCP‑сервер живе як частина проєкту. Але це не єдино можливий варіант.

8. MCP в екосистемі: Apps SDK, Agents SDK і ACP

Щоб не сприймати MCP як «фічу лише для Apps SDK», корисно побачити його в ширшій картині.

По‑перше, Apps SDK прямо спирається на MCP як на стандартний міст між ChatGPT і зовнішніми сервісами. Офіційна документація підкреслює: Apps SDK працює з будь‑якими MCP‑серверами. Сам протокол дозволяє описувати інструменти, повертати структуровані дані та вказувати компонент для рендерингу в UI.

По‑друге, Agents SDK, який ви розбиратимете в окремому модулі, теж уміє підʼєднуватися до MCP‑серверів. Це означає, що один і той самий MCP‑сервер із бізнес‑логікою може бути використаний:

• усередині ChatGPT як частина вашого App;
• усередині автономного агента, який працює, наприклад, у тлі вашого продукту або в batch‑режимі.

По‑третє, ACP (Agentic Commerce Protocol), який знадобиться вам для покупок і Instant Checkout, логічно будується поверх MCP‑підходу: модель і агенти викликають commerce‑інструменти, які теж описані через стандартизовані контракти.

Таким чином MCP стає фундаментом, на якому вже будуються UI (Apps SDK), агентні сценарії (Agents SDK) і комерція (ACP). Якщо ви впевнено почуваєтеся з MCP, усе інше стає зрозумілішим і передбачуванішим.

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

9. Невеликі вправи «в уяві» перед практикою

Перш ніж у наступній лекції пірнати у формат MCP‑повідомлень, корисно прогнати кілька уявних вправ. Це допоможе «перемкнути» мислення з «типового REST» на «протокол + контракт».

Уявіть, що до вашого Gift‑App хоче підʼєднатися не лише ChatGPT, а й IDE‑плагін для VS Code та внутрішній корпоративний асистент у Slack. Опишіть одним реченням, що їм усім потрібно знати про ваш сервіс. Найімовірніше, відповідь буде приблизно така: «У нас є інструмент suggest_gifts із такими‑то параметрами та каталог подарунків, доступний через такий‑то ресурс». Це й є те, що MCP формалізує.

Спробуйте також сформулювати двома фразами:

• що таке MCP для продуктового менеджера вашого App (підказка: стандартний спосіб «упакувати» функціональність для різних клієнтів);
• що таке MCP для розробника (підказка: JSON‑RPC протокол із чіткими примітивами tools/resources/prompts).

Якщо ви можете зробити це без запинок — ви вже на пів шляху до впевненої роботи з MCP.

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

10. Типові помилки й хибні уявлення навколо MCP

Помилка № 1: вважати MCP «ще одним API‑шаром поверх мого REST».
Іноді виникає спокуса: «Ну, в мене вже є REST, тож давайте я просто накручу тонкий адаптер, який перетворюватиме MCP‑виклики на REST і назад — і забуду». Формально так можна зробити, але тоді ви часто починаєте «протягувати» особливості старого API всередину MCP: дивні типи, неструктуровані відповіді, відсутність явних схем. З часом адаптер розростається, а виграш від MCP зменшується. Краще сприймати MCP як основний контракт, а старий REST — як внутрішню деталь реалізації (якщо він вам іще потрібен).

Помилка № 2: думати, що MCP «лише для ChatGPT Apps».
MCP — це загальний відкритий протокол для будь‑яких LLM‑клієнтів: ChatGPT, IDE‑плагінів, автономних агентів. Якщо ви проєктуєте MCP‑сервер із прицілом лише на один App, ви обмежуєте себе в майбутньому. Значно вигідніше відразу думати: «цей сервер зможуть використовувати й інші клієнти», — і робити інструменти та ресурси трохи універсальнішими.

Помилка № 3: ігнорувати JSON Schema та описувати аргументи «на словах».
Навіть якщо SDK дозволяє вам десь передати «будь‑який JSON», не лінуйтеся описувати схеми аргументів і результатів. Від цього безпосередньо залежать здатність моделі правильно викликати ваш інструмент, якість автодоповнення та discovery, а також зручність налагодження через інспектори. Неописані або погано описані аргументи — прямий шлях до загадкових tool‑call‑помилок.

Помилка № 4: сприймати MCP як «магічний транспорт» і не дивитися в логи.
Поки все працює, здається, що MCP — якась невидима штука, про яку не потрібно думати. Проблема в тому, що щойно щось ламається, без розуміння MCP‑структури ви довго гадатимете: «це Apps SDK? це модель? це мій бекенд?». Звичка дивитися на MCP‑повідомлення та логи на ранньому етапі вбереже від годин безглуздого «шаманства».

Помилка № 5: намагатися проєктувати складний workflow лише через REST, ігноруючи MCP‑примітиви.
Коли у вас зʼявляються багатокрокові сценарії (пошук подарунка → уточнення вподобань → вибір → оформлення замовлення), хочеться просто «зробити один великий REST‑ендпойнт». У контексті ChatGPT Apps це часто погіршує керованість: модель гірше розуміє проміжні кроки, а MCP‑клієнт втрачає можливість перевикористовувати ресурси та промпти. Значно краще розбивати функціональність на кілька добре описаних tools/resources, а логіку «зшивати» системними промптами та коректними описами.