Model Context Protocolin ydinkehittäjät julkaisivat uuden tiekartan, joka linjaa protokollan suunnan seuraavaan spesifikaatiojulkaisuun ja sen yli. Protokollan virallisen blogin mukaan tiekartta syntyi ydinkehittäjien, ylläpitäjäyhteisön ja työryhmien yhteistyönä. Se jakautuu viiteen painopistealueeseen, joilla kullakin on nimetty vastuutaho.
Rajaus on tiukka. Painopistealueille osuvat ehdotukset saavat nopeutetun käsittelyn, muut jäävät odottamaan. Osa aiheista oli edellisessä tiekartassa vasta horisontissa, mutta on nyt kypsynyt omaksi prioriteetikseen. Näin kävi palvelinlähtöisille tapahtumille, tulostyyppien parannuksille ja agenttien identiteetille.
Agenttiviestintä ei enää mahdu pyyntö–vastaus-malliin
Nykyaikaiset agenttityökuormat rikkovat perinteisen kaavan. Silmukat voivat kestää pitkään, palvelin voi työntää tuloksia virtana ja työtä pitää voida ohjata kesken suorituksen. Yksi pyyntö ja yksi vastaus eivät enää riitä.
MCP on jo vastannut tarpeeseen osittain. Protokollaan on tuotu Tasks-rakenne, subscriptions/listen-kutsu ja edistymisilmoitukset. Ydinkehittäjien mukaan pelkkä uusien primitiivien lisääminen ei kuitenkaan riitä.
Nyt halutaan varmistaa, että osaset toimivat myös yhdessä. Agents-, Transports- sekä Triggers & Events -työryhmät käyvät läpi, miten rakenteet komposoituvat keskenään. Tarkastelu on tiekartassa oma työkokonaisuutensa.
Konkreettisin uudistus on palvelinlähtöiset tapahtumat. Webhookit ja kanavat poistavat tarpeen kysellä tuloksia toistuvasti asiakkaan puolelta. Pitkissä agenttiajoissa pollaus on ollut sekä kallista että kömpelöä. Tasks-laajennus, tunnukseltaan SEP-2663, on tarkoitus kypsyttää osaksi varsinaista spesifikaatiota.
Yksi siirtotapa kaikkiin käyttötilanteisiin
Heinäkuun 28. päivän julkaisu teki etäpalvelimesta tavallisen HTTP-työkuorman. Sen jälkeen MCP-palvelinta voi ajaa samalla infrastruktuurilla kuin mitä tahansa muuta rajapintaa tai palvelua. Ratkaisu on osoittautunut skaalautuvaksi.
Sama malli halutaan nyt ulottaa muihinkin käyttötapoihin. Tavoitteena on, että paikallinen palvelin puhuu Streamable HTTP:tä stdio-yhteyden yli. Ero paikallisen ja etäpalvelimen välillä katoaisi käytännössä kokonaan.
Kehittäjän kannalta hyöty on suoraviivainen. Kun siirtotapoja on vain yksi, palvelimen ja asiakkaan toteutus yksinkertaistuu. Samalla vähenee koodimäärä, joka pitää kirjoittaa ja testata kahteen kertaan.
Muutos näkyy myös ylläpidossa. Kun palvelin on tavallinen HTTP-palvelu, sen valvonta, kuormantasaus ja skaalaus hoituvat samoilla työkaluilla kuin muukin tuotanto. Erillisiä MCP-kohtaisia ratkaisuja tarvitaan vähemmän.
Agentti tarvitsee oman identiteetin
MCP:n valtuutus rakentuu tällä hetkellä sen varaan, että ihminen hyväksyy pääsyn selaimessa. Malli toimii hyvin vuorovaikutteisissa asiakkaissa. Yhä useampi kutsuja on kuitenkin agentti, joka pyörii pilvityökuormana omalla identiteetillään.
Agentti voi toimia käyttäjän puolesta tilanteessa, jossa käyttäjä ei ole lainkaan paikalla. Se voi myös delegoida kapeamman valtuuden aliagentille. Tiekartan mukaan palvelimet tarvitsevat vakioidun tavan tunnistaa nämä identiteetit ja luottaa niihin.
Ratkaisua ei rakenneta tyhjästä. Työ nojaa olemassa oleviin standardeihin liimattujen API-avainten ja pitkäikäisten tokenien sijaan. Listalla ovat Demonstrating Proof of Possession eli DPoP, Workload Identity Federation, Enterprise-Managed Authorizationin taustalla oleva ID-JAG-myöntö sekä standardinmukainen token exchange.
Ydinkehittäjät jatkavat myös yhteistyötä OAuth-standardointielinten kanssa. Mukana ovat IETF:n OAuth- ja WIMSE-työryhmät. Tavoitteena on, että pohjalla olevat standardit kehittyvät agenttien tarpeiden mukana eivätkä jää jälkeen.
Sadan työkalun palvelin maksaa liikaa
Työkalukutsu on se MCP:n osa, johon kehittäjä törmää ensimmäisenä. Se on kestänyt käytössä hyvin koko protokollan eliniän. Heikoin kohta on tulosten käsittely.
tools/call-vastaus voi kuljettaa saman sisällön useassa eri muodossa. Palvelimen tekijällä ei ole tapaa tietää, minkä muodon asiakas lopulta näyttää mallille. Tiekartta lupaa vakioida yhden selkeän sopimuksen.
Toinen ongelma on työkalujen kasvava määrä. Sadan työkalun palvelimeen yhdistyminen tarkoittaa, että malli maksaa koko työkalupinnasta ennen kuin käyttäjä on ehtinyt kysyä mitään. Työkalun valinta myös heikkenee listan pidentyessä.
Vastaukseksi käynnistetään asteittaisen löytämisen työ. Palvelin voisi tarjota aluksi pienen sisääntulopisteen ja paljastaa luettelostaan lisää sitä mukaa kun keskustelu tarkentuu. Viides painopistealue keskittyy SDK-kirjastojen ergonomiaan ja dokumentaatioon, mikä korostuu nyt kun moni rakentaa MCP-toteutuksia osoittamalla agentin suoraan kirjastoihin.
Yhteenveto
Uusi tiekartta ei lupaa yhtä näyttävää ominaisuutta vaan siivoaa perustaa. Pitkät agenttiajot, yhtenäinen siirtotapa, agenttien identiteetti ja hallittu työkalumäärä ovat kaikki kohtia, joihin yritykset ovat törmänneet käytännön käyttöönotoissa.
Tiekartta ohjaa myös sitä, mikä etenee. Painopistealueiden sisältä tulevat SEP-ehdotukset saavat nopeutetun käsittelyn, ja ylläpitäjien katselmointiaika kohdistetaan niihin ensin. Ehdotuksen kirjoittajan kannattaa siis tunnistaa oma alueensa ja ottaa yhteyttä sen työryhmään ennen kirjoittamista.