Данила (Dayfing)
Жарияланымдарға оралу
1 888 сөз8 мин

MCP 2026-07-28: күйсіз серверлер және қауіпсіз көшіру

2026 жылғы 28 шілдеде шыққан Model Context Protocol (MCP) нұсқасы қашықтағы MCP жүйелерінің жұмыс үлгісін өзгертті. Протоколдың өзегі енді күйсіз және дербес сұрауларға негізделеді. Әр сұрауда оны өңдеуге қажетті деректер бар, сондықтан жүктеме теңгергіші келесі шақыруды басқа сервер данасына жібере алады. Нұсқаға server/discover, Multi Round-Trip Requests (MRTR), міндетті маршруттау тақырыптары, кэш кеңестері, кеңейтімдер framework-і және күшейтілген авторизация ережелері қосылды. Бұл мақаладағы нормативтік мәліметтер ресми релиз хабарламасына және спецификация өзгерістерінің журналына сүйенеді.

Бұл протокол күйінің өзгеруі, бүкіл бизнес жүйесін күйсіз ету талабы емес. Құрал дерекқорды, кезекті немесе ұзақ өмір сүретін workflow-ды пайдалана алады. Жойылатын нәрсе — MCP тасымалдау сессиясына жасырын байланысқан күй. Бұл бір процестен бірнеше репликаға көшкенде маңызды.

2025 жылғы протоколмен салыстырғандағы өзгерістер

Бұрынғы өмірлік цикл initialize сұрауынан басталып, notifications/initialized хабарламасымен жалғасатын. Streamable HTTP сервері Mcp-Session-Id беріп, кейінгі хабарламаларды сол қосылыммен байланыстыра алатын. 2026-07-28 нұсқасы initialize алмасуын және протоколдық сессия тақырыбын алып тастады. Әр сұрау _meta ішінде протокол нұсқасы мен клиент мүмкіндіктерін көрсетеді. Клиент io.modelcontextprotocol/clientInfo жіберуі керек, ал сервер нәтиже метадеректерінде өз идентификациясын көрсетуі керек.

Көшіруді жоспарлауға мына кесте көмектеседі:

Сала 2025 жылғы мінез-құлық 2026-07-28 мінез-құлқы
Өмірлік цикл initialize және notifications/initialized Протокол handshake-і жоқ
Сессия HTTP-тағы міндетті емес Mcp-Session-Id Протокол деңгейіндегі сессия жоқ
Мүмкіндіктер Бір рет келісіледі Әр сұрауда жарияланады
Анықтау initialize-ден кейін немесе келісіммен Қазіргі сервер server/discover ұсынуы тиіс, клиент шақыруы міндетті емес
Серверден клиентке Ашық арнадағы сұраулар MRTR енгізу сұрауларын жауап ішінде қайтарады
HTTP маршруты Gateway көбіне JSON талдайды Mcp-Method және қажет болса Mcp-Name тақырыптары
Тізімдер мен оқу Жаңалықты клиент анықтайды ttlMs және cacheScope кеңестері
Жалғастыру SSE event ID қолдана алатын Last-Event-ID арқылы жалғастыру жоқ, жаңа сұрау керек
Тіркеу DCR жиі автоматты жол болатын CIMD ұсынылады, DCR үйлесімділік үшін қалады

Бұл нұсқа Tasks-ты io.modelcontextprotocol/tasks кеңейтіміне көшіреді, ескі өзгерістер арнасын subscriptions/listen арқылы алмастырады және Roots, Sampling, Logging мен ескі HTTP+SSE-ні ескірген деп белгілейді. Саясат кемінде он екі айлық мерзім береді, бірақ жаңа іске асырулар оларды қолданбауы тиіс.

Күйсіз протокол іс жүзінде нені білдіреді

Қазіргі Streamable HTTP сервері POST қабылдайтын бір MCP endpoint ұсынады. Клиент әр POST арқылы бір JSON-RPC сұрауын немесе хабарламасын жібереді. Жауап бір JSON нысаны немесе тек сол сұрауға тиесілі SSE ағыны болуы мүмкін. Сервер сессия идентификаторын жасамайды, ал үзілген ағынның жалғастырылатын оқиғалар тарихы жоқ. HTTP-та жауап ағынын жабу — тоқтату сигналы.

Тасымалдау тақырыптары мен денесі бір операцияны сипаттайды. Қарапайым құрал шақыруы:

POST /mcp HTTP/1.1
Accept: application/json, text/event-stream
Content-Type: application/json
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search

{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"search","arguments":{"q":"otters"},"_meta":{"io.modelcontextprotocol/protocolVersion":"2026-07-28","io.modelcontextprotocol/clientCapabilities":{},"io.modelcontextprotocol/clientInfo":{"name":"catalog-app","version":"1.0.0"}}}}

MCP-Protocol-Version тақырыбының мәні _meta мәнімен бірдей болуы керек. Қазіргі сервер жетіспейтін немесе сәйкес емес міндетті тақырыпты HTTP 400 және HeaderMismatch, -32020 кодымен қабылдамайды. Gateway өңдегеннен кейін сервер тақырыптарды қайта тексеруі керек. Осылайша прокси бір құрал атымен маршруттап, қолданба басқа құралды орындамайды.

Күйсіздік масштабтауды өзгертеді, бизнес мағынасын емес. Workflow жалғасуы керек болса, құралдан нақты handle қайтарып, келесі шақыруда оны талап етіңіз. Негізгі күйді дерекқорда немесе workflow қызметінде сақтаңыз, handle-ды пайдаланушы мен операцияға байланыстырып, жарамдылық мерзімін қойыңыз. Тексерілмеген handle, requestState немесе құрал аргументі рұқсаттың дәлелі емес.

server/discover және нұсқалар үйлесімділігі

Әр қазіргі сервер server/discover RPC-сін іске асыруы тиіс. Оның нәтижесі қолдайтын протокол нұсқалары мен мүмкіндіктерін, сондай-ақ қосымша нұсқауларды жариялайды. Клиент нұсқаны таңдау үшін оны бірінші шақыра алады немесе қазіргі сұрауды тікелей жібере алады. Сондықтан discovery пайдалы, бірақ клиент жағындағы міндетті handshake емес.

Сұралған нұсқа қолдау таппаса, сервер UnsupportedProtocolVersionError және қолдайтын нұсқалар тізімін қайтарады. Клиент ортақ нұсқаны таңдап, қайталайды. Екі дәуірді де қолдайтын клиент сынақ нәтижесін абайлап жіктеуі керек. Бос 400 немесе танылған қазіргі JSON-RPC қатесі жоқ 400 ескі endpoint-ті білдіруі мүмкін. Танылған қазіргі қате сұрауды түзетуді немесе қайта келісуді талап етеді. Авторизация және инфрақұрылым қателері сервердің ескі екенін дәлелдемейді.

Қазіргі SDK standard input қосылымын тексеріп, дәуірді сол қосылымға бекіте алады. Сервер жаңа клиенттер қазіргі сұрауларды қолданған кезде legacy бағытын сақтай алады. Дәуірді тек сәтті TCP қосылымынан немесе жалпы 404-тен анықтамаңыз.

MRTR сервердің клиентке сұрауларын алмастырады

Қазіргі wire форматы серверден клиентке жіберілетін JSON-RPC сұрау арнасын алып тастайды. Растау, жетіспейтін мән немесе модель көмегі қажет құрал ағынды ашық ұстамай, аралық нәтиже қайтарады. Нәтижеде resultType: "input_required" және inputRequests картасы болады. Клиент оларға жауап беріп, бастапқы әдісті inputResponses арқылы қайталайды. Қайталау — жаңа сұрау, сондықтан басқа репликаға түсуі мүмкін.

Растау ағыны былай көрінуі мүмкін:

{
  "resultType": "input_required",
  "inputRequests": {
    "confirm": {
      "type": "elicitation",
      "message": "Delete three files?",
      "schema": {"type": "boolean"}
    }
  },
  "requestState": "signed-opaque-state"
}

Клиент кейін inputResponses.confirm жіберіп, requestState мәнін байт бойынша дәл қайтарады. Сервер handler-ге жаңа сұрау сияқты қайта кіруі керек. Handler-ді idempotent жасаңыз, ағымдағы workflow қадамын тексерілген күйден шығарыңыз және тек әлі жоқ деректерді сұраңыз. Растау тексерілмейінше жойғыш әрекетті аяқталды деп белгілемеңіз.

requestState қауіпсіз контейнер емес. Ол клиент арқылы өтеді, сондықтан шабуылдаушы басқаратын енгізу ретінде қаралуы керек. Оны HMAC-пен қол қойыңыз немесе аутентификацияланған шифрлау қолданыңыз, principal-ге, бастапқы әдіске, маңызды параметрлерге және мерзімге байланыстырыңыз, ал өзгертілген күйді handler іске қосылғанға дейін қабылдамаңыз. Қолтаңба мазмұнды жасырмайды, сондықтан құпияларды сақтамаңыз. TypeScript SDK сұрау күйінің codec-ін және тексеру hook-ін береді. Оның legacy shim-і 2025 клиенттері қолдау кезеңінде сол input_required handler-ін ескі elicitation/create, sampling/createMessage және roots/list сұрауларына түрлендіре алады.

Ұзақ операциялар үшін Tasks кеңейтімін, тұрақты task handle-ды, tasks/get polling-ін және клиент енгізуі керек болғанда tasks/update әдісін қолданыңыз.

Кэш кеңестері және детерминдік каталогтар

tools/list, prompts/list, resources/list, resources/templates/list және resources/read нәтижелерінің қазіргі түрі ttlMs пен cacheScope өрістерін қамтиды. ttlMs — миллисекундпен берілген, HTTP max-age мәніне ұқсас, теріс емес жаңалық кеңесі. Нөл нәтиже бірден ескі екенін білдіреді. Ескі серверде өріс жоқ болса, оны нөл деп санаңыз. Оң мән клиентке қайта қашан сұрамауға болатынын айтады, бірақ деректердің мерзім біткенше өзгермейтініне кепілдік бермейді. TTL-ді үздіксіз polling-ке айналдырмай, дерек қажет болғанда жаңалығын тексеріңіз.

Кэш кілті әдісті және нәтижеге әсер ететін барлық параметрді қамтуы керек. Оған ресурс URI-і мен беттелген тізім cursor-ы да кіреді. inputResponses немесе requestState бар жауапты кэшке салмаңыз, себебі қарапайым тізім кілті оның контекстін қамтымайды. cacheScope: "public" түрлі авторизация контексттері арасында бөлісуге рұқсат етеді, сондықтан оны пайдаланушыға немесе рұқсатқа қатысты дерегі жоқ нәтиже үшін ғана қойыңыз. Каталог кэште тұрса да, әр құралдың рұқсаты тексерілуі тиіс.

Сервер құралдарды детерминдік ретпен қайтаруы керек. Тұрақты рет модель prompt-тарын тұрақтандырып, қайта қосылғаннан кейін кэшті қайта пайдалануды жақсартады. listChanged хабарламасы TTL-ді толықтыра алады, бірақ дұрыс кеңестің орнын баспайды.

OAuth және қауіпсіздік өзгерістері

MCP үшін авторизация жалпы алғанда міндетті емес. Ресурстарды қорғайтын HTTP сервері 2026 спецификациясындағы OAuth 2.1 профилін ұстануы керек. Ол resource server ретінде жұмыс істеп, RFC 9728 бойынша OAuth Protected Resource Metadata жариялауы тиіс. 401 жауабы WWW-Authenticate арқылы осы метадеректерге сілтеп, қажет болса scope challenge көрсетуі керек. Клиент тақырыптағы URL мен екі well-known форманы қолдауы тиіс.

Метадеректер бір немесе бірнеше authorization server көрсете алады. Клиент RFC 8414-тегі OAuth Authorization Server Metadata мен OpenID Connect Discovery-ді қолдауы керек. Жолдан тұратын issuer үшін алдымен жол кірістірілген формаларды, кейін жол қосылған OpenID формасын тексеріңіз.

Клиентті тіркеу енді Client ID Metadata Documents жолын ұсынады. Алдын ала тіркеу де жарамды. Dynamic Client Registration ескірген fallback болып қалды. DCR қолданылса, desktop немесе CLI клиентіне сәйкес application_type жіберіңіз. PKCE-ні тексеріп, S256 қолданыңыз, redirect URI-ді дәл тіркеңіз және рұқсат етілген localhost callback-тен басқа жерде HTTPS пайдаланыңыз.

Клиент тексерілген issuer-ді PKCE транзакциясымен бірге сақтауы керек. Авторизация жауабында iss болса, code айырбастамай тұрып салыстырыңыз. Credential оларды шығарған issuer-ге байланған, сондықтан басқа authorization server-де қайта пайдаланбаңыз. MCP серверінің канондық URI-ін RFC 8707 resource ретінде авторизация және token сұрауларына қосыңыз. Сервер audience-ті тексеріп, басқа ресурсқа берілген token-ді қабылдамауы керек.

Streamable HTTP үшін DNS rebinding-ті болдырмау мақсатында Origin тексеріңіз. Жергілікті сервер localhost-қа ғана байлануы керек. Bearer token-дерді query string-ге немесе log-тарға жазбаңыз, жеке ресурсты ашпас бұрын және құрал шақырмас бұрын пайдаланушы келісімін алыңыз, сенімсіз сервердің сипаттамалары мен annotation-дарын сенімсіз дерек деп санаңыз. 401 — авторизация жоқ немесе жарамсыз дегенді білдіреді. 403 — рұқсат жеткіліксіз, мүмкін болса insufficient_scope challenge болуы керек.

TypeScript SDK көшіруі

TypeScript SDK v2 client, server, core және runtime пакеттерін бөледі. 2026-07-28 қолдау туралы SDK нұсқаулығын және v1-ден v2-ге көшу нұсқаулығын оқыңыз. SDK-ні жаңарту өздігінен wire-ға қазіргі байттар түсетінін білдірмейді. v2 клиенті әдепкіде legacy келісімін қолданады, сондықтан versionNegotiation параметрін әдейі қосыңыз.

Екі дәуірмен жұмыс істейтін клиент үшін құжаттағы үлгі:

import { Client } from '@modelcontextprotocol/client';

const client = new Client(
  { name: 'catalog-app', version: '1.0.0' },
  { versionNegotiation: { mode: 'auto' } },
);
await client.connect(transport);

mode: 'auto' server/discover арқылы тексеріп, шынымен legacy peer болғанда ғана 2025 handshake-іне оралады. Fallback үйлесімсіздікті жасыратын болса, 2026-07-28 нұсқасын бекітіңіз. createMcpHandler(factory) әр қазіргі HTTP сұрауына жаңа сервер құрып, екі дәуірге де қызмет көрсете алады. stdio арқылы дәуірді таңдау үшін serveStdio(() => buildServer()) қолданыңыз.

v1 схемалық handler тіркеуін setRequestHandler('tools/call', handler) сияқты әдіс жолдарына ауыстырыңыз. ctx.sessionId оқитын кодты қолданбалық handle немесе тексерілген requestState арқылы жазыңыз. Push-style elicitation орнына inputRequired(...) қолданыңыз. io.modelcontextprotocol/logLevel жоқ қазіргі сұрау log хабарламасын жібермейді. SDK codemod-ы механикалық көмек қана, үйлесімділік сынағы емес.

Тексеру кезінде createMcpHandler-ді fetch негізіндегі тест тасымалы арқылы жүргізіп, legacy handshake үшін бөлек қамту қалдырыңыз. Нақты ескі және қазіргі клиенттермен тақырыптарды, _meta-ны, қайталау idempotency-сін, кэш ауқымын, audience-ті және HTTP күйін тексеріңіз.

Көшіру тізімі

  1. Клиенттерді, серверлерді, тасымалдарды, сессия қоймаларын, SSE event store-ларын және Mcp-Session-Id оқитын кодты түгендеңіз.
  2. Қазіргі трафикке арналған endpoint пен өтпелі кезеңде қалатын legacy маршрутты анықтаңыз.
  3. SDK-ні жаңартып, lockfile ішінде нақты пакет нұсқаларын бекітіңіз.
  4. server/discover және нұсқа келісу саясатын қосыңыз.
  5. Әр сұрауды өзін-өзі сипаттайтын етіп, _meta мен айналыстырылған тақырыптарды тексеріңіз.
  6. Сессияға байланған күйді handle-дарға немесе қол қойылған, мерзімі бар requestState-ке ауыстырыңыз.
  7. Сервер интеракциясын MRTR арқылы қайта жазып, қайталауды қауіпсіз етіңіз.
  8. Каталогтар мен ресурс нәтижелеріне ttlMs, cacheScope және детерминдік рет қосыңыз.
  9. Gateway, WAF, метрика және трассалауды Mcp-Method пен Mcp-Name үшін жаңартыңыз.
  10. Issuer, resource, audience, PKCE, redirect, Origin және scopes тексерулерін іске асырыңыз.
  11. Жаңа кодта HTTP+SSE, Roots, Sampling, Logging немесе DCR қоспаңыз.
  12. Observability бар ортада кезеңдеп шығарып, modern және legacy қателерін салыстырыңыз, тұтынушылар көшкен соң compatibility кодын алып тастаңыз.

Ақауларды жою

Белгі Ықтимал себеп Әрекет
HTTP 400 және -32020 Тақырып жоқ немесе денемен сәйкес емес Бір сұрау нысанынан MCP-Protocol-Version, Mcp-Method және Mcp-Name мәндерін қайта есептеңіз
HTTP 400 және нұсқа қатесі Peer керекті редакцияны қолдамайды supported ішінен нұсқа таңдаңыз немесе legacy жолын қолданыңыз
HTTP 404 және method-not-found Endpoint қазіргі, бірақ әдіс жоқ Әдіс пен кеңейтімді тексеріңіз, initialize-ді ойланбай жібермеңіз
Discovery кезінде HTTP 401 немесе 403 Авторизация probe-ты бөгеді Credential пен метадеректі түзетіңіз, бұл күй legacy екенін дәлелдемейді
Log хабарламалары жоқ io.modelcontextprotocol/logLevel берілмеген Әр сұрауда қосыңыз немесе stderr пен OpenTelemetry қолданыңыз
Қайталанған жанама әсерлер Ағынды енді жалғастыруға болмайды Idempotency key және жаңа сұрау ID қолданыңыз
Бір пайдаланушы дерегі басқа кэште көрінеді Нәтиже қате public белгіленген private қойып, principal тексеруін сақтаңыз
Ескі клиент GET үшін 405 алады Ол HTTP+SSE күтеді Legacy endpoint-ті уақытша қалдырыңыз

Архитектура контексті үшін production AI agent architecture және MCP server with TypeScript and OAuth материалдарын қараңыз.

Дереккөздер

Бұл материал MCP 2026-07-28 спецификациясына, өзгерістер мен ескірген мүмкіндіктер журналына, Streamable HTTP талаптарына, күйсіз MCP туралы SEP-2575-ке, 2026-07-28 релиз мақаласына, MCP авторизация спецификациясына және TypeScript SDK көшіру құжаттамасына сүйенеді.

Басқа жарияланымдар