Koodaustyökalujen yhteentoimivuus MCP:n ja A2A:n kanssa

Etusivu » Python » Koodaustyökalujen yhteentoimivuus MCP:n ja A2A:n kanssa

Tekoälyagentit eivät ole enää vain hienoja chatbotteja, jotka vastaavat kysymyksiin yhdessä ikkunassa. Ne ovat muuttumassa hajautetuiksi järjestelmiksi, jotka pystyvät lukemaan ja kirjoittamaan koodia, kutsumaan API-rajapintoja, koordinoimaan toimintaansa muiden palveluiden kanssa ja jopa neuvottelemaan muiden agenttien kanssa työn tekemiseksi. Heti kun siirrytään "yhdestä älykkäästä avustajasta" "agenttiverkostoon", ilmenee raju ongelma: miten kaikki nämä osat kommunikoivat keskenään ajautumatta kaaokseen?

Juuri tätä aukkoa MCP (Model Context Protocol) ja A2A (Agent-to-Agent Protocol) yrittävät täyttää. MCP keskittyy siihen, miten agentti muodostaa yhteyden työkaluihin, dataan ja kontekstiin, kun taas A2A keskittyy siihen, miten agentit kommunikoivat ja tekevät yhteistyötä keskenään. Ne ovat hengeltään päällekkäisiä, mutta toimivat eri tasoilla. Tässä artikkelissa perehdymme syvällisesti siihen, mitä kukin tekee, miten ne täydentävät toisiaan, miten niitä jo käytetään todellisissa järjestelmissä ja mitä tämä tarkoittaa koodaustyökalujen ja moniagenttiarkkitehtuurien tulevaisuudelle.

Mitä MCP oikeastaan ​​on käytännössä

Pohjimmiltaan MCP on standardoitu tapa antaa työkaluja, resursseja ja kehotteita tekoälyagentille, jotta agentti voi kutsua niitä turvallisesti ja johdonmukaisesti. Sen sijaan, että jokainen työkalu kytkettäisiin suoraan jokaiseen agenttiin mukautetulla liimakoodilla, työkalut ovat MCP-palvelimen takana ja MCP-asiakkaat (agentit) löytävät ja kutsuvat niitä yhtenäisen protokollan kautta.

MCP noudattaa selkeää asiakas-palvelin-arkkitehtuuria: Isäntäsovellus (kuten editori, komentorivi tai agentin ajonaikainen käyttöliittymä) upottaa MCP-asiakasohjelman, ja kyseinen asiakasohjelma avaa kahdenvälisiä yhteyksiä yhteen tai useampaan MCP-palvelimeen. Jokainen palvelin on kevyt prosessi, joka tarjoaa useita ominaisuuksia – tyypillisesti työkaluja, vain luku -resursseja ja uudelleenkäytettäviä kehotteita.

Inspiraatio on hyvin lähellä Language Server Protocol (LSP). LSP abstraktoi ongelman ”editori ↔ kieliominaisuudet”, joten meidän ei tarvinnut kirjoittaa mukautettuja integraatioita jokaisen editorin ja jokaisen ohjelmointikielen välille. Jos toteutat kielipalvelimen kerran, mikä tahansa LSP-yhteensopiva editori voi kommunikoida sen kanssa. MCP ottaa saman idean ja soveltaa sitä LLM-ohjelmien työkaluihin ja kontekstiin: toteuta työkalu kerran MCP-palvelimena, ja jokainen MCP-tietoinen agentti voi käyttää sitä.

Liikenteen näkökulmasta MCP on joustava, mutta riittävän mielipiteisiin perustuva ollakseen käytännöllinen. Se käyttää viestimuotona JSON-RPC 2.0:aa ja tukee useita siirtoprotokollia: stdio paikallisille prosesseille (loistava työpöytäsovelluksille ja paikalliselle kehittäjälle) ja HTTP tai SSE etäpalvelimille (täydellinen pilvikäyttöön tai konttikäyttöönottoihin). Protokolla määrittelee myös, miten asiakas löytää ominaisuudet ja miten työkaluja kuvataan JSON-skeeman avulla, jotta LLM voi päättää, milloin ja miten niitä kutsutaan.

Ratkaisevasti MCP ei yritä ohjata agenttisi päättelyä. Se ei päätä kun työkalu tulisi kutsua tai miten työkalut tulisi ketjuttaa. MCP on kytkentäkerros: se asettaa työkalut, resurssit ja kehotteet saataville jäsennellyllä ja löydettävällä tavalla, jättäen päätöksenteon agenttikehyksellesi, suunnittelijallesi tai kehotteiden suunnittelulle.

MCP:n ydinosakkeet: työkalut, resurssit ja kehotteet

MCP-palvelimet pyörivät kolmen pääprimitiivin ympärillä: työkalut, resurssit ja kehotteet. Nämä kolme käsitettä riittävät kattamaan useimmat reaalimaailman agenttien tarpeet ilman, että protokollaa tarvitsee muuttaa täydelliseksi orkestrointikehykseksi.

Työkalut ovat erillisiä toimintoja, joita agentti voi laukaista. Ajattele"get_weather","search_inventory","book_flight","run_sql_query"Tai"get_exchange_rateJokainen työkalu deklaroidaan nimellä, ihmisen luettavalla kuvauksella ja syöttöskeemalla. Tämän skeeman avulla LLM ymmärtää, mitä parametreja sen tulisi välittää, ja se myös suojaa taustajärjestelmääsi validoimalla argumentit ennen suorittamista.

Resurssit edustavat vain luku -tilassa olevaa dataa, jota palvelin voi tarjota tarvittaessa. Tiedostot, lokit, tietokannan rivit, dokumentaatiokatkelmat, asetustiedostot – kaikki tiedot, jotka sopivat paremmin mallinnettavaksi funktiona "nouda tämä asia" kuin "suorita tämä funktio". Resurssit voivat olla suuria, joten MCP määrittelee tapoja sivuttaa ja suoratoistaa niitä, mikä on kriittistä syötettäessä kontekstia malliin, jossa on rajoitettu ikkuna.

Kehotteet ovat uudelleenkäytettäviä pohjia, joita palvelimet voivat näyttää asiakkaille. Sen sijaan, että koodaisit pitkiä ja hauraita kehotteita agenttisi sisälle, voit keskittää ne MCP-kehotteiksi. Palvelin näyttää ne nimineen, kuvauksineen ja parametripaikoineen, ja asiakas täyttää nämä paikat suorituksen aikana. Tämä on yllättävän tehokasta, kun useiden agenttien on jaettava samat mallit tietyn työkalun kanssa kommunikoimiseen tai yrityksen laajuisten turvallisuus- ja vaatimustenmukaisuussääntöjen noudattamiseen.

Kun asiakas muodostaa yhteyden palvelimeen, se suorittaa ominaisuuksien etsintävaiheen. Palvelin vastaa työkalujen, resurssien ja kehotteiden luettelolla, joista jokaisella on yksityiskohtaiset metatiedot. Tämä luettelo syötetään sitten LLM:ään (yleensä tiivistetyssä muodossa), jotta malli voi päätellä: "Voin käyttää get_exchange_rate vastata tähän valuutanmuunnosta koskevaan kysymykseen, enkä saisi yrittää keksiä vastausta.”

Koska kaikki tämä on deklaratiivista, uusia ominaisuuksia voidaan lisätä tai poistaa koskematta agentin ydinlogiikkaan. Lisää uusi työkalu palvelimelle, ota se uudelleen käyttöön, ja jokainen yhteyden muodostava MCP-asiakasohjelma näkee sen seuraavassa ominaisuusneuvottelussa. Tämä on tekoälytyökalujen "kytke vielä yksi USB-laite" -hetki.

Konkreettinen esimerkki MCP:stä: valuutanmuunnostyökalu

Googlen Agent Development Kitin (ADK) valuuttaagentin demo on täydellinen esimerkki MCP:stä toiminnassa. Se alkaa rakentamalla pieni MCP-palvelin, joka tarjoaa yhden työkalun, get_exchange_rate, jota tukee julkinen Frankfurter-rajapinta. Levyllä se on vain pieni Python-skripti, joka käyttää fastmcp.

Palvelin määrittelee työkalun tyypillisillä argumenteilla currency_from, currency_to ja currency_datesekä vankan lokikirjauksen ja virheiden käsittelyn. Kun agentti kutsuu sitä, palvelin ottaa yhteyttä Frankfurteriin HTTP:n kautta, validoi vastauksen ja palauttaa JSON-hyötykuorman, joka sisältää vaihtokurssin tai virheobjektin. Mikään tässä ei ole tekoälyyn liittyvää; MCP ainoastaan ​​standardoi, miten tätä toiminnallisuutta kuvataan ja kutsutaan.

Paikallisesti palvelinta käytetään yksinkertaisella komennolla, ja se kuuntelee http://localhost:8080. Erillinen testiasiakasohjelma, joka myös käyttää MCP:tä, muodostaa yhteyden ja löytää get_exchange_rate ja laukaisee kutsun USD → EUR. Loki näyttää työkalun kutsumisen, lähtevän HTTP-pyynnön, onnistuneen vastauksen ja palautetun JSON-tiedoston. Agenttisi näkökulmasta se kysyi vain "mitä työkaluja minulla on?" ja sitten "kutsu tätä".

Saman palvelimen käyttöönotto Cloud Runissa tuskin muuttaa tilannetta. Säilöit MCP-palvelimen ja otat sen käyttöön. --no-allow-unauthenticated joten se vaatii IAM-tuetun todennuksen ja sitten avaa suojatun tunnelin paikalliselta koneeltasi Cloud Run proxy -komennolla. Paikallisesti MCP-asiakasohjelmasi luulee edelleen kommunikoivansa http://127.0.0.1:8080; välityspalvelin käsittelee todennus- ja verkkohypyt läpinäkyvästi.

Tämä malli on tehokas tiimeissä: voit käyttää keskitettyä MCP-palvelinta jaetuille työkaluille, kuten valuuttakursseille, sisäisille API-rajapinnoille tai suljetuille tietokannoille. Jokainen organisaation kehittäjäagentti voi kytkeytyä palvelimeen suojatun liikenteen kautta sen sijaan, että se lähettäisi oman hieman erilaisen, puoliksi ylläpidetyn kääreensä saman API:n ympärille.

Agenttien rakentaminen MCP:n päälle: yksittäisistä työkaluista kokonaisiin työnkulkuihin

MCP:stä tulee todella mielenkiintoinen, kun se upotetaan agenttikehykseen, kuten Googlen ADK:hon. Valuutta-agentin esimerkissä ADK:ta käytetään luomaan erikoistunut LLM-agentti, jonka ainoa tehtävä on vastata valuuttakursseja koskeviin kysymyksiin MCP-työkalun avulla. Agentin järjestelmäkäsky kertoo sen kirjaimellisesti: "ainoa tarkoituksesi on käyttää get_exchange_rate työkalu".

ADK kytkee tämän käskyn, valitun mallin (esimerkiksi gemini-2.5-flash) ja MCPToolset instanssi, joka osoittaa MCP-palvelimen URL-osoitteeseen. Tästä eteenpäin, kun käyttäjä kysyy ”Paljonko 250 CAD on Yhdysvaltain dollareina?”, agentti päättelee, tarvitseeko se työkalukutsua, täyttää työkaluparametrit, lähettää pyynnön MCP:n kautta ja kirjoittaa sitten käyttäjäystävällisen vastauksen palautetun JSON-tiedoston avulla.

Sama kaava skaalautuu paljon monimutkaisempiin agentteihin. Yhden valuutan API:n sijaan voit kytkeä siihen useita palvelimia: yhden sisäisille tietokannoille, toisen kolmannen osapuolen SaaS-palveluille, kolmannen dokumenttien haulle sekä palvelimen, joka tarjoaa uudelleenkäytettäviä kehotteita tai RAG-putkia. MCP:lle ei ole väliä, toimivatko palvelimet paikallisesti, Cloud Runissa, Kubernetesissa vai VPN:n takana, kunhan siirtoa tuetaan ja todennus on määritetty oikein.

ADK lisää myös agenttikeskeisen näkökulman, jota MCP tarkoituksella välttää. Se käsittelee agentteja koottavina ohjelmistokomponentteina: voit määritellä LLM-pohjaisia ​​agentteja, työkalupainotteisia agentteja, arviointiagentteja ja orkestroijia, jotka kaikki pystyvät puhumaan MCP:tä suoraan laatikosta. Tuloksena on, että "agentin rakentaminen" alkaa näyttää paljon enemmän "mikropalvelun rakentamiselta" ja paljon vähemmän "loputtoman kehotteen muokkaamiselta muistikirjassa".

Mitä A2A on – ja miksi pelkkä MCP ei riitä

Jos MCP:ssä on kyse agenttien kytkemisestä työkaluihin, niin A2A:ssa on kyse agenttien kytkemisestä muihin agentteihin. Heti kun sinulla on useita agentteja, jotka kukin osaavat tehdä jonkin asian hyvin, tarvitset tavan, jolla he voivat löytää toisensa, vaihtaa tehtäviä ja pysyä synkronoituna työn ollessa käynnissä. Juuri tätä ongelmatilaa varten A2A on suunniteltu.

Google Cloudin aloittama ja nyt Linux Foundationin alaisuudessa toimiva A2A on avoin standardi agenttien väliselle yhteentoimivuudelle. Se käyttää tuttuja tekniikoita (HTTP(S), JSON-RPC 2.0 ja SSE suoratoistoon), mutta käärii ne toimialuemalliin, joka ymmärtää agentit, taidot, tehtävät, artefaktit ja ominaisuudet. "Työkalukutsujen" sijaan saat käyttöön korkeamman tason yhteistyökielen.

A2A:n kaksi ydinajatusta ovat agenttikortit ja tehtävät. Agenttikortti on JSON-dokumentti – yleensä löydettävissä osoitteesta /.well-known/agent.json – joka kuvaa, mitä agentti voi tehdä, miten siihen voi ottaa yhteyttä, mitä todennusta se odottaa ja mitä syöttö-/tulostustiloja se tukee. Tehtävät ovat työyksiköitä, joita yksi agentti voi lähettää toiselle, ja joilla on hyvin määritelty elinkaari ja strukturoidut tulokset.

A2A-vuorovaikutuksessa yksi agentti toimii asiakasagenttina ja toinen etäagenttina. Asiakas löytää etäagentin kortin, päättää, onko tämä oikea kumppani työhön, ja luo sitten tehtäväpyynnön. Etäagentti vastaanottaa tehtävän, suorittaa sen omalla LLM:llään ja sisäisillä työkaluillaan (usein MCP:n kautta) ja lähettää sitten edistymispäivitykset ja lopulliset tiedot takaisin.

Tämä rakenne tekee A2A:sta natiivisti point-to-point-yhteyden, asynkronisen ja verkkoystävällisen. Konepellin alla Pythonin toteutukset perustuvat ASGI-kehyksiin, kuten Starlette (via A2AStarletteApplication) ja uvicorn, jossa esineet ja tehtävien päivitykset kulkevat JSON-RPC:n ja SSE:n kautta. Tämä tarkoittaa, että tehtäviä voidaan suorittaa sekunteja tai tunteja estämättä yhtäkään HTTP-pyyntöä, mikä on olennaista reaalimaailman moniagenttityönkuluissa.

A2A-esimerkki: "Hello"-agentin ja sen ulkopuolisen paljastaminen

Kanoninen A2A “HelloWorldAgent” näyttää mekaniikat pelkistetyssä muodossa. Sinä määrittelet AgentExecutor alaluokka, joka toteuttaa execute metodi. Sisällä lisäät yhden tekstiviestin – ”Hei A2A:lta!” – tapahtumajonoon tehtävän tuloksena. Peruutus on tässä yksinkertaisessa tapauksessa ei-toivottava toiminto, mutta koukku on olemassa oikeille työkuormille.

Seuraavaksi luot AgentSkill kuvailee, mitä tämä agentti voi tehdä. Esimerkissä taito hello sisältää nimen, kuvauksen, joukon tunnisteita ja edustavia käyttäjäkyselyitä. Tämä taito sitten niputetaan yhteen AgentCard sekä agentin nimi, versio, URL-osoite, ominaisuudet ja tuetut syöttö-/tulostustilat.

Lopuksi kytket kaiken yhteen A2AStarletteApplication kanssa DefaultRequestHandler ja aja sitä uvicornin alla. Ulkomaailman näkökulmasta sinulla on nyt täysivaltainen A2A-agentti kuuntelemassa sinua. http://localhost:9000Mikä tahansa A2A:ta tukeva asiakasohjelma voi hakea /.well-known/agent.json, ymmärrä, mitä tämä agentti tarjoaa, ja lähetä sille tehtäviä.

Realistisemmissa käyttöönottotilanteissa sama malli skaalautuu orkestrointiskenaarioihin, kuten matkavarauksiin, perehdytykseen tai tuen automatisointiin. ”Matkatoimistoagentti” saattaa löytää ja kommunikoida ”lentotoimistoagenttiagentin”, ”hotelliagentin” ja ”autonvuokrausagentin” kanssa, jotka kukin toimivat oman A2A-päätepisteensä takana ja piilottavat sisäiset työkalunsa ja toimittajakohtaiset API-sopimuksensa. Matkatoimistoagentti näkee vain tehtävät, taidot ja artefaktit.

Tässä kohtaa A2A:n huolenaiheiden erottaminen loistaa. Jokainen downstream-agentti voi valita omat mallinsa, kehyksensä ja työkalunsa – ADK:lla ja MCP:llä rakennettu hotelliagentti, toisella pinolla rakennettu lentoyhtiöagentti, kumppanin infrastruktuurissa sijaitseva autonvuokrausagentti – ja kaikki voivat silti tehdä yhteistyötä puhtaasti A2A-pinnan kautta.

MCP:n ja A2A:n yhdistäminen samaan arkkitehtuuriin

Paperilla jako kuulostaa siistiltä – MCP työkaluille, A2A agenteille – mutta käytännössä rajat hämärtyvät nopeasti. Todelliset järjestelmät haluavat usein piilottaa A2A:n MCP:n taakse, kerrostaa MCP:n A2A:n sisään tai yhdistää molemmat samassa prosessissa. Virallisissa A2A-esimerkeissä A2A-tiedonsiirto jopa kääritään yhdeltä palvelimelta käsin avattuihin MCP-työkaluihin, jolloin LLM näkee "yhden MCP-työkalupakin" kahden rinnakkaisen protokollapinon sijaan.

Yksi yleinen kaava on käsitellä MCP:tä kunkin agentin sisäisenä johdotuksena ja A2A:ta agenttien välisenä ulkoisena verkkona. Agentin sisällä LLM kutsuu MCP-työkaluja tavoittaakseen tietokantoja, API-rajapintoja tai dokumenttivarastoja. Ulkopuolella orkestroija kommunikoi agentin kanssa A2A-yhteyden kautta, luovuttaen tehtäviä eteenpäin ja lukeen artefakteja takaisin. Orkestroijan näkökulmasta agentti on musta laatikkopalvelu, jolla on selkeä ja kirjoitettu käyttöliittymä.

Käänteinen kuvio – A2A:n esiin tuominen MCP-työkaluina – on houkutteleva integroinnin näkökulmasta. Monilla LLM-palveluntarjoajilla on jo hiottuja työkaluja MCP:n ympärille: kehitystyökaluja, käyttöliittymädemoja, SDK:ita ja tietoturvaoppaita. Kun "ota yhteyttä etäagenttiin X" on yksi MCP-työkalu, LLM voi käynnistää A2A-vuorovaikutuksen minimaalisella asennuksella. Rekisteröit vain yhden MCP-palvelimen, mutta palvelimen avulla se voi välittää tehtäviä koko A2A-verkossa.

Juuri tätä jotkin esimerkkirepositoriot osoittavat: sen sijaan, että jokainen A2A-etäagentti kytkettäisiin suoraan malliin, MCP-palvelin tarjoaa kompaktin työkalujoukon, joka itse puhuu A2A:ta. Se rikkoo naiivin ajattelumallin ("MCP:n ja A2A:n on oltava täysin erillisiä"), mutta yksinkertaistaa huomattavasti käytännön integrointia ja pitää LLM-rajapintasi pienenä ja hyvin kuratoituna.

Mikään ei myöskään estä sinua käyttämästä MCP:tä ja A2A:ta erikseen silloin, kun se on järkevää. Monet projektit tarvitsevat MCP:tä vain yhden agentin yhdistämiseen muutamaan työkaluun. Toiset, erityisesti toimittajia tai sisäisiä tiimejä kokoavia projekteja, nojaavat vahvasti A2A-protokollaan organisaatioiden välisessä koordinoinnissa ja käyttävät omaa sisäistä johdotustaan ​​MCP:n sijaan. Tärkeää on, että protokollat ​​eivät kilpaile keskenään – ne muodostavat kokonaisuuden.

Yhteentoimivuus, viitekehykset ja puuttuva ”iso rakenne”

Pelkät protokollat ​​eivät takaa yhteentoimivuutta, jos kaikki upottavat ne hyvin erilaisiin korkeamman tason arkkitehtuureihin. Voit puhua täydellistä MCP:tä ja A2A:ta ja silti päätyä eläintarhaan keskenään yhteensopimattomia agenttimalleja, jotka jokainen keksii uudelleen suunnittelun, muistin, virheenkäsittelyn ja hallinnan.

Todennäköinen seuraava askel ekosysteemissä on MCP:n ja A2A:n päälle rakennettu kehyskerros, joka standardoi paitsi johdot myös koko rakenteen. Ajattele, miten web-kehykset syntyivät HTTP:n päälle tai miten ORM:t rakennettiin SQL:n päälle. Alamme nähdä tätä ADK:n, LangGraph-tyyppisten orkestroijien, hallittujen alustojen, kuten Vertex AI Agent Enginen, ja tekoälyyhdyskäytävien kohdalla, jotka ymmärtävät molempia protokollia.

Kun toimiala yhdistyy muutamiin pragmaattisiin malleihin – ”näin jäsennät moniagenttityönkulun A2A:n ja MCP:n yli”, ”näin paljastat tiimien työkalut MCP:n takana” – kiista siitä, pitäisikö MCP:n vai A2A:n takana olla jotain, alkaa hälvetä. Useimmat rakentajat valitsevat vain kehyksen, kytkevät palvelimen tai kaksi ja saavat järkevät oletusasetukset.

Hankalampi ja hitaampi ongelma on nopea suunnittelu ja nopea yhteentoimivuus. Vaikka käytössä olisi täydelliset protokollat, MCP:n ja A2A:n kautta yhdistäessäsi järjestelmiä käytännössä sallit mielivaltaisten kehotteiden – järjestelmäohjeiden, työkalukuvausten ja turvakaiteiden – vuotamisen ja vuorovaikutuksen rajojen yli. Jos nämä kehotteet ovat väärin kohdistettuja, päällekkäisiä tai täysin ristiriitaisia, suorituskykysi kärsii kauan ennen kuin tietoturvaongelmia ilmenee.

Käytännössä huonosti suunnitellut kehotteet ja ohjeet MCP + A2A -pinossa voivat aiheuttaa valtavaa viivettä, hallusinaatioita ja epävakautta. Jokainen agentti voi olla paikallisesti "hyvin kehotettu", mutta kun ne kerrostetaan, työnkulut voivat haurastua: työkalut priorisoidaan väärin, konteksti-ikkunat menevät hukkaan ja käyttäjätason odotukset rikotaan. A2A voi koordinoida tehtäviä, MCP voi paljastaa työkaluja, mutta kumpikaan ei pakota pitämään kehotteita johdonmukaisina.

Tästä syystä tiimit, jotka ovat itse asiassa toimittaneet LLM-tuotteita laajamittaisesti, suhtautuvat nopeaan suunnitteluun ensisijaisena suunnitteluongelmana, eivät viime hetken säätönä. Liiketoiminnan sidosryhmät näkevät kehotteet usein taianomaisena keinona korjata kaikki; insinöörit joskus hylkäävät kehotteet toissijaisina yksityiskohtina koodiin verrattuna. Todellisuus on jotain siltä väliltä: kehotteet eivät tee huonosta järjestelmästä hyvää, mutta huolimattomat kehotteet voivat ehdottomasti romuttaa muuten vakaan arkkitehtuurin.

Tietoturva, identiteetti ja hallinta MCP:ssä ja A2A:ssa

Kun agenttien toiminta ihmisten puolesta MCP- ja A2A-rajojen yli alkaa, identiteetistä ja valtuutuksesta tulee nopeasti keskeisiä ongelmia. Yksi pyyntö voi kulkea useiden delegointitasojen läpi: käyttäjä kommunikoi orkestrointiagentin kanssa, joka kutsuu työkalua MCP:n kautta, mikä puolestaan ​​kutsuu sisäisesti muita MCP-palvelimia tai A2A-agentteja, jotka vaativat erilliset tunnistetiedot.

Konkreettisia skenaarioita ilmestyy kaikkialle: SaaS-sovellus paljastaa MCP-palvelimen, joka tarvitsee OAuth-tokenit; A2A:n takana oleva sisäinen HR-agentti käyttää yrityksen LDAP-identiteettejä; kolmannen osapuolen analytiikkatyökalu käyttää omaa kertakirjautumistaan. Käyttäjä odottaa, että ”kirjaudu sisään kerran ja saat asiat tehtyä”, mutta kulissien takana on yhdistettävä useita identiteettijärjestelmiä.

Googlen A2A-dokumenteissa usean identiteetin yhdistäminen mainitaan nimenomaisesti keskeisenä haasteena. Käyttäjä U saattaa olla vuorovaikutuksessa agentin A kanssa, joka vaatii järjestelmän A identiteetin (esimerkiksi yrityksen LDAP), kun taas agentin A on delegoitava sisäisesti agentille B, joka vaatii järjestelmän B identiteetin (esimerkiksi ulkoinen SaaS-palveluntarjoaja). Protokollien on tuettava näiden identiteettien siirtämistä ja laajuuden määrittämistä pakottamatta käyttäjiä manuaalisesti uudelleen todentautumaan jokaisella hypyllä.

Identiteettipalveluntarjoajat ja OAuth/OIDC-alustat sopeutuvat nopeasti tähän uuteen todellisuuteen. Infrastruktuuri, kuten Logto, Auth0 tai yrityksen sisäiset identiteetintarjoajat, voivat jo nyt myöntää tokeneita, joita agentit kuljettavat MCP- ja A2A-puheluiden kautta. Avoin kysymys ei ole, onko tämä mahdollista – se selvästi on – vaan se, miten standardoimme mallit niin, että tänään rakennetusta työkalusta ei tule huomisen turvallisuus- tai hallintariski.

Todennuksen lisäksi havainnoitavuus ja käytäntöjen valvonta siirtyvät todennäköisesti jaettuihin "agenttiyhdyskäytäviin". Nämä yhdyskäytävät voivat lopettaa MCP- ja A2A-liikenteen, keskittää lokikirjauksen, valvoa nopeusrajoituksia, liittää käyttäjä- ja agentti-identiteettejä ja jopa suodattaa, mitkä työkalut tai agentit ovat käytettävissä missäkin kontekstissa. Tämä alkaa näyttää paljon API-yhdyskäytäviltä – vain viritettynä tekoälyliikenteelle tavallisen HTTP:n sijaan.

MCP ja A2A ovat hiljaa muuttamassa ajattelutapaamme ohjelmistointegraatiosta ja koodaustyökaluista. Kehittäjille MCP:hen ja ACP:hen (Agent Client Protocol for IDEs) kytketty koodausavustaja voi löytää työkaluja, soittaa kielipalvelimille, integroitua versionhallintaan ja kommunikoida muiden koodareiden agenttien kanssa – kaikki standardiprotokollien kautta. Yritysten osalta moniagenttijärjestelmät voivat toimia yhteen tiimien ja toimittajien välillä ilman, että kaikkea tarvitsee kytkeä uudelleen jokaista uutta käyttötapausta varten.

Pitkän aikavälin siirtymä on "kiinteistä sovelluksista" "agenttiekosysteemeihin". Aivan kuten USB ja HTTP mahdollistivat mielivaltaisten laitteiden ja palveluiden yhdistämisen, MCP ja A2A pyrkivät tekemään työkaluista ja agenteista kytkettäviä. Voittajia ovat tiimit, jotka eivät kohtele näitä protokollia kiiltävinä logoina, vaan perustavanlaatuisena infrastruktuurina sille, miten heidän järjestelmänsä kommunikoivat, tekevät yhteistyötä ja kehittyvät ajan myötä.