Maelekezo mapya ya MCP ya 2026-07-28 yanaondoa hitaji lolote la hali ya kikao (session-state), na kuruhusu kila ombi kubeba data zote zinazohitajika. Mabadiliko haya kwenda kwenye itifaki isiyo na hali (stateless protocol) yanamaanisha kuwa watengenezaji wanaweza kuanzisha nakala moja (single instance) kwa kila wito, kuendesha kwenye serverless au edge nodes, na kuondoa mifumo ya zamani ya "sticky-routing" na "shared-store" ambayo imekuwa kikwazo katika utekelezaji.

Kutoka Mikataba ya Utambulisho (Handshakes) hadi Wito Unaojitegemea

Mpaka sasa, Model Context Protocol (MCP) ililazimisha mchakato wa utambulisho (handshake) uliotoa kitambulisho cha kikao (session ID). Seva zilipaswa kukumbuka kitambulisho hicho kwa muda wote wa muunganisho, jambo ambalo kwa vitendo lilimaanisha kuweka michakato hai, kunakili hali (state) kwenye kundi la Redis, au kusanidi balansi za mzigo (load balancers) kwa ajili ya "sticky" routing. Matokeo yake yalikuwa ni mfumo tata na wenye matumizi makubwa ya rasilimali uliodhoofisha uwezo wa kutanuka (scaling) na kufanya ukuaji wa mlalo (horizontal growth) kuwa ghali.

Maelekezo mapya yanayafanya kila ombi kuwa unajitegemea. Kila pakiti ya data (payload) inajumuisha toleo la itifaki na utambulisho wa mwombaji, hivyo seva inaweza kuchukulia ombi hilo kama muamala wa mara moja. Hakuna hifadhi ya kikao (session store), hakuna mchakato unaodumu kwa muda mrefu, na hakuna sheria maalum za uelekezaji (routing).

Kwa Nini Hali Isiyo na Kikao (Stateless) ni Muhimu kwa Utekelezaji

  • Tayari kwa serverless na edge – Ombi hubeba kila kitu kinachohitajika, hivyo kazi (function) inaweza kuanza, kujibu, na kufunga bila kuhitaji hali ya awali (warm-up state). Watoa huduma wanaotoza kwa kila wito wanakuwa wenye tija kwa kazi za MCP.
  • Urahisi wa usawazishaji wa mzigo (load balancing) – Balansi za kawaida za L4/L7 zinaweza kusambaza trafiki kwa usawa; hakuna haja ya kumfungia mteja kwenye seva ya nyuma (backend) fulani.
  • Kupunguza gharama za uendeshaji – Timu zinaweza kuondoa makundi ya Redis au kodi maalum za kunakili hali (session-replication), hivyo kupunguza gharama na uwezekano wa hitilafu.

Kwa mashirika ambayo tayari yanatumia MCP nyuma ya balansi ya mzigo, mabadiliko haya yanaondoa haja ya sheria za "sticky" ambazo mara nyingi husababisha usambazaji usio sawa wa trafiki. Akiba hii ni kubwa hasa kwa huduma zenye kasi kubwa zinazopokea mamilioni ya wito kwa siku.

Maboresho ya Utendaji na Usalama

Maelekezo haya yanaongeza maboresho madhubuti yanayofanya itifaki kuwa imara zaidi zaidi ya hali yake ya kutokuwa na kikao:

  • Kumbukumbu (caching) inayotegemea TTL – Orodha za zana (tools) na maelekezo (prompts) sasa zinajumuisha uwanja wa muda wa kuishi (time-to-live), ikiruhusu wateja kuhifadhi matokeo ndani yao na kuepuka safari zisizo za lazima za mtandao.
  • Uelekezaji unaoendeshwa na vichwa vya habari (headers) – Vichwa vipya vya HTTP vinaonyesha taarifa za uelekezaji mapema, hivyo milango ya kiunganishi (gateways) inaweza kusogeza trafiki bila kuhitaji kusoma mwili mzima wa JSON, jambo linalopunguza ucheleweshaji (latency).
  • Uimarishaji wa OAuth/OIDC – Tokeni za utambulisho hupitia ukaguzi mkali zaidi wa OAuth na OpenID Connect, ikipunguza hatari ya mashambulizi ya kurudia (replay) na wizi wa tokeni.
  • Mfumo rasmi wa nyongeza (extensions) – Kazi (Tasks) na Programu (Apps) sasa ni sehemu ya mfumo wa nyongeza uliowekwa, jambo linalofanya utoaji wa vipengele vipya kuwa rahisi kwa watunza SDK.

Athari kwa Watengenezaji

Mfumo wa SDK tayari unaonyesha mabadiliko haya: maktaba za TypeScript, Python, Go, na C# zinatoa mfumo mpya wa ombi. Pakia za pamoja za SDK hizi zinakaribia nusu bilioni kwa mwezi, mara nne zaidi kuliko mwanzoni mwa mwaka, jambo linaloonyesha jinsi MCP inavyokubalika kwa upana.

Watengenezaji lazima warekebishe kodi yoyote iliyodhani kuwa kuna kikao kinachodumu (persistent session). Kwa kawaida, hiyo inamaanisha kuhamisha data maalum za kikao kwenye pakiti ya ombi (request payload) au kwenye hifadhi ya nje inayotumiwa kwa kila wito. Dirisha la uhamiaji ni miezi kumi na miwili, ikitoa muda kwa timu kufanya marekebisho (refactor), kufanya majaribio, na kuanzisha mfumo mpya.

Upande wa Pili: Ugumu wa Uhamiaji

Hali isiyo na kikao (statelessness) haina gharama yake. Programu ambazo hapo awali zilitegemea hali ya upande wa seva (server-side state) kwa mambo kama historia ya mazungumzo yanayopiga hatua sasa zinapaswa kusimamia hali hiyo upande wa mteja (client-side) au kupitia tabaka tofauti la kuhifadhi data.

Mambo ya Kufuatilia

  • Vipimo vya upokeaji – Fuatilia ongezeko la matoleo ya SDK; kupungua kwa kasi kunaweza kuashiria ugumu wa uhamiaji.
  • Usaidizi wa majukwaa ya edge – Kadiri watoa huduma wengi wanavyotangaza mifumo inayozingatia MCP, faida halisi ya gharama ya serverless itakuwa wazi zaidi.
  • Ripoti za matukio ya usalama – Mtiririko uliimarishwa wa OAuth/OIDC unapaswa kupunguza mashambulizi ya utambulisho, lakini uvunjifu wowote utajaribu ulinzi mpya.

Muhtasari: Kwa kufanya MCP iwe stateless, maelekezo haya yanaoanisha itifaki na mifumo ya kisasa ya cloud-native, ikipunguza mzigo wa uendeshaji wa usimamizi wa vikao huku ikifungua mlango wa mifumo ya utekelezaji ya bei nafuu na inayoweza kutanuka kwa urahisi. Unyumbufu (trade-off) ni kipindi kifupi cha marekebisho ya kodi na ukubwa wa pakiti za maombi, lakini faida ya muda mrefu ni itifaki inayoweza kutanuka kwa urahisi kama miundombinu inayoiendesha.