MCP 2026-07-28: що мають змінити розробники серверів
Специфікація MCP від 2026-07-28 прибирає сесії та handshake initialize і додає server/discover. Розповідаємо, що змінилося для розробників серверів.
Model Context Protocol опублікував свою редакцію 2026-07-28 як стабільний реліз 28 липня 2026 року. Головна зміна: сесій більше немає, і handshake initialize теж прибрано. Тепер кожен запит існує сам по собі. Якщо ви підтримуєте сервер або клієнт MCP, закладіть час на тестування з цією версією.
Цей огляд спирається на офіційний журнал змін у репозиторії специфікації, який перелічує зміни з редакції 2025-11-25. Прочитайте повний текст, перш ніж міняти код.
Що змінилося в протоколі?
- Сесій немає. Streamable HTTP більше не має протокольних сесій і заголовка
Mcp-Session-Id. Сервер, якому потрібен стан між викликами, сам видає дескриптор, а клієнт передає його як звичайний аргумент інструмента. - Немає handshake. Обмін
initializeприбрано. Кожен запит несе версію протоколу та можливості клієнта в_meta, а невідповідність версій повертаєUnsupportedProtocolVersionError. server/discover. Новий виклик, який сервери мають реалізувати. Він оголошує підтримувані версії, можливості та ідентичність.subscriptions/listen. Один довгий потік відповіді тепер несе повідомлення про зміни. Він замінив старий GET-endpoint і виклики subscribe та unsubscribe.- Видалені виклики.
ping,logging/setLevelіnotifications/roots/list_changedприбрано. Рівень логування тепер передається в кожному запиті. - Resumable SSE зник. Якщо потік обривається, клієнт повторює запит з новим ID.
Що застаріло?
Roots, Sampling і Logging працюють протягом вікна застарівання, але журнал змін каже, що нові реалізації не повинні їх додавати. Старий транспорт HTTP+SSE застарів на користь Streamable HTTP. OAuth Dynamic Client Registration застаріла як метод реєстрації на користь Client ID Metadata Documents. Нова політика життєвого циклу функцій встановлює мінімальне вікно застарівання у дванадцять місяців.
Що ще варто перевірити?
- Tasks перенесли з ядра в розширення, з опитуванням через
tasks/getзамість блокування до результату. - Запити від сервера, як-от sampling і elicitation, тепер ідуть за схемою з кількома раундами: сервер повертає результат
input_required, а клієнт повторює запит зі своїми відповідями. - Кожен результат потребує
resultType, це"complete"або"input_required". Клієнти мають вважати старіші сервери, які його не містять, завершеними. - Підказки для кешу (
ttlMsіcacheScope) обов'язкові в результатах list і read. - POST-запити Streamable HTTP мають містити заголовки
Mcp-MethodіMcp-Name. - Коди помилок змінилися. Ресурс не знайдено тепер має код
-32602, а кілька кодів MCP перенумеровано в діапазон від -32020 до -32099.
Що зробити цього тижня?
- Прочитайте журнал змін від початку до кінця і складіть список пунктів, які стосуються вашого сервера.
- Якщо ви зберігаєте щось на рівні сесії, перепроєктуйте це навколо дескрипторів, що передаються як аргументи.
- Додайте
server/discoverі протестуйте узгодження версій із клієнтом на старій редакції. - Припиніть додавати Roots, Sampling чи Logging до нової роботи.
- Тримайте стару редакцію працюючою, доки ваші клієнти не перейдуть.
Якщо ви обираєте, як розгорнути моделі, які викликають ваші агенти, перегляньте наш посібник із запуску локального сервера LLM і загляньте в хаб AI Agents & Infrastructure. Який з ваших серверів сьогодні зберігає стан у сесії?
