Toleo la MCP 2 litaanza kutumika Julai 28, 2026. Linaondoa kila handshake, kichwa cha habari cha session-ID (session-ID header), na mifumo mitatu ya zamani (legacy subsystems) iliyounganisha Model Context Protocol (MCP) na seva za sticky-session. Itifaki itakuwa isiyo na hali (stateless) kabisa, hivyo kila instance inayojiongeza (autoscaled) au isiyo na seva (serverless) inaweza kushughulikia ombi lolote bila kuhifadhi hali ya mteja (client state).

Kwa nini mabadiliko haya ni muhimu

MCP v1 ilimlazimu mteja kuanza kikao (session) kwa handshake ya initialize; kisha seva ilitenga Mcp-Session-Id. Kila wito wa baadaye ulihitaji kubeba kichwa hicho, jambo lililomfunga mtumiaji kwenye node moja ya nyuma (backend node). Vibaunzi vya mizigo (load balancers) vililazimika kusimamia ukaribu wa kikao (session affinity), hali iliyoongeza ucheleweshaji (latency) na vikwazo vya kiutendaji.

Hali ya kutokuwa na hali (statelessness) inaondoa vikwazo hivyo. Muktadha (context) wote sasa upo kwenye nyanja maalum za meta (meta fields) ambazo husafiri pamoja na kila wito wa HTTP. Ombi linaweza kuingia kwenye instance yoyote, lishughulikiwe, na instance hiyo inaweza kufutwa mara tu jibu linapotumwa. Timu zinazotumia mifumo ya serverless, makundi ya container-orchestrated, au mazingira yoyote yanayozalisha na kuondoa pods kulingana na mahitaji, sasa zinaweza kuoanisha itifaki hiyo na miundombinu yao.

Vitu vinavyofutwa

Mifumo mitatu iliyotegemea miunganisho endelevu (persistent connections) imetangazwa rasmi kuwa haitatumika tena (deprecated):

  • Sampling – Katika v1, seva ingeweza kumwomba mteja kutengeneza maandishi, mfumo ambao ulihitaji kikao kilichofunguliwa. v2 inatarajia seva iite mtoa huduma wa large-language-model moja kwa moja au itumie mfumo wa InputRequiredResult, ambapo mteja hutoa ingizo linalokosekana katika ombi la ufuatiliaji.
  • Roots – Hapo awali, wateja walituma URIs ambazo zilizuia mtazamo wa seva kuhusu rasilimali za nje. Njia mpya inapitisha URIs hizo kama vigezo vya zana (tool parameters) au kuzijumuisha katika nyanja za rasilimali za ombi, ikiondoa hatua ya pekee ya mazungumzo ya “roots”.
  • Logging – Vichwa vya habari vya uandishi wa kumbukumbu (logging headers) katika kiwango cha itifaki vinaondoka. Andika kwenye stderr kwa ajili ya urekebishaji wa ndani (local debugging) au tumia OpenTelemetry kwa ajili ya uwezo wa kuona mambo yanayoendelea (observability) kwenye uzalishaji.

Kipindi cha kuondoa vitu hivi kitachukua mwaka mmoja. Vipengele vilivyofutwa (deprecated) vitaendelea kufanya kazi kwa kipindi hicho, vikiwapa timu muda wa kufanya marekebisho (refactor) kabla ya itifaki kuvikataa.

Ni nini kipya zaidi ya kutokuwa na hali (statelessness)

MCP v2 inaongeza vipengele viwili rasmi (extensions):

  • MCP Apps – Njia nyepesi ya kuelezea miongozo ya watumiaji (user interfaces) inayotolewa na seva ambayo itifaki inaweza kuiita.
  • Tasks – Mfumo wa kushughulikia operesheni zinazoendelea kwa muda mrefu ambazo zinaweza kuvuka mizunguko mingi ya ombi-jibu (request-response cycles).

Vipengele vyote viwili vinategemea mfumo wa ombi usio na hali (stateless request model) na huepuka hali ya siri ya kikao (hidden session state).

Hatari na hoja za kinyume

Mabadiliko haya si maboresho ya "plug-and-play". SDK za v2 bado zipo katika hatua ya beta, na API zake za umma zinaweza kubadilika kabla ya toleo thabiti kufika. Kwa kazi za uzalishaji (production workloads) ambazo haziwezi kuvumilia mabadiliko makubwa (breaking changes), endelea kutumia SDK thabiti ya v1 hadi SDK ya v2 itakapokomaa.

Watengenezaji pia wanahitaji kukagua kodi zilizopo kwa ajili ya mifumo yoyote mitatu iliyofutwa.

Mpango wa uhalisia wa uhamiaji (migration roadmap)

  1. Kagua leo – Chunguza huduma zako kwa matumizi ya handshake, Mcp-Session-Id, wito wa sampling, URIs za roots, na uandishi wa kumbukumbu katika kiwango cha itifaki. Tambua kodi ambayo itaharibika chini ya mfumo usio na hali (stateless model).
  2. Jaribu kwenye node isiyo ya muhimu – Wakati SDK thabiti ya v2 itakapozinduliwa, fungua seva ya sandbox, iunganishe na mteja wa majaribio, na uhakikishe kuwa nyanja zote muhimu za meta zipo na zinafafanuliwa kwa usahihi.
  3. Uhamiaji kamili kabla ya muda uliopangwa – Kamilisha mabadiliko kwenye node zote za uzalishaji kabla ya kipindi cha mwaka mmoja cha uvumilivu kuisha ili kuepuka kukataliwa wakati wa utendaji (runtime rejections).

Nini cha kufuatilia baadaye

  • Utoaji wa SDK thabiti – SDK za beta zitafungwa na kifurushi thabiti chenye toleo kitachapishwa. Toleo hilo litakuwa lengo salama kwa ajili ya utumiaji wowote muhimu.

Mpito huo utahitaji mabadiliko ya kodi na kipindi kifupi cha majaribio ya beta-SDK, lakini faida yake ni kiunganishi safi zaidi na kinachoweza kupanuliwa zaidi kwa ajili ya programu yoyote inayotegemea LLM.

Muhtasari: Ikiwa mfumo wako bado unategemea handshake za MCP au mifumo mitatu iliyofutwa, anza ukaguzi sasa; mwaka mmoja wa uvumilivu ni mwingi, lakini gharama halisi ni juhudi za marekebisho (refactor), siyo muda wa mwisho.