MCP servers: mabadiliko ya stateless kuanzia 2026-07-28

Seva ya MCP isiyo na hali (stateless) ni nini

Seva ya MCP isiyo na hali haihifadhi hali yoyote ya mteja (per-client state) kati ya maombi. Kila ombi hubeba toleo la itifaki, uwezo wa mteja, na vitambulisho ambavyo seva inahitaji ili kujibu ombi hilo, kwa hivyo mchakato wowote kwenye mashine yoyote unaweza kujibu ombi lolote. MCP (Model Context Protocol, muundo wa mawasiliano unaotumiwa na mawakala kufikia zana) iliweka hili kama sheria katika marekebisho 2026-07-28, ambayo iliondoa handshake ya initialize na kipindi cha HTTP (HTTP session) kilichokuwa chini yake.

Hiyo ndiyo hoja nzima ya kiutendaji. Seva ambayo haihifadhi chochote kwa kila mteja inaweza kukaa nyuma ya load balancer ya kawaida bila kuhitaji session affinity, inaweza kuanzishwa upya wakati wa deploy bila kukatiza wateja, na inaweza kuendeshwa kama michakato minne inayofanana badala ya mmoja. Seva inayotegemea session haiwezi kufanya mambo hayo bila vifaa vya ziada.

Model Context Protocol ni itifaki isiyo na hali: taarifa zote zinazohitajika ili kuchakata ombi zimo ndani ya ombi lenyewe. Seva huchakata kila ombi kwa kujitegemea; hakuna hali inayopaswa kudhaniwa kutoka kwa maombi ya awali, hata yale yaliyo kwenye muunganisho au mtiririko (stream) uleule.

Kutokuwa na hali (stateless) hakumaanishi kuwa seva yako haihifadhi chochote. Database yako, foleni (queue) yako, na cache yako bado vipo. Inamaanisha kuwa itifaki haibebi hali yoyote kwenye muunganisho, kwa hivyo seva haipaswi kuchukulia muunganisho, mchakato, au socket iliyo wazi kama mwakilishi wa "mteja huyu, katikati ya mazungumzo".

Mabadiliko yaliyofanywa katika toleo la 2026-07-28

2026-07-28 ndilo toleo la sasa la vipimo hivi kuanzia Agosti 2026. Ikilinganishwa na 2025-11-25, toleo hili linaondoa vipengele vitano vilivyokuwepo awali kwa ajili ya kusaidia vikao (sessions).

• Ombi la initialize na taarifa ya notifications/initialized. Hakuna tena mchakato wa handshake (SEP-2575).
• Kichwa cha habari (header) cha Mcp-Session-Id, na usitishaji wa kikao kupitia HTTP DELETE (SEP-2567).
• Mtiririko (stream) wa HTTP GET uliokuwa ukisimama pekee ambao seva ilikuwa ikitumia kusukuma taarifa. Sasa umebadilishwa na subscriptions/listen, ambao ni ombi la kawaida la POST ambalo jibu lake ni mtiririko wa muda mrefu.
• Uwezo wa kuendeleza mtiririko wa SSE (server-sent events). Kichwa cha habari cha Last-Event-ID na vitambulisho vya kila tukio (per-event IDs) vimeondolewa, hivyo mtiririko ukikatika, ombi linaloendelea hupotea na mteja lazima atume ombi jipya lenye kitambulisho kipya.
• ping, logging/setLevel na notifications/roots/list_changed. Kiwango cha logi sasa ni sehemu ya kila ombi, io.modelcontextprotocol/logLevel ndani ya _meta.

Njia moja imeongezwa, na kila seva lazima iitekeleze. server/discover inarejesha matoleo ya itifaki yanayoungwa mkono na seva, uwezo wake, na utambulisho wake katika mwito mmoja. Hii ndiyo kitu pekee kilichobaki kinachokaribiana na handshake, na kuitumia ni hiari kwa wateja.

Kwa nini usafirishaji wa session ulikuwa mgumu kuendesha katika uzalishaji

Katika 2025-11-25 na matoleo ya awali, seva iliweza kutengeneza session ID wakati wa kuanzishwa na kuirejesha ndani ya header ya Mcp-Session-Id kwenye InitializeResult. Mteja alilazimika kutuma header hiyo katika kila ombi lililofuata. Toleo la itifaki lililokubaliwa na uwezo wa mteja vilikuwa vikihifadhiwa kwenye kumbukumbu ya seva, vikiwa vimeunganishwa na ID hiyo. Kila moja ya chaguzi hizo ina gharama ya kiutendaji.

• Kuanzisha upya seva (restart) kulifuta jedwali la session. Ufafanuzi wa kiufundi uliitaka seva kujibu ombi lolote lenye session ID iliyokufa kwa 404 Not Found, na kumtaka mteja kuanza upya na InitializeRequest mpya. Kila deploy ikawa tukio la kuunganisha upya kwa kila mteja aliyekuwa ameunganishwa.
• Replica ya pili haikujua session za replica ya kwanza. Kuongeza uwezo (scaling out) kulimaanisha kutumia sticky routing kwenye load balancer, au kutumia hifadhi ya session ya pamoja ambayo kila replica ilisoma katika kila ombi.
• Jedwali la session lilikuwa kumbukumbu iliyokua kulingana na wateja wasiofanya kazi (idle). DELETE ilikuwa ya hiari, na wateja waliofunga bila kuituma waliacha entries nyuma.
• Matokeo ya orodha yaliweza kutofautiana kwa kila muunganisho, hivyo caching mbele ya seva haikuwa salama.

Kuondoa session kunaondoa matatizo yote manne kwa wakati mmoja. Hilo ndilo badiliko linalostahili kueleweka kabla ya kugusa usanidi wowote.

Yale ambayo kila ombi hubeba sasa

Kila POST kwenye endpoint ya MCP hujitegemea. Toleo la itifaki na uwezo wa mteja (client capabilities) husafiri ndani ya mwili wa ombi chini ya _meta, na sehemu zilizochaguliwa huakisiwa kwenye HTTP headers ili mpatanishi (intermediary) aweze kuelekeza maombi hayo bila kuhitaji kuchanganua JSON.

POST /mcp HTTP/1.1
Content-Type: application/json
Accept: application/json, text/event-stream
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: get_weather
Authorization: Bearer <access token>

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": {"location": "Seattle, WA"},
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {"name": "ExampleClient", "version": "1.0.0"},
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

io.modelcontextprotocol/protocolVersion na io.modelcontextprotocol/clientCapabilities ni lazima yawepo kwenye kila ombi. clientInfo si lazima, ingawa wateja wanapaswa kuituma. Ombi linalokosa sehemu ya lazima halijaundwa ipasavyo, kwa hivyo seva lazima ilikatae kwa kutumia JSON-RPC error -32602 na HTTP 400 Bad Request.

Header ya Mcp-Method ni lazima iwepo kwenye kila ombi. Mcp-Name ni lazima kwenye tools/call, resources/read na prompts/get. Thamani ya header lazima ilingane na mwili wa ombi, na seva inayochakata mwili huo lazima ikatae kutolingana huko kwa kutumia 400 Bad Request na msimbo wa hitilafu -32020, HeaderMismatch. Kanuni hiyo ipo kwa sababu load balancer inayoelekeza maombi kwa kutumia header na seva inayotekeleza maombi kwa kutumia mwili ni vyanzo viwili tofauti vya ukweli. Ikiwa unaelekeza au kuweka kikomo cha kasi (rate-limit) kwa kutumia headers hizi, kagua MCP-Protocol-Version kwanza: marekebisho ya awali hayakuwahi kuhakiki header dhidi ya mwili, kwa hivyo kwenye matoleo hayo thamani ya header haiwezi kuaminiwa.

Kutokubaliana kwa toleo sasa ni hitilafu ya kawaida ya kila ombi badala ya handshake iliyoshindwa. Seva isiyotekeleza toleo lililoombwa hujibu 400 Bad Request na hitilafu -32022, UnsupportedProtocolVersion, na kuorodhesha matoleo inayounga mkono katika data.supported. Mteja huchagua moja kutoka kwenye orodha hiyo na kujaribu tena.

Mahali ambapo state imekwenda: tokens, cursors, na subscriptions

State haijapotea. Imehamia kwenye maeneo unayoweza kuyaona na kuyaweka kwenye log.

Credentials huhamia kwenye kila ombi. Hakuna session ya kuunganisha utambulisho, kwa hivyo access token husafiri kwenye kila HTTP call na kuhakikiwa kila mara. Maelezo yapo kwenye sehemu ya authentication hapa chini.

Cursors lazima zibebe nafasi yake yenyewe. Pagination kwenye tools/list, resources/list, prompts/list na resources/templates/list hutumia opaque cursor string, na wateja hawapaswi kuichambua au kuibadilisha. Kwenye seva ya mchakato mmoja (single-process), ilikuwa kawaida kuhifadhi offset kwenye kumbukumbu, ikitambuliwa na session. Bila session, cursor lazima iwe na taarifa za kutosha kwa replica yoyote kuendeleza orodha, kwa hivyo encode nafasi hiyo ndani ya cursor na uisaini, au ihifadhi kwenye hifadhi inayoshirikiwa na kila replica. Cursor batili inapaswa kurudisha -32602. Isaini kwa sababu opaque cursor bado ni input inayotolewa na mteja ambayo code yako huidecode na kuiamini.

Subscriptions ni za ombi, si za muunganisho. Mteja anayetaka arifa za mabadiliko hutuma subscriptions/listen ikiwa na filter inayotaja aina anazotaka: toolsListChanged, promptsListChanged, resourcesListChanged na resourceSubscriptions. Seva hujibu kwa notifications/subscriptions/acknowledged na kuweka mkondo huo wa majibu wazi. Ikiwa mkondo huo utakatika, seva haihifadhi chochote, na mteja hutuma tena subscriptions/listen ili kuurejesha.

Application state ya kati ya calls huwa handle ya wazi. Wakati seva inahitaji kukumbuka kitu kati ya calls, jibu la specification ni identifier iliyotolewa na seva inayopitishwa kama argument ya kawaida ya tool. Inaonekana kwenye tool schema, inaweza kuwekwa kwenye log, na haijafichwa kwenye muunganisho. Seva yenye data halisi ya mtumiaji nyuma yake, kama vile seva ya barua pepe ya MCP inayojiendesha yenyewe, hutumia muundo huu badala ya session: identifier ya mailbox au draft ni argument ya tool, kwa hivyo replica yoyote inaweza kuchukua call inayofuata. Zana nyingi hazihitaji handle hata kidogo: zana ya utafutaji inayotumia instance yako ya SearXNG hupokea query na kurudisha matokeo, bila kitu chochote cha kuendeleza kwa call inayofuata na bila sababu ya kujali ni replica ipi iliyojibu.

Upelekaji: reverse proxy, muda wa kusubiri (timeouts), na ukaguzi wa afya (health checks)

Endpoint ya MCP ni njia moja inayokubali POST. Trafiki nyingi ni ombi fupi na jibu la JSON, ambalo proxy yoyote inaweza kushughulikia. Isipokuwa ni jibu la mtiririko (streaming response), ambapo mipangilio chaguomsingi ya proxy inaweza kukwamisha kazi. Hii ndiyo sehemu inayobadilika unapohama kutoka kwenye demo ya kompyuta ya mkononi kwenda kwenye seva ya MCP inayofanya kazi kwenye VPS.

location /mcp {
    proxy_pass http://127.0.0.1:8080;
    proxy_http_version 1.1;
    proxy_set_header Connection "";
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_buffering off;
    proxy_read_timeout 1h;
    proxy_send_timeout 1h;
}

proxy_buffering off ni muhimu kwa sababu nginx hufanya buffering ya majibu ya proxy kwa chaguomsingi, jambo linaloshikilia matukio ya SSE hadi buffer ijae au jibu liishe. Uainishaji pia unataka seva zitumie X-Accel-Buffering: no kwenye majibu ya SSE, na nginx huheshimu header hiyo, kwa hivyo seva sahihi huiambia proxy yako jambo sahihi yenyewe. Weka directive hiyo pia, kwa sababu hiyo ndiyo nusu unayoidhibiti wewe.

proxy_read_timeout ina muda chaguomsingi wa sekunde 60. Mtiririko wa subscriptions/listen unaokaa kimya kwa muda mrefu zaidi ya hapo hufungwa na nginx, si na seva yako, kwa hivyo logi zako zitaonyesha mchakato mzima na mteja wako ataonyesha mtiririko uliokatika. Iongeze kwenye location ya MCP pekee, si kwenye seva nzima. Seva pia zinahimizwa kutuma mstari wa maoni wa SSE (mstari unaoanza na koloni) kama keep-alive wakati wa vipindi vya utulivu, jambo linalozuia waamuzi (intermediaries) kufunga mtiririko huo.

Caddy inahitaji kidogo zaidi. Inafanya buffering kwa sehemu kwa chaguomsingi kwa ajili ya ufanisi wa mtandao na hutoa data mara moja wakati jibu lina Content-Type: text/event-stream, kwa hivyo streaming hufanya kazi bila maelekezo ya ziada.

mcp.example.com {
	reverse_proxy 127.0.0.1:8080 {
		health_uri /healthz
		health_interval 10s
	}
}

Zingatia mahali ambapo ukaguzi wa afya unaelekeza. Usielekeze ukaguzi amilifu kwenye endpoint ya MCP kwa kutumia GET, kwa sababu seva inayotekeleza marekebisho haya pekee itajibu 405 Method Not Allowed kwa GET na DELETE, na mbinu chaguomsingi ya ukaguzi wa afya ya Caddy ni GET. Proxy ingeashiria backend iliyo salama kabisa kama imekufa. Toa njia rahisi kama /healthz kwa ajili ya proxy, na kagua itifaki kando kwa kutumia POST.

curl -sS https://mcp.example.com/mcp \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -H 'MCP-Protocol-Version: 2026-07-28' \
  -H 'Mcp-Method: server/discover' \
  -d '{"jsonrpc":"2.0","id":"health-1","method":"server/discover","params":{"_meta":{"io.modelcontextprotocol/protocolVersion":"2026-07-28","io.modelcontextprotocol/clientCapabilities":{}}}}'

200 inayobeba orodha ya supportedVersions inamaanisha mchakato umewaka na unazungumza itifaki hiyo. 404 yenye hitilafu ya JSON-RPC -32601 inamaanisha mchakato umewaka lakini hauhudumii server/discover, ambayo kila seva ya 2026-07-28 lazima itekeleze. 400 yenye -32022 inamaanisha mkaguzi wako aliomba toleo ambalo build hii haiauni, jambo ambalo ndilo hasa unalotaka kuligundua baada ya kuboresha dependency. Nginx ya chanzo huria haina ukaguzi amilifu wa afya, kwa hivyo tumia max_fails na fail_timeout tulivu kwenye upstream na uendeshe ukaguzi wa itifaki kutoka kwenye ufuatiliaji wako badala yake.

Kuanzisha upya kwa mtiririko (rolling restart) sasa kunakugharimu maombi yaliyopo njiani na hakuna kingine. Futa, acha POST zilizo wazi zimalizike, anzisha mchakato mpya, na wateja wataomba upya chochote kilichoshindwa. Kitu kimoja unachopoteza bado ni mtiririko wowote wa subscriptions/listen ulio wazi, kwa sababu mtiririko huo ni muunganisho wa moja kwa moja kwenye mchakato mmoja mahususi. Kutokuwa na hali (statelessness) kumeondoa session affinity. Hakukuondoa muunganisho wa mtiririko ulio wazi hivi sasa, na hakuna sheria ya uelekezaji inayoweza kurekebisha hilo. Mteja anaweza kutofautisha: mtiririko unaoishia na matokeo matupu ya subscriptions/listen umefungwa vizuri, na mtiririko unaoishia bila matokeo hayo umekatika, jambo ambalo mteja anaweza kulichukulia kama sababu ya kuunganisha tena.

Caching inawezekana kwa mara ya kwanza. Matokeo kutoka kwa mbinu za orodha sasa yanabeba ttlMs na cacheScope, na cacheScope: "public" inawaambia waamuzi wa pamoja kuwa wanaweza kuhifadhi jibu hilo (cache). Hilo ni salama tu kwa sababu matokeo ya orodha hayabadiliki tena kwa kila muunganisho, jambo ambalo ni matokeo ya moja kwa moja ya kuondoa session.

Kwa nini uthibitishaji hubadilika wakati hakuna session

Ukiwa na session, ilikuwa rahisi kuthibitisha mara moja kwenye initialize kisha kutumia kitambulisho cha session kama uthibitisho wa kila kitu kinachofuata. Kitambulisho cha session kinachotumiwa kwa njia hiyo ni kitambulisho cha mtoa huduma (bearer credential) kisicho na hadhira (audience), kisicho na muda wa kuisha, na kisicho na njia ya kufutwa, kilichotolewa na seva yako mwenyewe. Kuondoa session kunaondoa njia hiyo ya mkato, na mbadala wake ni mkali zaidi.

Seva ya MCP iliyolindwa hufanya kazi kama seva ya rasilimali ya OAuth 2.1. Kila ombi la HTTP kutoka kwa mteja lazima libebe Authorization: Bearer <access token>, na seva huthibitisha tokeni hiyo katika kila ombi. Uthibitishaji unajumuisha hadhira: seva lazima ithibitishe kuwa tokeni ilitolewa kwa ajili yake mahususi, kulingana na RFC 8707 (Viashiria vya Rasilimali kwa OAuth 2.0), na haipaswi kukubali au kupitisha tokeni zilizokusudiwa kitu kingine chochote. Wateja huomba hadhira sahihi kwa kutuma kigezo cha resource pamoja na URI rasmi ya seva.

Ugunduzi huanza kwa changamoto. Ombi linapofika bila tokeni inayoweza kutumika, seva hujibu 401 Unauthorized.

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource",
                         scope="files:read"

Mteja husoma resource_metadata, huchota hati hiyo (RFC 9728, Metadata ya Rasilimali Iliyolindwa ya OAuth 2.0, ambayo seva za MCP lazima zitekeleze), hupata seva ya idhini na kuendesha mtiririko huo. Tokeni halali yenye ruhusa chache sana hupata 403 Forbidden pamoja na error="insufficient_scope" na wigo (scopes) unaohitajika kwa operesheni hiyo.

Kuna matokeo mawili kwa jinsi unavyoiendesha. Uthibitishaji wa tokeni sasa hufanyika katika kila ombi badala ya mara moja kwa kila session, kwa hivyo safari ya mtandao kwenda kwenye endpoint ya introspection kwa kila ombi itaonekana katika latency yako: pendelea tokeni unazoweza kuthibitisha ndani ya mfumo wako dhidi ya sahihi, hadhira na muda wa kuisha, au hifadhi matokeo ya uthibitishaji kwa muda mfupi kwa kutumia tokeni kama ufunguo. Na kwa sababu hakuna session inayoshikilia utambulisho, idhini lazima ihesabiwe kutoka kwa tokeni katika kila ombi. Hiyo ni njia ya kweli zaidi kuliko mfumo wa session, na inaendana na mazoezi mapana ya kuweka vitambulisho nje ya mchakato wa wakala (agent process), jambo ambalo limefafanuliwa katika kuhifadhi siri nje ya wakala wa AI.

Ni nini cha kweli kuhusu marekebisho haya, na nini si cha kweli

Kila kitu hapo juu kinaelezea marekebisho ya 2026-07-28. Hayaelezei MCP milele, na hayaelezei seva uliyoipeleka mwaka jana.

Wateja na seva kwenye 2025-11-25 na matoleo ya awali bado hutumia muundo wa handshake. Uainishaji huu unaita marekebisho hayo kuwa ya kizamani (legacy), na unaita marekebisho ya per-request-metadata kuwa ya kisasa (modern). Seva inayounga mkono marekebisho haya pekee, inapokutana na mteja wa zamani, inapaswa kujibu 405 Method Not Allowed kwa GET au DELETE kwenye endpoint ya MCP, kupuuza header yoyote ya Mcp-Session-Id bila kuunda au kurudisha nyingine, na kupuuza Last-Event-ID kwa sababu mitiririko (streams) haiwezi kurejelewa. Seva ya enzi mbili inaweza kuhudumia zote mbili kwenye endpoint moja: ombi lenye _meta ya kisasa huhudumiwa bila hali (statelessly), na ombi la initialize huchagua semantics za kikao (session) za zamani.

Kwa hivyo, kagua kamba ya marekebisho (revision string) kabla ya kuamini chochote kati ya haya. Ikiwa SDK yako bado inatuma initialize, vikao bado ni halisi kwa ajili ya usakinishaji wako na matatizo ya mfumo wa vikao yaliyotajwa hapo juu bado ni yako ya kuyashughulikia. Hali hiyo hiyo inatumika kwa upande wa mteja: mchakato wa wakala kwenye mashine yako mwenyewe, kama vile usanidi katika kuendesha wakala wa usimbaji kwenye VPS, hauna hali (stateless) katika maana hii ikiwa maktaba inayotumia inazungumza marekebisho ya kisasa. Soma toleo ambalo runtime yako inajadiliana, kisha soma marekebisho yanayolingana ya uainishaji, na uchukulie ukurasa huu kama unaoelezea marekebisho moja yaliyotajwa badala ya itifaki kwa ujumla.

FAQ

Je, seva ya MCP isiyo na state inamaanisha siwezi kuhifadhi chochote?

Hapana. Neno "stateless" linaelezea itifaki, si programu yako. Database, queue, na cache zote hufanya kazi kama zamani. Kinachobadilika ni kwamba state inayohusu maombi mengi lazima itambulike kwa kitambulisho maalum ambacho mteja (client) hupitisha katika kila ombi, kama vile handle inayotolewa na seva ndani ya argument ya tool. Usichopaswa kufanya ni kudhani muktadha (context) kutoka kwa muunganisho: vipimo (specification) vinasema seva haipaswi kutegemea maombi ya awali kwenye muunganisho uleule ili kubaini uwezo, toleo la itifaki, au utambulisho wa mteja, kwa sababu kila ombi hutoa taarifa hizo katika _meta.

Je, bado nahitaji sticky sessions kwenye load balancer yangu?

Si kwa maombi ya kawaida. Chini ya marekebisho ya 2026-07-28, kila POST hubeba toleo lake la itifaki, uwezo, na vitambulisho, kwa hivyo replica yoyote inaweza kujibu ombi lolote na round-robin inafaa. Kitu pekee cha muda mrefu kilichobaki ni mkondo wa majibu wa subscriptions/listen, ambao ni muunganisho mmoja wazi kwa mchakato mmoja. Huisha wakati mchakato huo unapoisha, na mteja hutuma tena subscriptions/listen ili kuuanzisha upya. Hiyo ni muda wa maisha wa muunganisho badala ya session affinity, na hakuna sheria ya routing inayoweza kuizuia.

Nini kimetokea kwa Mcp-Session-Id na mkondo wa HTTP GET?

Vyote viliondolewa katika marekebisho ya 2026-07-28, chini ya SEP-2567 na SEP-2575. Seva inayotekeleza marekebisho haya pekee inapaswa kujibu 405 Method Not Allowed kwa GET na DELETE kwenye endpoint ya MCP, na inapaswa kupuuza header ya Mcp-Session-Id badala ya kuirejesha. Arifa za mabadiliko zinazoanzishwa na seva sasa husafiri kwenye mkondo wa majibu wa ombi la subscriptions/listen badala ya mkondo wa GET wa pekee. Seva zinazopaswa kuendelea kuhudumia wateja wa zamani hutekeleza tabia ya marekebisho ya awali sambamba na haya.

Ninawezaje kufanya health check ya seva ya MCP bila handshake?

Tumia viwango viwili. Elekeza ukaguzi wa kazi wa proxy kwenye njia ya kawaida ya HTTP ambayo programu yako inahudumia, kwa sababu GET kwenye endpoint ya MCP itarudisha 405 kwa usahihi na itaashiria backend iliyo salama kama imekufa. Kisha kagua itifaki yenyewe kwa kutuma POST ya server/discover, ambayo kila seva ya 2026-07-28 lazima itekeleze, na uhakikishe kuwa jibu ni HTTP 200 na linaorodhesha toleo la itifaki ambalo wateja wako wanatumia. 404 yenye JSON-RPC error -32601 inamaanisha mchakato unafanya kazi lakini hauhudumii njia hiyo, na 400 yenye -32022 inamaanisha toleo uliloomba halitumiki na build hiyo.