Що таке MCP і чому раптом кожен ШІ-інструмент почав ним говорити?
Протягом більшої частини останнього десятиліття підключення ШІ-моделі до інструментів вашої компанії означало індивідуальну інтеграцію для кожної пари. Model Context Protocol, відкритий стандарт, який Anthropic представила в листопаді 2024 року, замінив це одним «штекером», що підходить всюди, — і OpenAI, Google та Microsoft із того часу всі його впровадили. Ось як він насправді працює і справжній чек-лист перед тим, як підключити його до даних вашої команди.
Відкрийте десктопний застосунок Claude і попросіть його перевірити відкриті pull request'и вашої команди — і він просто це зробить. Не тому, що Anthropic вбудувала в Claude інтеграцію з GitHub. А тому, що десь — ваша IT-команда, постачальник, розробник на GitHub — хтось написав невелику програму, яка розмовляє протоколом під назвою MCP, і Claude вже вміє спілкуватися з усім, що говорить цією ж мовою. Те саме тепер справедливо для ChatGPT, Gemini від Google і Microsoft Copilot. Саме ця конвергенція, більше за будь-який окремий реліз функції, — причина, чому MCP став тим, підтримку чого майже кожен постачальник ШІ будував протягом останнього року.
Що таке MCP насправді
MCP означає Model Context Protocol. Anthropic розробила його і 25 листопада 2024 року відкрила специфікацію разом із першими SDK. У власних матеріалах до запуску компанія описала цю ідею аналогією, яка прижилася: уявіть MCP як порт USB-C для ШІ-застосунків — один стандарт фізичного роз'єму замість окремого кабелю для кожного аксесуара. На момент запуску Anthropic назвала перших користувачів, які вже вбудовували підтримку MCP у власні продукти, включно з компаніями корпоративного ПЗ Block та Apollo, а також виробниками інструментів для розробників Zed, Replit, Codeium та Sourcegraph. Десктопний застосунок Claude в той самий день отримав можливість запускати MCP-сервери локально, на власному комп'ютері користувача.
Проблема, яку він вирішує: N інструментів на M джерел даних
Проблема, яку вирішує MCP, має назву, яку інженери вживають буденно: проблема інтеграції N на M. Скажімо, компанія використовує п'ять ШІ-інструментів, яким потрібно діяти з даними компанії, — Claude, ChatGPT, GitHub Copilot, Cursor та внутрішній бот підтримки, — а ці дані живуть у восьми місцях: Slack, GitHub, база даних Postgres, Salesforce, Notion, Google Drive, Jira та внутрішній API. Без спільного протоколу корисне підключення кожного інструмента до кожного джерела вимагає до сорока окремих інтеграцій — п'ять помножити на вісім, — кожна зі своєю схемою автентифікації, власною обробкою помилок і власним податком на підтримку щоразу, коли форма одного з цих API змінюється. Додайте шостий ШІ-інструмент — і число підскочить до сорока восьми. На практиці ніхто не будував усі сорок. Кожен постачальник ШІ будував ту невелику частину, яку вважав вартою інженерного часу, а все інше залишалося ручним: скопіювати, вставити, пояснити знову, повторити.
MCP перетворює множення на додавання. Компанія, яка хоче, щоб Claude читав з її бази даних Postgres, не будує коннектор Postgres, специфічний для Claude. Вона будує — або повторно використовує той, який уже опублікував хтось інший, — один MCP-сервер, що надає доступ до Postgres, і цей сервер працює з Claude, ChatGPT, Gemini чи будь-яким іншим MCP-сумісним агентом без додаткового коду. Власний список Anthropic на момент запуску називав готові сервери для Google Drive, Slack, GitHub, Git, Postgres та інструмента автоматизації браузера під назвою Puppeteer. Ідея ніколи не полягала в тому, що Anthropic будуватиме їх усі. Ідея в тому, що це може зробити будь-хто, і каталог доступних серверів давно виріс за межі того, що могла би обслуговувати штатом будь-яка окрема компанія.
Як протокол насправді працює
Якщо відкинути обгортку, MCP — це доволі простий клієнт-серверний протокол, свідомо позбавлений будь-якого гламуру за задумом. Він визначає три ролі. Host — це застосунок, який людина насправді відкриває: Claude Desktop, IDE як Cursor, застосунок ChatGPT. Host вбудовує MCP Client, який відкриває пряме, стейтфул-з'єднання з MCP Server — невеликою програмою, що надає доступ до однієї конкретної системи: бази даних, інструмента для тикетів, файлової системи, внутрішнього API. Клієнт і сервер обмінюються повідомленнями у форматі JSON-RPC 2.0, легкому форматі для віддалених викликів процедур, що вже поширений в існуючій інфраструктурі, через один із двох транспортів: stdio, коли сервер — це програма, що працює локально на тій самій машині, або Streamable HTTP, коли це хостований сервіс, що працює десь інде.
Те, що сервер може надавати, зводиться до трьох примітивів. Tools — це функції, які модель може викликати, щоб виконати дію, — create_task, run_query, send_message, — і модель сама вирішує, коли викликати той чи інший, виходячи з розмови. Resources — це контекст лише для читання, який Host може підтягнути і передати моделі без того, щоб їй довелося про це просити, — вміст файлу, схема бази даних, тикет підтримки. Prompts — це повторно використовувані шаблони, що запускаються користувачем, — готове «підсумуй цю гілку» чи «склади оновлення статусу», яке людина явно викликає, а не те, що модель вирішує зробити самостійно. Добре побудований сервер явно вказує, який із трьох він пропонує для конкретної можливості, тому що саме ця відмінність визначає, чи може підключений ШІ-інструмент лише подивитися на щось, чи ще й змінити це.
Хто ще підхопив це, і коли
Перші кілька місяців MCP був проєктом виключно Anthropic. Це швидко змінилося, і то у спосіб, який справді незвичний для галузі ШІ: прямі конкуренти зійшлися на протоколі однієї компанії замість того, щоб випускати власні. OpenAI додала підтримку MCP до свого Agents SDK у березні 2025 року, дозволивши розробникам підключати агентні робочі процеси до будь-якого MCP-сервера замість створення індивідуальних, специфічних для OpenAI інтеграцій інструментів. Наступного місяця Google DeepMind підтвердила, що Gemini та її власний набір інструментів для розробки агентів теж підтримуватимуть MCP — крок, який Google поєднала з власним доповнювальним протоколом Agent2Agent, спрямованим на те, щоб дозволити незалежним агентам координуватися між собою, а не з інструментами. До травня 2025 року Microsoft принесла нативну підтримку MCP у Windows 11 через те, що вона називає Windows AI Foundry, а підтримка також з'явилася в GitHub Copilot і Copilot Studio.
Жодні дві з цих чотирьох компаній не погоджуються майже в чому, коли йдеться про архітектуру моделей, ціноутворення чи платформену стратегію. Усі чотири тепер випускають продукти, які говорять одним протоколом для підключення агента до інструмента. Це достатньо рідкісне явище в цій галузі, щоб стати справжньою історією — важливішою за будь-яку окрему функцію, яку уможливлює MCP.
Чому це питання довіри, а не просто «сантехніка»
Ця конвергенція справді корисна, і саме тому MCP заслуговує на пильну увагу, а не на сліпу довіру. Протокол, який робить тривіальним підключення агента до систем вашої компанії, — це протокол, який робить тривіальним і те, що погано побудоване чи погано налаштоване з'єднання отримає доступ до тих самих систем. Сам MCP цьому не перешкоджає. Специфікація визначає, як клієнт і сервер спілкуються один з одним, — вона нічого не каже про те, хто має право надавати з'єднання, до чого це з'єднання може мати доступ, чи хтось помітить, якщо щось піде не так. Ці рішення повністю залежать від того, хто побудував або налаштував конкретний сервер чи клієнт перед вами. Деякі постачальники продумують усе це ретельно. Деякі не продумують цього взагалі, і протокол їх не зупинить.
MCP — це протокол передачі даних, а не система керування доступом. Він стандартизує те, як агент просить інструмент щось зробити. А ось чи цей запит обмежений за областю дії, логується і чи його можна відкликати — це рішення, яке хтось прийняв — або не прийняв — понад ним.
Чек-лист перед тим, як підключити сервер
Перш ніж ваша команда підключить MCP-сервер — чи це продукт постачальника, інструмент з відкритим кодом, знайдений кимось на GitHub, чи щось розроблене всередині компанії, — шість питань відрізняють контрольоване з'єднання від відчинених дверей. Жодне з них не вимагає читання специфікації. Вони просто вимагають, щоб хтось поставив їх перш ніж натиснути «схвалити», і справді прочитав відповідь, яку дає екран підключення.
| Запитайте це | Як виглядає добре | На що звернути увагу |
|---|---|---|
| Які області доступу чи інструменти він запитує? | Деталізовано Названий, конкретний список, який можна прочитати перед схваленням — «створювати завдання, читати повідомлення в цьому каналі». | Загальний доступ «Повний доступ до облікового запису» без деталізованого списку того, що він насправді може робити. |
| Це лише читання, чи він може писати й діяти? | Розділено Доступ на читання за замовчуванням; будь-яка дія, що змінює дані, потребує окремого видимого дозволу. | Об'єднано Доступ на запис включено автоматично, без можливості зрозуміти, яка можливість що робить. |
| Це персональний доступ чи спільний на всю команду? | Персональний Кожна людина входить зі своїм власним логіном; агент бачить лише те, що бачить ця людина. | Спільний Один API-ключ чи сервісний облік, використовуваний усією командою, що обходить індивідуальні дозволи. |
| Чи є журнал аудиту того, що він зробив? | Залогований Кожен виклик інструмента записано: хто підключив, до чого торкнувся і коли. | Без логів Немає запису, окрім того, що сам ШІ-інструмент вирішить вам розказати про те, що сталося. |
| Чи можна відкликати доступ миттєво? | Миттєво Один перемикач, що діє негайно, зі сторінки налаштувань, яку ви контролюєте. | Із затримкою Відкликання вимагає тикета в підтримку, дзвінка постачальнику, або взагалі неможливе. |
| Чи зламає відкликання щось інше? | Ізольовано Обмежено цим одним з'єднанням; вимкнення впливає лише на нього. | Заплутано Спільні облікові дані з іншими інструментами, тому відкликання одного тихо зламує три інших. |
Як насправді виглядає добре побудоване з'єднання
Власна конфігурація MCP у FabricLoop — це одна конкретна відповідь на цей чек-лист, не тому що вона незвична, а тому що кожен елемент прямо відповідає одному з шести питань вище, і варто назвати справжню механіку, а не маркетингову версію. FabricLoop працює в обох ролях одночасно: це MCP-сервер, до якого підключаються зовнішні інструменти, тож Cursor, Claude чи ChatGPT можуть створити завдання, додати коментар чи прочитати нотатку, використовуючи власні дозволи конкретної людини у FabricLoop, — і це також MCP-клієнт, що підключається назовні, тож канал може підтягнути MCP-застосунок постачальника, як GitHub чи Linear, і @згадати його, як члена команди.
Кожне з'єднання, у будь-якому напрямку, починається з людини, а не з робочого простору. Підключення зовнішнього клієнта, як Cursor, відкриває екран згоди OAuth за адресою app.fabricloop.com/oauth/consent, де ця людина вибирає робочий простір і схвалює конкретні інструменти, які запитує клієнт, — після цього клієнт може діяти лише в межах областей доступу, наданих на цьому екрані, під дозволами саме цієї людини, і ніколи — під спільним сервісним обліком. У зворотному напрямку все відбувається так само: адміністратор може увімкнути MCP-застосунок постачальника для всієї команди, але кожна людина все одно проходить власний вхід, перш ніж застосунок почне для неї працювати, і адміністратор може встановити для цього застосунку режим лише читання чи обмежити його дозволеним списком конкретних інструментів замість усього, що надає постачальник.
Кожен підключений клієнт з'являється на екрані налаштувань поруч із елементом керування «Відкликати», що негайно розриває з'єднання, — на власній сторінці людини, а не через тикет у підтримку. На тарифах Enterprise ця активність — включно з наданням доступу MCP і тим, що насправді зробив підключений агент, — потрапляє в журнал аудиту, який команда безпеки може переглянути за потреби, а не в скриншоти, витягнуті зі стрічки повідомлень постфактум.
Ніщо з цього не є екзотичною інженерією. Це невеликий, свідомо позбавлений гламуру набір рішень, застосований послідовно: обмежити область дії, прив'язати до людини, залогувати, зробити відкликаним без побічних збитків. Це той самий аргумент, який цей сайт наводить про Легкість читання в ширшому сенсі: доступ, який можна назвати, залогувати й відкликати, перевершує доступ, про який нікому не потрібно думати, — і MCP забезпечує це лише тоді, коли хтось будує саме так. Протокол робить сантехніку стандартною. Він не робить управління автоматичним.
Рішення, яке насправді має значення
MCP не зникне, і заперечувати проти нього на цьому етапі — це трохи як заперечувати проти USB. Кожен великий постачальник моделей тепер підтримує його, список доступних серверів продовжує зростати, і агент, який не може дістатися до ваших інструментів, для більшості реальної роботи — це агент, який мало що може зробити. Цікаве рішення не в тому, чи дозволити ШІ-інструменту підключатися до ваших систем, — дедалі частіше певна версія цього рішення вже приймається за вас, по одній інтеграції за раз, коли інструменти, якими вже користується ваша команда, тихо додають підтримку MCP під функцією, в яку ви натиснули, не читаючи дрібний шрифт. Рішення, яке все ще справді залишається вашим, — це те, що ви перевіряєте, перш ніж натиснути «схвалити».
MCP стандартизував те, як ШІ-агент просить інструмент щось зробити. Він нічого не зробив для стандартизації того, чи безпечно надавати цей запит, — ця частина досі є і залишатиметься рішенням людини, яка натискає «схвалити».