Ключові висновки

Спека 2026-07-28 — інфраструктурний реліз, не косметика. Прибрали initialize/initialized і ідентифікатор сесії. Кожен запит самодостатній: версія протоколу, клієнт і можливості їдуть у _meta. Запит може потрапити на будь-який інстанс за звичайним round-robin.

Стан не зник — його зробили видимим для моделі. Якщо потрібен контекст між викликами, сервер видає handle (id задачі, знімок, чернетку), а агент передає його аргументом. Прихований стан у транспорті гірший: модель його не бачить і не може свідомо «протягнути» між tools.

Безпека — головний бар’єр масштабування. Shadow MCP (сервери в IDE без обліку IT) часто в рази ширший за очікування. Інструмент із записом у прод або доступом до секретів небезпечніший за «просто чат». Пісочниці й allowlist серверів — обов’язковий контур поруч із самим MCP.

Дизайн tools важливіший за кількість методів API. Вісім предметних інструментів зі зрозумілими режимами зазвичай надійніші за вісімдесят майже однакових обгорток. Це вже видно на практиці в розборах MCP для зовнішніх API.

Авторизація й спостережуваність — частина продукту. RFC 9207 (iss), відмова від DCR на користь Client ID Metadata Documents, заголовки Mcp-Method / Mcp-Name для шлюзів — без цього «продакшен» лишається демо на ноутбуці.

Що таке MCP і навіщо він команді розробки

MCP — відкритий протокол того, як LLM-агент виявляє й викликає tools, читає resources, використовує prompts і (у нових сценаріях) запитує підтвердження в людини. Клієнти — Cursor, Claude Desktop, VS Code, хмарні agent runtimes. Сервери — ваші обгортки над Git, тікетами, БД, внутрішніми API, CI.

До MCP кожна зв’язка «модель ↔ сервіс» була одноразовим конектором. Зміна вендора моделі ламала бібліотеку інтеграцій. Протокол виносить контракт назовні: один сервер обслуговує кілька клієнтів; один клієнт підключає багато серверів.

Чому тема вибухнула саме зараз

До липня 2026 екосистема виросла до промислового масштабу: сотні мільйонів завантажень SDK на місяць, тисячі публічних серверів, підтримка великих платформ. 28 липня вийшла специфікація 2026-07-28 із переходом на stateless protocol core — найпомітніший зсув від появи remote MCP.

Паралельно команди зіткнулися з «тіньовою» установкою серверів: розробник додав MCP у Cursor в п’ятницю, а security дізналася про це на інциденті. Це перетинається з темою пісочниць для агентного коду і з тим, що «локальна» модель не дорівнює приватності.

Як влаштований MCP: ролі та поверхня

Клієнт

Хост агента: тримає діалог із моделлю, підключає сервери, показує elicitations, застосовує політики (які сервери дозволені). Клієнт вирішує, які tools потраплять у контекст моделі.

Сервер

Процес або HTTP-endpoint, який оголошує capabilities і виконує виклики. У 2026 remote MCP поверх Streamable HTTP — норма для прода; локальний stdio лишається зручним для розробки й персональних інструментів.

Tools, resources, prompts

Tools — дії з побічними ефектами або обчисленнями (створити тікет, прогнати запит, переобхід URL).
Resources — сутності для читання (файл, схема, звіт).
Prompts — шаблони, які сервер пропонує клієнту.

Для агента критичний каталог: назви, описи, схеми аргументів. Погані описи → хибний tool. Занадто багато схожих tools → плутанина. Хороший сервер групує API навколо задач користувача, а не навколо OpenAPI paths.

Спека 2026-07-28: що реально змінюється

Офіційний анонс підкреслює: ядро стало request/response без прив’язки до сесії на конкретному інстансі.

Немає handshake і Mcp-Session-Id

Раніше клієнт і сервер обмінювалися initialize / initialized, далі жила сесія. Тепер кожен запит несе потрібний контекст сам. Опційний server/discover дозволяє дізнатися capabilities заздалегідь — але він не обов’язковий перед першим tools/call.

Це прямо впливає на деплой: можна крутити MCP за load balancer без sticky sessions і без shared session store на рівні протоколу.

Стан застосунку через handles

Якщо tool створює довгу операцію або чернетку, сервер повертає ідентифікатор. Наступний виклик приймає цей id в arguments. Модель бачить handle в історії й може передати його далі — на відміну від невидимого session bag на сервері.

Multi Round-Trip Requests (MRTR)

Раніше server-initiated elicitation/sampling вимагали тримати двонаправлений потік. MRTR дозволяє серверу відповісти input_required, клієнт збирає відповіді людини (або іншої підсистеми) і повторює вихідний виклик з inputResponses. Типовий кейс: «підтвердіть видалення» або «вкажіть проєкт перед дорогою дією».

Маршрутизація за заголовками

Запити Streamable HTTP зобов’язані нести Mcp-Method і Mcp-Name. Шлюз, WAF і rate limiter можуть різати або враховувати квоти за назвою інструмента, не розбираючи JSON body. Для ops це різниця між «чорною скринькою POST /mcp» і нормальним HTTP-сервісом.

Кеш списків

Відповіді tools/list, prompts/list, resources/list і частина resources/read несуть підказки ttlMs і cacheScope. Клієнти рідше смикають каталог; стабільний порядок списку допомагає prompt cache не «тремтіти» на кожному reconnect.

Авторизація

Посилюють перевірку iss (RFC 9207), прив’язку credentials до issuer, поступовий відхід від Dynamic Client Registration до Client ID Metadata Documents (CIMD). DCR ще живий для сумісності, але нові реалізації мають планувати CIMD.

Tasks і розширення

Довгі задачі оформлюють розширенням Tasks (poll через tasks/get, оновлення через tasks/update), а не «вічною» сесією. Roots, Sampling і Logging позначені deprecated із мінімум дванадцятимісячним вікном — не будувати на них нові продукти.

Як писати MCP-сервер, який доживе до прода

Почніть із питань користувача, не з OpenAPI

Випишіть 5–15 питань, які агент має закривати («які URL з помилками індексації», «створи чернетку PR», «покажи повільні запити»). Кожне питання — кандидат у tool або режим одного tool. Ідентифікатори, які не можна вгадати з URL, віддавайте окремим «discover»-кроком.

Робіть результати компактними й пояснюваними

Моделі погано перетравлюють сирий dump на 50 КБ. Сортування, фільтрація застарілого, зведені лічильники, явний next step при помилці — частина контракту. Розрізняйте 401 (потрібен новий вхід) і 403 (немає прав на об’єкт): інакше агент крутить OAuth марно.

Явні побічні ефекти

Tool, який пише дані, має бути названий як дія (submit_, delete_, create_), а не як нейтральний get_. Для руйнівних операцій закладайте MRTR/elicitation.

Версії та сумісність

Міняйте схему аргументів обережно. Додавання optional-полів безпечніше за перейменування. Документуйте MCP-Protocol-Version, які ви підтримуєте; тестуйте клієнтів на 2026-07-28 і на попередній лінії, поки парк IDE не оновиться.

Стек

TypeScript SDK лишається найчастішим вибором для веб-команд; Python, Go і C# закриті на Tier 1 для нової спеки. Для serverless (Workers і аналоги) stateless-ядро якраз знімає головне операційне гальмо.

Міграція з сесійної моделі

План без героїзму:

1. Інвентаризація: де код читає session id або кладе міжвикликовий стан у пам’ять процесу.
2. Для кожного шматка стану — явний handle (БД, Redis, object storage) + аргумент tool.
3. Увімкнути/оновити SDK під 2026-07-28; прогнати tools/list і критичні tools/call за балансувальником із двома інстансами.
4. Перевірити elicitations через MRTR, якщо використовували server-push.
5. Оновити шлюз: правила за Mcp-Method / Mcp-Name.
6. Зафіксувати deprecation: не використовувати Roots/Sampling/Logging у нових фічах.

Змішані версії клієнтів і серверів у серпні–вересні 2026 — очікуване джерело інцидентів. Має сенс canary і явний pin версії протоколу в корпоративному образі клієнта, якщо політика це дозволяє.

Безпека та governance: shadow MCP

Shadow MCP — сервери, які розробники підключили локально (або в особистій хмарі), минаючи каталог компанії. За оцінками індустрії розрив між «що думає security» і «що реально в IDE» часто кратний.

Практичний мінімум для команди:

• Allowlist серверів у керованому конфігу IDE / agent gateway.
• Заборона довільних remote URL без review.
• Секрети лише через корпоративний vault / short-lived tokens, не в arguments назавжди.
• Логи викликів із редакцією чутливих полів.
• Пісочниця для tools, які запускають код або шелл — див. контур Docker Sandboxes.
• Поділ read-only і write tools; write — за підтвердженням.

Prompt injection через вміст resource/tool result лишається реальною загрозою: сервер має вважати зовнішні тексти ненадійними даними, а не інструкціями.

Спостережуваність і експлуатація

Без метрик MCP у проді — чорна скринька. Мінімальний набір:

• RPS і помилки за Mcp-Name.
• Latency p50/p95 за tool.
• Частка input_required і відмов користувача на elicitation.
• Розмір відповідей (байт) — захист від випадкового dump.
• Версії протоколу клієнтів.
• Аудит: хто (суб’єкт OAuth) викликав який tool із яким handle.

Трейсинг (OpenTelemetry) зручно вішати на межу gateway → server → downstream API. Назва tool — чудовий span attribute.

Порівняння: MCP, function calling і «просто OpenAPI»

MCP не скасовує OpenAPI: часто MCP-сервер — кураторський фасад над вашим API. OpenAPI лишається контрактом для сервісів; MCP — контрактом для агентів.

Типові помилки

Скопіювали весь REST один-в-один у tools. Модель тоне в синонімах.
Сховали критичний стан у пам’яті процесу. Після переходу на stateless і двох реплік «втратили» чернетки.
Дають write-tools без підтвердження. Один хибний виклик — інцидент.
Логують arguments як є. Витікають токени й PII.
Ігнорують версію протоколу. Клієнт оновився — сервер мовчки деградував.
Вважають localhost безпечним за замовчуванням. Локальний сервер із небезпечним tool і спільним ноутбуком — усе ще поверхня атаки.

Практичний чекліст запуску

1. Один сервер, 5–10 tools навколо реальних задач команди.
2. Read-only спочатку; write за MRTR.
3. OAuth / CIMD-план, перевірка iss.
4. Деплой ≥2 інстансів без sticky.
5. Метрики за Mcp-Name, алерти на 5xx і аномальний розмір відповіді.
6. Allowlist у клієнтах розробників.
7. Runbook міграції на 2026-07-28.
8. Зв’язка з пісочницею, якщо tool виконує код.

Сценарії з практики

Агент супроводжує реліз

Сервер віддає tools: статус пайплайну, diff критичних файлів, створення чернетки release notes, виклик rollback лише через elicitation. Без MCP той самий сценарій зазвичай живе як набір скриптів у CI плюс ручний чат. З MCP тімлід в IDE питає «чому червоний deploy» і отримує структуровану відповідь tool, а не простирадло логів.

Підтримка та внутрішні дані

Read-only tools до CRM або бази знань знижують ризик, якщо агент допомагає L2. Write-tools (зміна статусу тікета, коментар клієнту) краще тримати за підтвердженням і з аудитом суб’єкта. Тут знову важливий компактний результат: агенту потрібні «відкриті тікети клієнта X з SLA < 4 год», а не повний JSON сутності.

Платформна команда як власник каталогу

У зрілій моделі MCP-сервери — продукти платформи, а не особисті експерименти. Платформа публікує каталог, SLA, версії протоколу й канал breaking changes. Розробники підключають сервери як залежності, а не як «ще один URL із твіта».

Шлюз і enterprise-контур

Між IDE й origin-серверами майже завжди потрібен gateway: єдина точка OAuth, allowlist, rate limit, редакція логів, маршрутизація за Mcp-Name. Шлюз же зручно вішає canary: частину трафіку на нову версію сервера. Без нього кожен сервер знову винаходить auth і ви отримуєте зоопарк винятків у security review.

Має сенс розділити edge policy (хто взагалі може викликати MCP) і tool policy (які назви tools доступні ролі). Роль «стажер» може мати лише read-каталог; роль «on-call» — write з elicitation. Це простіше виразити на шлюзі, ніж сподіватися, що кожна IDE правильно локально відфільтрує tools.

Як тестувати сервер без повної IDE

Повний цикл «відкрив Cursor → поговорив із моделлю» дорогий для регресій. Тримайте контрактні тести:

• tools/list стабільний за назвами й обов’язковими полями схеми;
• golden-тести на arguments → downstream HTTP (мок);
• два інстанси за nginx/caddy без sticky: той самий handle читається з обох;
• сценарій MRTR: перша відповідь input_required, друга — успіх після inputResponses;
• негативні: прострочений токен, 403 на чужий ресурс, занадто велика відповідь обрізається.

Окремо ганяйте описи tools через чекліст для людей: незнайомий розробник за одним description розуміє, коли викликати tool. Якщо ні — модель теж не зрозуміє.

Часті питання

Чи потрібен MCP, якщо в нас уже є внутрішній API?

Так, якщо агенти мають викликати цей API з різних IDE і рантаймів без окремого конектора на кожного вендора. Ні, якщо агентів немає і інтеграції лише service-to-service.

Чи обов’язковий перехід на 2026-07-28 прямо зараз?

Для нових серверів — так, орієнтуйтеся на актуальну спеку. Для наявних — сплануйте міграцію до масового оновлення клієнтів; вікно сумісності не нескінченне.

Чим MRTR кращий за старий elicitation по стріму?

Не потрібно тримати двонаправлений потік і sticky-сесію. Підтвердження людини вбудовується в повтор того самого виклику — простіше масштабувати й налагоджувати.

Чи можна лишати стан у Redis і вважати сервер stateless?

Так: протокол stateless, застосунок — ні. Головне, щоб ключ стану був явним handle в arguments, а не «магією» session id на балансувальнику.

Як обмежити ризик shadow MCP?

Корпоративний каталог серверів, allowlist в IDE, заборона невідомих remote endpoints, аудит конфігів робочих станцій, навчання: «новий MCP = зміна інфраструктури».

TypeScript чи Python для сервера?

Беріть мову команди супроводу. TypeScript зручний поруч із веб/Node-стеком; Python — поруч із data/ML. Обидва Tier 1 SDK закривають 2026-07-28.

Що робити з deprecated Roots і Sampling?

Не використовувати в нових продуктах. Для поточного коду — план заміни в межах оголошеного 12-місячного вікна й стежити за changelog SDK.

Чи замінює MCP RAG?

Ні. RAG відповідає за витягнення знань; MCP — за дії й доступ до систем. Часто працюють разом: retrieval як tool/resource, запис у тікети — як окремий tool.

Подальше читання

• Як ІІ-агент отримує доступ до API через MCP — приклад курації tools над зовнішнім API
• Безпека пісочниці для агентного ІІ
• Локальний ІІ не завжди означає приватність
• Корпоративна AI-платформа
• Архітектура enterprise RAG
• SEO / AEO / GEO готовність до AI-пошуку

Зовнішні першоджерела: анонс специфікації 2026-07-28, документація MCP і migration notes Tier 1 SDK.

Що зробити цього тижня

Якщо тема для вас нова, не починайте з «напишемо свій Cursor-плагін». Візьміть один внутрішній API, про який агенти вже питають вручну, і обгорніть у 5–7 tools із read-only доступом. Підніміть два інстанси без sticky, повісьте метрики за Mcp-Name, додайте сервер в allowlist команди. Паралельно складіть список write-tools, які не можна віддавати без MRTR. За тиждень у вас буде не слайд про MCP, а робочий контур і список дірок для наступного спринту.

Для вже наявних серверів тиждень іде на інвентаризацію session-стану й пілот 2026-07-28 на одному некритичному сервісі. Документуйте handles і breaking changes так само, як для публічного HTTP API: changelog, версія протоколу, контакт власника.

Висновок

MCP у 2026 — це вже не експеримент «підключимо файлову систему до чату». Stateless-ядро, MRTR, заголовки для шлюзів і жорсткіша авторизація перетворюють протокол на звичайну (і тому більш вимогливу) частину платформи. Виграють команди, які проєктують маленький зрозумілий каталог tools, явно переносять стан у handles, ставлять governance проти shadow MCP і готують міграцію спеки так само серйозно, як міграцію API. Іншим ринок усе одно нав’яже оновлення клієнтів — краще зустріти його з runbook, а не з інцидентом у п’ятницю.