MCP розвивається: що мають планувати виробничі команди в нових специфікаціях
Як оновлення протоколу контексту моделі від 28.07.2026 змінює масштабування, завдання, авторизацію та кешування, та як безпечно мігрувати існуючий сервер поетапно.
Джерела: **MCP Grows Up: Six Changes Production Teams Need to Plan For**
Оновлення, яке є масштабнішим за звичайне покращення версії
Згідно з оголошенням про випуск проекту, Model Context Protocol оприлюднив своє найбільше оновлення з моменту запуску 28 липня 2026 року. У цьому документі скасовано протокольні сесії, формалізовано розширення, додано можливості для асинхронної роботи, посилено механізми авторизації та надано реальну політику поступового видалення функцій. Кандидатська версія випуску була заморожена з 21 травня, що дало розробникам SDK, клієнтському програмному забезпеченню та операторам серверів приблизно десять тижнів на тестування нової структури.
У сукупності готовий документ забезпечує безстановий ядро, підтримку багаторазових запитів, маршрутизацію за заголовками, можливість знаходження та кешування результатів, фреймворк для розширень, функції для обробки завдань, MCP Apps, посилену авторизацію та надійну процедуру поступового видалення функцій.
„Stateless MCP“ — це гарний заголовок, але список змін є довшим. Під ним ховається кілька суттєвих змін. Результати отримують поле resultType. Стрім HTTP GET було видалено. subscriptions/listen замінює старіші способи підписки. Стріми SSE втрачають можливість відновлення через Last-Event-ID. Результати списку та ресурсів зобов’язані містити підказки щодо кешування. Схеми інструментів можуть використовувати всю специфікацію JSON Schema 2020-12. Нарешті, відсутній ресурс тепер повертає стандартний код JSON-RPC -32602, тоді як раніше це був код -32002.
Вважати це просто „підвищенням версії залежностей та перезапуском“ було б помилкою. Це міграція архітектури.
1. Безстановий протокол не робить додаток безстановим
У попередніх версіях контекст встановлювався за допомогою процедури initialize/initialized. Для віддалених HTTP-серверів сервер також міг надати Mcp-Session-Id, який клієнт використовував у подальших запитах. Це пов’язувало клієнта з однією сеансом сервера, і під час реальних реалізацій часто використовувалося «липке» маршрутизування на балансувальнику навантаження, спільний сховище сеансів або поєднання обох цих методів.
У версії 2026-07-28 процедура взаємодії та протокольний сеанс зникають. Кожен запит містить інформацію про версію протоколу, можливості клієнта та необов’язкові дані про ідентичність клієнта у полі _meta. Сервери повинні реалізувати функцію server/discover, хоча клієнтам не обов’язково викликати її перед кожною операцією. Натомість клієнт може надіслати свою бажану версію та спробувати знову, якщо надійде помилка UnsupportedProtocolVersionError.
Через Streamable HTTP поточний запит передає метадані наступним чином:
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Та сама версія, метод та назва також зустрічаються у тілі JSON-RPC. Це тіло залишається авторитетним джерелом інформації, і сервери повинні відхиляти будь-яку невідповідність між заголовками та тілом. Це запобігає ситуації, коли шлюз схвалює або направляє певну операцію, тоді як сервер виконує іншу.
„Безстановий“ не означає „нічого не зберігати“
Специфікація не скасовує концепцію стану додатку; вона просто не змушує його приховувати. Коли серверу потрібна послідовність між окремими викликами, він повинен створити ідентифікатор домену, наприклад workspace_id, browser_id, basket_id, analysis_run_id або deployment_id. Клієнт або модель потім передає його як звичайний аргумент у наступних викликах:
create_workspace()
→ { "workspace_id": "ws_7f3..." }
add_file(workspace_id="ws_7f3...", ...)
→ ...
run_analysis(workspace_id="ws_7f3...")
→ ...
Це чистіше, ніж прихований стан транспортування, але це покладає на додаток нові обов’язки. Йому потрібно керувати перевірками прав власності, ізоляцією користувачів, термінами дії, правилами зберігання даних, авторизацією та захистом від спроб вгадування чи повторного використання даних. Постійні робочі процеси все ще можуть потребувати бази даних чи розподіленої кеш-системи, а завдання з довгим часом виконання за своєю суттю вимагають надійного зберігання. Інфраструктура може бути безстановою, тоді як продукт залишається становим.
2. Де безстановість справді має сенс
Просте горизонтальне масштабування
Коли запит містить усі необхідні дані власного контексту, сервер може розташовуватися за стандартним балансувальником навантаження типу round-robin. У Kubernetes зазвичай достатньо звичайних об’єктів Deployment та Service, без анотацій щодо сесійної прив’язки та без StatefulSet, призначених виключно для керування сесіями MCP. Особливо корисним є автомасштабування: новий под не повинен перебудовувати протокольні сесії перед тим, як почне обробляти трафік, а под, який замінюється під час поступового розгортання, не залишає клієнтів у недійсній сесії.
Є один недолік. Якщо додаток сервера обробляє об’єкти типу tasks, ці об’єкти все одно зберігаються у зовнішньому надійному сховищі, щоб вижити у разі втрати процесу чи пода.
Маршрутизація та політики на шлюзі
Оскільки Mcp-Method та Mcp-Name є звичайними заголовками, шлюз може маршрутизувати трафік, вимірювати обсяги та застосовувати правила без необхідності аналізувати тіло JSON. У сервісі з кількома користувачами це дозволяє встановлювати окремі ліміти для tools/list, дорогих інструментів пошуку, інструментів розгортання та будь-яких інструментів, які можуть завдати шкоди:
tools/list → high request allowance
tools/call + search → standard allowance
tools/call + deploy_prod → lower rate limit and stronger policy
resources/read → data-volume quota
Шлюз також ніколи не повинен читати clientInfo як доказ того, хто здійснює виклик. Це поле є самооголошеним та призначене для відображення, налагодження та логування. Ідентичність користувача потрібно визначати за допомогою підтвердженого токена або іншого надійного джерела.
Кешування
Відповіді на запити resources/read, resources/templates/list, resources/list, prompts/list, tools/list та server/discover містять два нові поля — ttlMs та cacheScope. Перше вказує на свіжість даних, а не інтервал опитування. Друге визначає, чи є результат публічним чи приватним. Усе, що змінюється залежно від користувача, тенанта, діапазону чи авторизації, не повинно розглядатися як спільні публічні дані, а сповіщення про зміни можуть зробити недійсним результат, який інакше залишався б актуальним.
Кешування зменшує кількість повторних запитів до каталогу інструментів та стабілізує вхідні дані для моделей. Неправильно обраний діапазон також створює нову категорію помилок, пов’язаних із коректністю та конфіденційністю.
Спостережуваність
У специфікаціях W3C описано передачу контексту відстеження через ключі _meta traceparent, tracestate та baggage. Хост, клієнт MCP, шлюз, сервер та послуги нижчого рівня таким чином мають спільний спосіб для кореляції викликів інструментів протягом усього шляху виконання. Контекст відстеження допомагає у кореляції, але не є механізмом авторизації чи гарантією цілісності, і конфіденційні дані, токени, необроблені запити та особиста інформація не повинні знаходитися в полі baggage.
3. Розширення стають концепцією першого класу
Кожне розширення тепер має ідентифікатор, правила взаємодії, визначених адміністраторів, власний репозиторій та власний цикл випуску. Клієнти вказують розширення, якими вони користуються, у характеристиках, що надсилаються з кожним запитом, тоді як сервери оголошують свої розширення через server/discover. Розширення починає діяти лише тоді, коли обидві сторони його підтримують; якщо у однієї зі сторін він відсутній, реалізація мусить повернутися до базової поведінки або надати відповідну помилку.
Це великий крок у розвитку протоколу, адже функції більше не чекають на повний випуск основної частини протоколу. Це також створює матрицю сумісності. Сервер не може припускати, що кожен хост підтримує Tasks, MCP Apps, Enterprise-Managed Authorization чи будь-яке майбутнє розширення, тому код для продакшну потребує чітких механізмів резервного функціонування:
- Інструмент, який підтримує завдання, також пропонує синхронний шлях для клієнтів, які не оголошують про наявність завдань, або повертає чітку помилку про відсутню підтримку цієї функції.
- Інструмент, підтримуваний за допомогою MCP App, повертає корисний структурований або текстовий контент, коли хост не може відобразити свій інтерфейс.
- Авторизація на рівні підприємства використовується лише там, де це дозволяє політика організації.
- Поля, специфічні для розширень, ніколи не надсилаються клієнтам, які не домовилися про їх використання.
Розширення послаблюють зв’язок із основними специфікаціями та підвищують ризик фрагментації екосистеми.
4. Завдання роблять інструменти з довгим часом виконання більш стійкими
Завдання переміщуються з експериментальної частини в офіційне розширення io.modelcontextprotocol/tasks. Якщо клієнт повідомляє, що підтримує завдання, сервер може відповісти звичайною операцією, використовуючи ідентифікатор завдання замість кінцевого результату. Потім клієнт використовує tasks/get для отримання поточного стану, tasks/update для надання необхідних даних та tasks/cancel для запиту на скасування.
Завдання проходить стани working, input_required, completed, failed та cancelled. Сервер повинен зберігати інформацію про завдання перед тим, як повернути його ідентифікатор. Скасування є кооперативним процесом, тому підтвердження запиту не гарантує миттєвого зупинення виконання завдання.
Природними кандидатами є набори тестів, конвеєри збірки, генерація коду, розгортання в хмарі, імпорт даних, обробка документів, кроки, що чекають на людське схвалення, пакетні завдання та прості обгортки над зовнішніми API завдань. Насправді мова йде не стільки про асинхронну виконуваність як таку, скільки про можливість відновлення: клієнт може зупинитися, перезапуститися та продовжити отримувати інформацію, використовуючи той самий ідентифікатор завдання.
Що мусить додати сервер у продакшені
Для виконання завдань потрібно набагато більше, ніж просто фонова нитка:
- надійний репозиторій завдань
- перевірка авторизації щоразу, коли викликаються функції
tasks/get,tasks/updateабоtasks/cancel - ізоляція власників та користувачів
- перевірка змін статусу
- зберігання результатів та помилок
- забезпечення терміну дії та очищення даних
- обмеження частоти запитів
- передача інформації про скасування
- відновлення після збою працівника
- створення ідемпотентних завдань
- захист від дублювання оновлень
- метрики щодо тривалості очікування у черзі та завдань, що застрягли
Розглядайте ідентифікатор завдання як ідентифікатор ресурсу, а не як секрет. Наявність ідентифікатора ніколи не повинна бути достатньою для авторизації будь-чого.
5. Багатократні запити замість запитів від сервера
Безстановий сервер не може покладатися на постійне двостороннє з’єднання для постановки запитань клієнту у будь-який час. Тут на допомогу приходять багатократні запити (MRTR). Коли сервер потребує підтвердження, інформації, зразків чи іншого вхідного даних від клієнта, він повертає InputRequiredResult. Клієнт збирає необхідні дані та повторює початкову операцію, використовуючи inputResponses та, за наявності, requestState.
Візьмемо приклад руйнівного інструменту:
delete_resources(resource_ids=[...])
Замість того, щоб відкрити зворотний запит для існуючого потоку, сервер відповідає:
input_required:
"Confirm deletion of 53 resources"
Клієнт отримує підтвердження та повторює початковий виклик. Повторна спроба є автономною, тому це працює у різних інстанціях, але це також означає, що сервери мають бути розроблені з урахуванням можливості повторних спроб.
Правила для продакшн-середовищ MRTR
- Не виконуйте незворотних дій, поки не будуть отримані всі необхідні дані.
- Робіть повторні спроби ідемпотентними.
- Пов’язуйте
requestStateз конкретною операцією та тим, хто її ініціював. - Видаляйте старі стани запитів.
- Відхиляйте відповіді, які посилаються на ключі, про які сервер ніколи не просив або які він вже отримав.
- Встановіть обмеження на кількість дозволених спроб, щоб уникнути утворення циклів.
- Знову авторизуйте операцію під час кожної повторної спроби.
- Ніколи не припускайте, що повторна спроба відбудеться у тій самій інстанції.
У випадках, коли робочий процес є конфіденційним, нехай requestState буде або непрозорим випадковим ідентифікатором, при цьому справжні дані зберігаються на сервері, або значенням, яке містить код автентифікації повідомлення, щоб дозволити виявити будь-які зміни.
6. Додатки MCP змінюють продукт, а не лише протокол
Додатки MCP дозволяють серверу пов’язати інструмент із інтерактивним HTML-інтерфейсом. Сумісні хости відображають його всередині інфраструктури типу sandboxed iframe. Додаток взаємодіє з хостом через JSON-RPC за допомогою postMessage, а хост контролює, які функції та інструменти може використовувати додаток. Це дозволяє створювати форми, панелі керування, діалогові вікна підтвердження, програвачі медіа, конфігуратори розгортання, екрани для сортування та інші елементи інтерфейсу, які складно описати лише текстом.
Для стартапу це може змінити економіку MVP: інтерактивний конверсаційний робочий процес без необхідності спочатку створювати окрему оболонку додатку та шар інтеграції. Проте інженерія фронтенду не зникає — команди все ще відповідають за дизайн інтерфейсу, обробку стану, налаштування CSP, код, який виконується в сандбоксі, перевірку вхідних даних, визначення можливостей хоста, безпечну обробку викликів інструментів, тестування сумісності на різних клієнтах та резервний варіант для хостів без підтримки додатків. Оскільки додатки є необов’язковим розширенням, підтримка хостів відрізняється, тому сервер має повертати змістовний структурований контент навіть тоді, коли відображення неможливе.
7. Авторизація стає суворішою та складнішою
Згідно з правилами авторизації HTTP, захищений сервер MCP виконує роль сервера ресурсів OAuth, а клієнт MCP — роль клієнта OAuth. Ця версія запозичує певні елементи стандарту OAuth 2.1 та суміжних стандартів. Сервери повинні публікувати метадані захищених ресурсів, щоб клієнти могли їх знайти, і приймаються як метадані серверів авторизації OAuth, так і OpenID Connect. PKCE є обов’язковим, як і вказівники ресурсів у запитах на авторизацію та отримання токенів, причому перевірки емітента є більш суворими. Основні правила:
- Клієнти надсилають параметр
resourceіз назвою бажаного сервера MCP. - Сервер перевіряє, чи токен, який він отримує, був створений для його власної аудиторії.
- Сервери авторизації повинні містити поле
iss, а клієнти перевіряють емітента, якщо воно є, перед тим, як обміняти код авторизації.
Authorization, а не у рядку запиту.S256.Індикатори ресурсів обмежують коло користувачів токена. Їх не слід описувати як криптографічне прив’язування токена.
Корпоративна ідентичність — це окрема справа
Основна авторизація MCP охоплює стандартний процес OAuth, який здійснюється через користувача. Централізована корпоративна політика доступу забезпечується за допомогою необов’язкового розширення Enterprise-Managed Authorization, яке дозволяє постачальнику ідентичностей організації керувати доступом до серверів MCP, включаючи процедури приєднання та виходу, умовний доступ та його забезпечення. Клієнт, система авторизації сервера та корпоративне середовище ідентичностей повинні всі підтримувати це розширення. Для перевірки безпеки архітектура поділяється наступним чином:
Core authorization
OAuth flow
issuer validation
resource/audience validation
scopes and step-up
Protected Resource Metadata
Optional enterprise extension
corporate IdP policy
SSO
centralized approval and revocation
identity-assertion exchange
Специфікація уточнює архітектуру, але не робить процес OAuth більш простим у використанні. Завантаження метаданих клієнта створює проблеми, пов’язані з SSRF та політикою довіри. Токени та облікові дані для оновлення потребують безпечного зберігання. У сценаріях з кількома видачами токенів потрібна окрема реєстрація та відстеження їхнього статусу. Метадані, URI-адреси перенаправлення, обмеження та канонічні ідентифікатори ресурсів мають залишатися послідовними.
8. Справжня політика виходу з ужитку
Функції тепер мають три статуси: Активні, Виходять з ужитку та Видалені. Основна функція зазвичай залишається у статусі «Виходить з ужитку» принаймні дванадцять місяців, перш ніж її можна буде видалити; для виходу з ужитку необхідний задокументований шлях міграції та запис у центральному реєстрі. Видалення може відбутися пізніше, ніж передбачено найранішою датою. Існує прискорений процес для активних безпекових ризиків, але навіть у цьому випадку зазвичай потрібно принаймні 90 днів.
HTTP+SSE, старіший спосіб передачі даних, має власне правило поступового відмовлення від нього та може бути видалений раніше, ніж інші нещодавно відмінені функції. Усі, хто все ще використовує його, повинні спочатку спланувати перехід на Streamable HTTP. Також варто зазначити, що правило дванадцяти місяців стосується лише функцій протоколу; API SDK мають окремі політики підтримки та терміни, які можуть відрізнятися.
Як це працює у реальних додатках
Внутрішні інструменти корпорацій
Уявіть собі компанію, яка публікує внутрішні знання, інформацію з Jira та Confluence, каталоги послуг та посібники через MCP. За старою моделлю віддалене розгортання могло залежати від принципу афінності сеансів, щоб один працівник завжди потрапляв на ту саму інстанцію. З датою 2026-07-28 рівень MCP може складатися з нестанових контейнерів за звичайним Kubernetes Service та балансувальником навантаження:
MCP host
↓
API gateway / authorization
↓
Stateless MCP Deployment
├─ Knowledge connector
├─ Jira connector
├─ Confluence connector
└─ Service catalog connector
↓
OpenTelemetry backend
Щоденна авторизація може ґрунтуватися на основному механізмі OAuth, а розширення Enterprise-Managed Authorization використовується тоді, коли потрібна централізована політика IdP. Основною обмеженням є кількість клієнтів, які фактично підтримують це розширення.
Multi-tenant SaaS
Уявімо, що постачальник інструментів для розробників продає MCP як платний API сотням або тисячам користувачів. Відсутність стану дозволяє використовувати звичайне маршрутизування між зонами, а шлюз може вимірювати обсяг використання за параметрами Mcp-Method та Mcp-Name, використовуючи дані про авторизацію користувача, а не назви чи заголовки, які надсилає клієнт. Хороша реалізація мала б розділяти обробники та завдання за користувачами, позначати каталоги, специфічні для кожного користувача, як cacheScope: „private“, порівнювати кожен заголовок із тілом повідомлення, обмежувати використання дорогих інструментів відповідно до їхніх лімітів, блокувати пошук завдань між користувачами та уникати зберігання рішень щодо авторизації у місцевій пам’яті процесу. Маршрутизування, залежне від сеансу, більше не існує; ізоляція користувачів залишається вашою відповідальністю.
Асистенти з кодування на основі ШІ
Сервер для кодування може робити доступними як завдання функції run_tests, build_project, generate_patch чи deploy_preview. Він одразу повертає ідентифікатор завдання, відправляє роботу у чергу та дозволяє агенту продовжувати читати код чи переглядати іншу проблему. Клієнт перевіряє статус на інтервалі, запропонованому сервером, і коли для якогось кроку потрібна затвердження, завдання переходить у стан input_required, і клієнт відповідає командою tasks/update. Перевагою є стійкість до перезапусків редактора та переривань мережі. Ціною є справжня система обробки завдань: міцна черга, оренда ресурсів працівників, зберігання результатів, можливість скасування, ізольовані робочі простори та політика зберігання даних.
Охорона здоров’я та фінансові послуги
Показники ресурсів та перевірки аудиторії зменшують ймовірність повторного використання токена, виданого для одного сервера MCP, на іншому, а верифікація видачі токенів знижує ризик атак типу OAuth mix-up. W3C Trace Context дозволяє відстежувати запит протягом усього шляху MCP та послуг, що знаходяться за ним. Разом вони надають командам з безпеки та відповідності стандартам більш чіткий набір засобів контролю, хоча й не є готовою відповіддю щодо відповідності. Вам все одно потрібні авторизація всередині додатку, незмінні події аудиту, правила зберігання та видалення даних, класифікація даних, обробка згоди користувачів, керування ключами, журнали адміністративного доступу, процедура реагування на інциденти та мінімальні дані для відстеження. Відстеження допомагає у діагностиці; воно не повинно бути єдиним записом аудиту.
Стартап, створений спеціально для ШІ
Уявіть собі невелику команду, яка створює інструмент для керування інфраструктурою. За допомогою MCP Apps вона може надавати форму для планування розгортання, панель керування з оцінкою витрат, діалог для схвалення, інструмент для моніторингу процесу розгортання та механізм для скасування змін. Хост забезпечує контекст для спілкування, сервер — інструменти та ресурси інтерфейсу, а додаток використовує ці інструменти через міст, яким керує хост. Спочатку окремий продукт у вигляді панелі керування може здатися зайвим, проте концепція API, авторизація, тестування інтерфейсу, доступність, правила CSP та механізми компатibilitету залишаються актуальними.
Де нові вимоги додають складності
Стан переміщується, але не зникає. Стан з’єднання стає частиною явного доменного стану, що є архітектурним покращенням, яке змушує ретельно проектувати механізми керування даними, їх зберігання, терміни дії, власність та ідемпотентність.
Оновлення SDK та впровадження протоколу — це два окремі проекти. Поки існувала версія кандидата на випуск, адміністратори SDK закликали команди не поєднувати оновлення основної версії SDK із ввімкненням нового протоколу передачі даних, і ця порада залишається актуальною. Візьмемо SDK TypeScript v2: він розділяє єдиний пакет на окремі пакети для сервера та клієнта, постачається лише у форматі ESM, працює під Node.js 20+, Bun та Deno, перевіряється за допомогою бібліотек, сумісних із Standard Schema, та містить кодові зміни для типових оновлень від версії v1. Python v2 також є значною переробкою, зокрема через заміну назви FastMCP на MCPServer. TypeScript v1 буде отримувати виправлення та оновлення безпеки принаймні протягом шести місяців після виходу v2, а Python v1 все ще буде отримувати критичні виправлення та патчі безпеки. Обережний порядок робіт:
- Оновіть SDK, зберігаючи попередню поведінку протоколу там, де це підтримується.
- Виправте зміни API на рівні додатку.
- Додайте підтримку протоколів різних епох.
- Перевірте роботу з реальними клієнтами та трафіком.
- Поступово активуйте сучасну безстанову поведінку.
- Скасуйте підтримку застарілих версій лише після спостереження за їх використанням клієнтами.
Розширення розривають функціональність. Інструмент не може припускати, що Tasks чи MCP Apps існують скрізь, тому команди продуктів потребують матриць сумісності та альтернативних рішень користувацького інтерфейсу.
Повторні спроби стають проблемою коректності. Шляхи повторних спроб тепер виникають через MRTR, переговори щодо версії протоколу, втрату потоків відповідей HTTP, підвищення рівня автентифікації, опитування Tasks та поновлення підписок. Тому будь-яка операція з побічними ефектами потребує ретельного плану ідемпотентності.
OAuth краще інтегрується, але залишається складним у використанні. У специфікації OAuth 2.1 та документах з метаданими Client ID наведені проєкти стандартів, тому розробники змушені дотримуватися як змін MCP, так і основних стандартів.
Кешування породжує питання щодо конфіденційності. Якщо відповідь, яка залежить від авторизації, позначити як публічну, це може призвести до того, що каталог одного користувача чи абонента стане доступним для іншого. Краще використовувати приватний діапазон, якщо результат справді однаковий для всіх користувачів.
Загальна оцінка
MCP 2026-07-28 наближає протокол до принципів сучасного вебу: окремі запити, чіткі версії, звичайне маршрутизування HTTP, справжня семантика кешування, розподілений трекінг, стандартна авторизація та необов’язкові функції, які розвиваються окремо. Справжньою перевагою є відсутність прихованого стану протоколу, а не просто відсутність стану взагалі.
Масштабування, маршрутизація між зонами, відновлення після збоїв, налаштування політики шлюзу та моніторинг системи стають значно простішими. У відповідь з’являється стан робочої сесії, який раніше приховувався: обробники додатків, ідемпотентність, довговічні завдання, запасні варіанти розширень, метадані авторизації, конфіденційність кешів та правила повторних спроб.
Якщо ви керуєте існуючим сервером у продакшені, мігруйте поетапно та підтримуйте обидві версії. Розглядайте оновлення SDK та протокол зв’язку як окремі кроки, усувайте припущення щодо підключень, зберігайте довготривалі дані у спеціальних сховищах, тестуйте механізми авторизації та повторних спроб, і лише після перевірки реального використання клієнтами скасовуйте застарілу поведінку. Для абсолютно нового сервера все простіше: почніть з обробників запитів без стану та чіткого опису стану, використовуйте Streamable HTTP та сучасні механізми авторизації, додайте OpenTelemetry, зробіть кешування детермінованим та з самого початку плануйте можливості розширення.
Протокол тепер легше використовувати, проте лише для команд, які готові чітко описати стан свого додатку, межі безпеки та поведінку у разі збоїв.
Пов’язана література
- Практичні нотатки: MCP 2026: Протокол виріс – ось що таке промисловий ШІ — Детальний огляд Практичних нотаток: MCP 2026: Протокол виріс – ось що таке промисловий ШІ: контракти, перевірки та шаблони коду для команд, які використовують цю модель.
- Десять серверів MCP, які варто встановити першими, у порядку пріоритету для розробників — Список серверів MCP для асистентів з кодування на ШІ, від Context7 та GitHub до Postgres та інших інструментів, з налаштуваннями встановлення та рекомендаціями щодо прав доступу.