Model Context Protocolin uusi 2026-07-28-spesifikaatio muuttaa MCP:n toimintaa merkittävästi. Protokollan istunnot poistuvat, mikä helpottaa MCP-palveluiden skaalaamista ja sovittamista olemassa olevaan verkkoinfrastruktuuriin.
Muutos on kuitenkin herättänyt kehittäjien keskuudessa toisen kysymyksen: jos MCP toimii nyt tilattomilla HTTP-pyynnöillä, kuinka paljon se enää eroaa tavallisesta API:sta?
Uudistus ei rajoitu istuntojen poistamiseen. MCP tuo HTTP-liikenteeseen myös uutta metadataa, jonka avulla API-yhdyskäytävät, palomuurit ja muut infrastruktuuripalvelut voivat tunnistaa agentin tekemän toiminnon ilman JSON-RPC-pyynnön sisällön avaamista.
MCP-istunnot poistuvat
Aikaisemmassa mallissa MCP-yhteys alkoi initialize- ja initialized-vaihdolla. Palvelin loi istunnon, jota seurattiin Mcp-Session-Id-tunnisteella.
Tämä teki palveluiden skaalaamisesta hankalampaa. Seuraavat pyynnöt piti saada palvelimelle, jolla kyseiseen istuntoon liittyvä tila oli saatavilla. Kuormantasaus, automaattinen skaalaaminen ja palveluiden päivittäminen joutuivat kaikki huomioimaan aktiiviset istunnot.
Uudessa MCP-versiossa handshake ja Mcp-Session-Id poistuvat protokollan varsinaiselta pyyntöpolulta. Tarvittavat tiedot, kuten protokollaversio, asiakas ja ominaisuudet, kulkevat yksittäisen pyynnön mukana.
Tämän seurauksena mikä tahansa palvelininstanssi voi käsitellä pyynnön.
MCP-palveluiden ajaminen esimerkiksi Kubernetes-ympäristössä tai suuren kuormantasaajan takana muuttuu näin huomattavasti suoraviivaisemmaksi.
Uudet HTTP-headerit helpottavat liikenteen hallintaa
Samalla MCP:n Streamable HTTP -pyyntöihin tulee kaksi pakollista headeria: Mcp-Method ja Mcp-Name.
Esimerkiksi search-nimisen työkalun kutsu voidaan tunnistaa suoraan seuraavista ohjelmiston tiedoista:
Mcp-Method: tools/call
Mcp-Name: search
Varsinainen JSON-RPC-data kulkee edelleen pyynnön sisällä, mutta infrastruktuurin ei tarvitse enää avata sitä selvittääkseen, mitä agentti yrittää tehdä.
Tällä on merkitystä erityisesti MCP:n yrityskäytössä. API gateway voi esimerkiksi asettaa eri työkaluille omat nopeusrajoitukset, estää tiettyjä kutsuja tai mitata niiden käyttöä.
Cloudflaren Matt Careyn mukaan tämä mahdollistaa MCP-liikenteen käsittelemisen pitkälti samoilla infrastruktuurityökaluilla, joita yritykset käyttävät jo tavallisten API-rajapintojen hallintaan.
Myös työkaluille annettuja argumentteja voidaan siirtää headereihin esimerkiksi mukautettua reititystä varten.
Myös ihmisen hyväksyntää vaativat pyynnöt muuttuvat
Tilattomuuteen siirtyminen vaikuttaa myös MCP:n elicitation-toimintoihin eli tilanteisiin, joissa palvelin tarvitsee käyttäjältä tai asiakkaalta lisätietoja ennen toiminnon jatkamista. Aikaisemmin palvelimen aloittama pyyntö saattoi edellyttää avoimen yhteyden säilyttämistä.
Uudessa mallissa käytetään Multi Round-Trip Requests -menetelmää. Palvelin voi palauttaa input_required-tilan, jonka jälkeen asiakas kerää tarvittavan vastauksen ja lähettää pyynnön uudelleen.
Esimerkiksi ihmisen hyväksyntää odottava agenttitoiminto muuttuu näin kahdeksi erilliseksi pyynnöksi yhden pitkään avoimena pidettävän yhteyden sijaan. Ratkaisu helpottaa infrastruktuuria, mutta muuttaa samalla sitä, miten pitkäkestoiset agenttityönkulut täytyy toteuttaa.
Autentikointia kiristetään
Uusi MCP-spesifikaatio muuttaa myös autentikointia ja valtuutusta. Dynamic Client Registration on merkitty poistuvaksi ominaisuudeksi, ja sen tuki on tarkoitus lopettaa kesän 2027 jälkeen. Samalla MCP ottaa käyttöön RFC 9207:n mukaisen issuer identification -mekanismin.
Asiakkaiden pitää lisäksi lähettää palvelimen kanoninen URI RFC 8707:n resource-arvona. Tarkoituksena on varmistaa, että käyttöoikeustunnus hyväksytään vain sille tarkoitetussa palvelussa.
Muutokset vievät MCP:tä jälleen lähemmäksi jo olemassa olevia verkkopalveluiden turvallisuus- ja API-käytäntöjä.
Kehittäjät kysyvät, keksittiinkö REST uudelleen
Juuri tämä on synnyttänyt keskustelua MCP:n tulevaisuudesta. Hacker Newsissa osa kehittäjistä pitää muutosta osoituksena siitä, että MCP:n ei olisi alun perinkään pitänyt olla tilallinen protokolla. Kun istunnot poistetaan ja pyynnöt voidaan käsitellä itsenäisesti, MCP-palvelut voivat hyödyntää tavallisia kuormantasaajia, API gateway -ratkaisuja ja asteittaisia käyttöönottoja.
Kriittisimmissä kommenteissa uudistusta on kuvattu käytännössä paluuksi ajatukseen, jossa asiakas yksinkertaisesti lähettää itsenäisen HTTP-pyynnön palvelimelle.
MCP ei kuitenkaan teknisesti muutu REST-rajapinnaksi. Sen viestintä perustuu edelleen JSON-RPC:hen.
Puolustajien mukaan MCP:n arvo ei myöskään koskaan perustunut siihen, että se olisi keksinyt täysin uuden tavan tehdä verkkopyyntöjä. Sen merkitys on yhteisessä standardissa, jonka tekoälypalveluiden ja työkalujen kehittäjät ovat ottaneet laajasti käyttöön.
Anthropicin mukaan MCP:n SDK-pakettien kuukausittaiset lataukset ovat jo ylittäneet 400 miljoonaa.
MCP:n arvo voi siirtyä infrastruktuuriin
Uudistus voi samalla vahvistaa MCP:n ympärille rakentuvien gateway-, autentikointi- ja hallintapalveluiden merkitystä. Kun agentin kutsuma menetelmä ja työkalu ovat näkyvissä suoraan HTTP-tasolla, yritysten ei tarvitse rakentaa kokonaan erillistä hallintakerrosta MCP:tä varten. Agenttiliikenne voidaan tuoda lähemmäksi samoja käytäntöjä, joilla tavallisia API-rajapintoja jo valvotaan.
Tuotannossa MCP:tä jo käyttävien yritysten täytyy silti tehdä migraatiotyötä. Erityisesti protokollaistuntoihin, palvelimelta asiakkaalle lähetettäviin pyyntöihin tai jatkuvasti avoimiin yhteyksiin perustuvat toteutukset eivät siirry uuteen malliin automaattisesti.
Vanha ja uusi toteutus voidaan kuitenkin pitää siirtymävaiheessa rinnakkain, jolloin aktiiviset istunnot voidaan ajaa loppuun ennen vanhan reitin poistamista.
MCP:n uusi suunta onkin hieman paradoksaalinen. Mitä paremmin protokolla mukautuu tavalliseen verkkoinfrastruktuuriin, sitä enemmän se alkaa ulospäin muistuttaa teknologioita, joita kehittäjät ovat käyttäneet jo vuosikymmeniä.
Ero voi lopulta olla vähemmän siinä, miten HTTP-pyyntö kulkee verkossa, ja enemmän siinä, että tekoälyagentit ja niiden käyttämät työkalut puhuvat samaa standardoitua kieltä.