Interoperabilitet mellan kodningsverktyg och MCP och A2A

Hem » Python » Interoperabilitet mellan kodningsverktyg och MCP och A2A

AI-agenter är inte längre bara tjusiga chatbotar som svarar på frågor i ett enda fönster. De håller på att förvandlas till distribuerade system som kan läsa och skriva kod, anropa API:er, koordinera med andra tjänster och till och med förhandla med andra agenter för att få arbete gjort. Så fort man går från "en smart assistent" till "ett nätverk av agenter" uppstår ett brutalt problem: hur kommunicerar alla dessa delar med varandra utan att de förfaller till kaos?

Det är precis den luckan som MCP (Model Context Protocol) och A2A (Agent-to-Agent Protocol) försöker fylla. MCP fokuserar på hur en agent ansluter till verktyg, data och kontext, medan A2A fokuserar på hur agenter kommunicerar och samarbetar med varandra. De överlappar varandra i anda men fungerar på olika lager. I den här artikeln kommer vi att gå djupare in på vad var och en gör, hur de kompletterar varandra, hur de redan används i verkliga system och vad detta innebär för framtiden för kodningsverktyg och multiagentarkitekturer.

Vad MCP egentligen är i praktiken

I grund och botten är MCP ett standardiserat sätt att exponera verktyg, resurser och uppmaningar för en AI-agent så att agenten kan anropa dem säkert och konsekvent. Istället för att koppla varje verktyg direkt till varje agent med anpassad limkod, exponerar du dessa verktyg bakom en MCP-server och låter MCP-klienter (agenterna) upptäcka och anropa dem via ett enhetligt protokoll.

MCP följer en tydlig klient-server-arkitektur: En värdapplikation (som en editor, ett CLI eller en agentkörning) bäddar in en MCP-klient, och den klienten öppnar en-till-en-anslutningar till en eller flera MCP-servrar. Varje server är bara en lättviktsprocess som exponerar en mängd funktioner – vanligtvis verktyg, skrivskyddade resurser och återanvändbara prompter.

Inspirationen ligger mycket nära Language Server Protocol (LSP). LSP abstraherade problemet "editor ↔ språkfunktioner" så att vi inte behövde skriva anpassade integrationer mellan varje editor och varje programmeringsspråk. Om du implementerar en språkserver en gång kan vilken LSP-kompatibel editor som helst kommunicera med den. MCP tar samma idé och tillämpar den på verktyg och kontext för LLM:er: implementera ett verktyg en gång som en MCP-server, och varje MCP-medveten agent kan använda det.

Ur transportsynpunkt är MCP flexibel men tillräckligt åsiktsfull för att vara praktisk. Den använder JSON-RPC 2.0 som meddelandeformat och stöder flera transporter: stdio för lokala processer (utmärkt för skrivbordsappar och lokal utveckling) och HTTP eller SSE för fjärrservrar (perfekt för Cloud Run eller containerbaserade distributioner). Protokollet definierar också hur en klient upptäcker funktioner och hur verktyg beskrivs med hjälp av JSON-schema så att en LLM kan bestämma när och hur de ska anropas.

Avgörande är att MCP inte försöker orkestrera din agents resonemang. Det avgör inte när ett verktyg ska anropas, eller hur verktyg ska kedjas. MCP är kopplingslagret: det gör verktyg, resurser och prompter tillgängliga på ett strukturerat, synligt sätt, och lämnar beslutsfattandet till ditt agentramverk, planerare eller promptteknik.

Kärnkomponenter i MCP: verktyg, resurser och instruktioner

MCP-servrar kretsar kring tre huvudsakliga primitiver: verktyg, resurser och prompter. Dessa tre koncept räcker för att täcka de flesta verkliga agentbehov utan att protokollet ska förvandlas till ett fullständigt orkestreringsramverk.

Verktyg är diskreta åtgärder som en agent kan utlösa. Tänk "get_weather","search_inventory","book_flight","run_sql_query"Eller"get_exchange_rateVarje verktyg deklareras med ett namn, en läsbar beskrivning och ett inmatningsschema. Det schemat är det som låter LLM:en förstå vilka parametrar den ska skicka, och det skyddar också din backend genom att validera argument före exekvering.

Resurser representerar skrivskyddad data som en server kan hantera på begäran. Filer, loggar, databasrader, dokumentationsavsnitt, konfigurationsfiler – all information som bättre modelleras som "hämta den här grejen" än "kör den här funktionen". Resurser kan vara stora, så MCP definierar sätt att söka och strömma dem, vilket är avgörande när man matar in kontext i en modell med ett begränsat fönster.

Prompter är återanvändbara mallar som servrar kan visa för klienter. Istället för att hårdkoda långa, ömtåliga promptsträngar inuti din agent kan du centralisera dem som MCP-prompter. Servern exponerar dem med namn, beskrivningar och parameterplatser, och klienten fyller dessa platser vid körning. Detta är förvånansvärt kraftfullt när flera agenter behöver dela samma mönster för hur de ska kommunicera med ett specifikt verktyg eller följa företagsomfattande säkerhets- och efterlevnadsregler.

När en klient ansluter till en server utför den ett steg för funktionsidentifiering. Servern svarar med en katalog över verktyg, resurser och prompter, var och en med detaljerad metadata. Den katalogen matas sedan in i LLM (vanligtvis i sammanfattad form) så att modellen kan resonera: "Jag kan använda get_exchange_rate att besvara denna fråga om valutaomvandling, och jag borde inte försöka hitta på svaret.”

Eftersom allt detta är deklarativt kan nya funktioner läggas till eller tas bort utan att vidröra agentens kärnlogik. Lägg till ett nytt verktyg till servern, driftsätt det igen, och varje MCP-klient som ansluter kommer att se det vid nästa kapacitetsförhandling. Detta är tillfället då AI-verktyg ska "anslut en USB-enhet till".

Ett konkret MCP-exempel: ett valutakonverteringsverktyg

Demon av valutaagenten från Googles Agent Development Kit (ADK) är en perfekt illustration av MCP i praktiken. Det börjar med att bygga en liten MCP-server som exponerar ett enda verktyg, get_exchange_rate, som stöds av det publika Frankfurter API:et. På disken är det bara ett litet Python-skript som använder fastmcp.

Servern definierar verktyget med typade argument för currency_from, currency_to och currency_date, plus robust loggning och felhantering. När agenten anropar den, skickar servern en sökning till Frankfurter via HTTP, validerar svaret och returnerar en JSON-nyttolast med växelkursen eller ett felobjekt. Ingenting med detta är AI-specifikt; MCP standardiserar bara hur denna funktionalitet beskrivs och anropas.

Lokalt kör du servern med ett enkelt kommando och den lyssnar på http://localhost:8080. En separat testklient, som också använder MCP, ansluter, upptäcker get_exchange_rate och utlöser ett anrop för USD → EUR. Loggen visar verktygsanropet, den utgående HTTP-förfrågan, det lyckade svaret och den returnerade JSON-filen. Ur din agents synvinkel frågade den bara "vilka verktyg har jag?" och sedan "vänligen anropa det här".

Att driftsätta samma server till Cloud Run förändrar knappt historien. Du containeriserar MCP-servern, distribuerar med --no-allow-unauthenticated så det kräver IAM-baserad autentisering, och sedan öppnar en säker tunnel från din lokala maskin med hjälp av Cloud Run-proxykommandot. Lokalt tror din MCP-klient fortfarande att den pratar med http://127.0.0.1:8080; proxyn hanterar autentiserings- och nätverkshopp transparent.

Det här mönstret är kraftfullt i team: du kan köra en centraliserad MCP-server för delade verktyg som valutakurser, interna API:er eller proprietära databaser. Varje utvecklaragent i organisationen kan ansluta till den servern via en säker transport istället för att skicka sitt eget något annorlunda, halvt underhållna omslag runt samma API.

Bygga agenter ovanpå MCP: från enskilda verktyg till kompletta arbetsflöden

MCP blir riktigt intressant när man bäddar in det i ett agentramverk som Googles ADK. I exemplet med valutaagenten används ADK för att skapa en specialiserad LLM-agent vars enda uppgift är att svara på frågor om växelkurser med hjälp av MCP-verktyget. Agentens systeminstruktion säger bokstavligen: "ditt enda syfte är att använda get_exchange_rate verktyg".

ADK:n kopplar denna instruktion, den valda modellen (till exempel gemini-2.5-flash) och en MCPToolset instans som pekar på MCP-serverns URL. Från och med då, när en användare frågar "Hur mycket är 250 CAD i USD?", resonerar agenten om huruvida ett verktygsanrop behövs, fyller i verktygsparametrarna, skickar begäran via MCP och skriver sedan ett användarvänligt svar med hjälp av den returnerade JSON-filen.

Samma mönster skalas till betydligt mer komplexa agenter. Istället för ett enda valuta-API kan du koppla in flera servrar: en för interna databaser, en annan för tredjeparts SaaS, en annan för dokumentsökning, plus en server som exponerar återanvändbara prompter eller RAG-pipelines. MCP bryr sig inte om dessa servrar körs lokalt, på Cloud Run, i Kubernetes eller bakom ett VPN, så länge transporten stöds och autentiseringen är korrekt konfigurerad.

ADK lägger också till ett agent-first-perspektiv som MCP medvetet undviker. Den behandlar agenter som komponerbara programvarukomponenter: du kan definiera LLM-baserade agenter, verktygstunga agenter, utvärderingsagenter och orkestratorer, som alla kan tala MCP direkt ur lådan. Resultatet blir att "bygga en agent" börjar se mycket mer ut som "bygga en mikrotjänst" och mycket mindre som "justera en oändlig prompt i en anteckningsbok".

Vad A2A är – och varför MCP ensamt inte räcker

Om MCP handlar om att koppla agenter till verktyg, handlar A2A om att koppla agenter till andra agenter. Så snart du har flera agenter som alla vet hur man gör något bra, behöver du ett sätt för dem att hitta varandra, utbyta uppgifter och hålla sig synkroniserade medan arbetet pågår. Det är det problemområdet A2A är utformat för.

A2A, initierat av Google Cloud och nu under Linux Foundation, är en öppen standard för interoperabilitet mellan agenter. Den använder välkända tekniker (HTTP(S), JSON-RPC 2.0 och SSE för streaming) men omsluter dem i en domänmodell som förstår agenter, färdigheter, uppgifter, artefakter och funktioner. Istället för "verktygsanrop" får du ett högre samarbetsspråk.

De två kärnidéerna i A2A är agentkort och uppgifter. Ett agentkort är ett JSON-dokument – ​​vanligtvis synligt på /.well-known/agent.json – som beskriver vad en agent kan göra, hur den når den, vilken autentisering den förväntar sig och vilka in-/utdatalägen den stöder. Uppgifter är de arbetsenheter som en agent kan skicka till en annan, med en väldefinierad livscykel och strukturerade resultat.

I en A2A-interaktion tar en agent rollen som "klientagent" och en annan agerar som "fjärragent". Klienten upptäcker fjärragentens kort, avgör om detta är rätt partner för jobbet och skapar sedan en uppgiftsförfrågan. Fjärragenten tar emot uppgiften, använder sin egen LLM och interna verktyg (ofta via MCP) för att utföra den och streamar sedan tillbaka förloppsuppdateringar och slutliga artefakter.

Denna design gör A2A nativt punkt-till-punkt, asynkront och nätverksvänligt. Under huven bygger Python-implementeringar på ASGI-ramverk som Starlette (via A2AStarletteApplication) och uvicorn, med artefakter och uppgiftsuppdateringar som flödar över JSON-RPC och SSE. Det innebär att uppgifter kan köras i sekunder eller timmar utan att blockera en enda HTTP-förfrågan, vilket är avgörande för verkliga arbetsflöden med flera agenter.

Ett A2A-exempel: exponera en "Hello"-agent och mer därtill

Den kanoniska A2A "HelloWorldAgent" visar mekaniken i en nedskalad form. Du definierar en AgentExecutor underklass som implementerar en execute metod. Inuti köar du ett enda textmeddelande – ”Hej från A2A!” – till händelsekön som resultat av uppgiften. Avbrytning blir en no-op i detta enkla fall, men kroken finns för riktiga arbetsbelastningar.

Nästa steg är att skapa en AgentSkill som beskriver vad den här agenten kan göra. I exemplet, färdigheten hello innehåller ett namn, en beskrivning, en uppsättning taggar och representativa användarfrågor. Den färdigheten samlas sedan i en AgentCard tillsammans med agentens namn, version, URL, funktioner och inmatnings-/utmatningslägen som stöds.

Slutligen kopplar du in allt i en A2AStarletteApplication med en DefaultRequestHandler och kör den under Uvicorn. Vad gäller omvärlden har du nu en fullfjädrad A2A-agent som lyssnar på http://localhost:9000Alla klienter som stöder A2A kan hämta /.well-known/agent.json, förstå vad den här agenten erbjuder och skicka uppgifter till den.

I mer realistiska implementeringar skalas samma mönster ut till orkestreringsscenarier som resebokning, onboarding eller supportautomatisering. En ”resebyrå” kan upptäcka och kommunicera med en ”flygbyrå”, ”hotellbyrå” och ”biluthyrningsbyrå”, som var och en körs bakom sin egen A2A-slutpunkt och döljer sina interna verktyg och leverantörsspecifika API-avtal. Resebyrån ser bara uppgifter, färdigheter och artefakter.

Det är här A2As separering av bekymmer lyser. Varje agent nedströms kan välja sina egna modeller, ramverk och verktyg – en hotellagent byggd med ADK och MCP, en flygbolagsagent byggd med en annan stack, en biluthyrningsagent som sitter i en partners infrastruktur – och alla samarbetar fortfarande smidigt via A2A-ytan.

Sammanför MCP och A2A i en arkitektur

På pappret låter uppdelningen snygg – MCP för verktyg, A2A för agenter – men i praktiken suddas gränserna ut snabbt. Verkliga system vill ofta dölja A2A bakom MCP, lägga MCP inuti A2A, eller blanda båda i samma process. De officiella A2A-exemplen slår till och med in A2A-kommunikation som MCP-verktyg exponerade från en enda server, så att en LLM ser "en MCP-verktygsuppsättning" istället för två parallella protokollstackar.

Ett vanligt mönster är att behandla MCP som den interna kopplingen för varje agent och A2A som det externa nätverket mellan agenter. Inuti en agent anropar din LLM MCP-verktyg för att nå databaser, API:er eller dokumentarkiv. Utanför kommunicerar din orchestrator med agenten via A2A, delegerar uppgifter och läser tillbaka artefakter. Ur orchestratorns perspektiv är agenten en svart låda-tjänst med ett rent, typsnittsgränssnitt.

Det omvända mönstret – att A2A dyker upp som MCP-verktyg – är attraktivt ur integrationssynpunkt. Många LLM-leverantörer har redan finslipad verktyg kring MCP: utvecklingsverktyg, UI-demos, SDK:er och säkerhetsguider. Genom att exponera "kontakta fjärragent X" som ett enda MCP-verktyg låter du LLM:en utlösa en A2A-interaktion med minimal installation. Du registrerar bara en MCP-server, men under huven kan den servern hantera uppgifter över ett helt A2A-nätverk.

Det här är precis vad några exempelrepos visar: istället för att koppla varje fjärransluten A2A-agent direkt till modellen, erbjuder en MCP-server en kompakt uppsättning verktyg som själva kommunicerar A2A. Det bryter mot den naiva mentala modellen ("MCP och A2A måste vara helt separata") men förenklar avsevärt den praktiska integrationen och håller din LLM-gränssnittsyta liten och välkurerad.

Det finns inte heller något som hindrar dig från att använda MCP och A2A isolerat där det är vettigt. Många projekt kommer bara att behöva MCP för att ansluta en enda agent till ett fåtal verktyg. Andra, särskilt när de sammanfogar leverantörer eller interna team, kommer att luta sig starkt mot A2A för samordning mellan organisationer samtidigt som de använder sin egen interna kablage istället för MCP. Den viktiga poängen är att protokollen inte konkurrerar – de komponerar.

Interoperabilitet, ramverk och den saknade "stora strukturen"

Protokoll ensamma garanterar inte interoperabilitet om alla bäddar in dem i väldigt olika arkitekturer på högre nivå. Du kan tala perfekt MCP och A2A och ändå få en mängd ömsesidigt inkompatibla agentmönster som alla återuppfinner planering, minne, felhantering och styrning.

Det troliga nästa steget i ekosystemet är ett lager av ramverk byggda ovanpå MCP och A2A som standardiserar inte bara ledningarna, utan den större strukturen. Tänk på hur webbramverk uppstod ovanpå HTTP eller hur ORM:er byggdes ovanpå SQL. Vi börjar se detta med ADK, LangGraph-liknande orkestratorer, hanterade plattformar som Vertex AI Agent Engine och AI-gateways som förstår båda protokollen.

När branschen väl konvergerar kring en handfull pragmatiska mönster – ”så här strukturerar du ett arbetsflöde med flera agenter över A2A och MCP”, ”så här exponerar du teamens verktyg bakom MCP” – kommer oenigheten om huruvida något ”borde finnas bakom MCP eller A2A” att börja avta. De flesta byggare väljer bara ett ramverk, kopplar in en eller två servrar och får rimliga standardinställningar.

Det knepigare, långsammare problemet är snabb ingenjörskonst och snabb interoperabilitet. Även med perfekta protokoll, när du ansluter system via MCP och A2A, tillåter du i praktiken godtyckliga uppmaningar – systeminstruktioner, verktygsbeskrivningar, säkerhetsräcken – att läcka och interagera över gränser. Om dessa uppmaningar är feljusterade, redundanta eller helt motsägelsefulla, blir din prestanda lidande långt innan säkerhetsproblem uppstår.

I praktiken kan dåligt utformade prompter och instruktioner över en MCP + A2A-stack producera massiv latens, hallucinationer och instabilitet. Varje agent kan vara lokalt "väluppmanad", men när du lager upp dem kan flöden bli sköra: verktyg felprioriteras, kontextfönster går till spillo och förväntningar på användarnivå bryts. A2A kan koordinera uppgifter, MCP kan exponera verktyg, men ingetdera tvingar dig att hålla uppmaningarna sammanhängande.

Det är därför team som faktiskt har levererat LLM-produkter i stor skala tenderar att behandla snabb utveckling som en förstklassig teknisk fråga, inte en justering i sista minuten. Affärsintressenter ser ofta prompter som ett magiskt sätt att fixa allt; ingenjörer avfärdar ibland prompter som en sekundär detalj jämfört med kod. Verkligheten ligger mitt emellan: prompter gör inte ett dåligt system bra, men slarviga prompter kan absolut förstöra en annars solid arkitektur.

Säkerhet, identitet och styrning över MCP och A2A

När man väl börjar låta agenter agera för människors räkning över MCP- och A2A-gränser blir identitet och auktorisering snabbt centrala problem. En enda begäran kan gå igenom flera delegeringslager: en användare kommunicerar med en orchestrator-agent, som anropar ett verktyg via MCP, vilket internt anropar andra MCP-servrar eller A2A-agenter som kräver separata autentiseringsuppgifter.

Konkreta scenarier dyker upp överallt: en SaaS-app exponerar en MCP-server som behöver OAuth-tokens; en intern HR-agent bakom A2A förbrukar företagets LDAP-identiteter; ett tredjepartsanalysverktyg använder sin egen SSO. Användaren förväntar sig "logga in en gång och få saker gjorda", men bakom kulisserna måste flera identitetssystem federeras.

Googles A2A-dokumentation framhåller uttryckligen federation av flera identiteter som en central utmaning. En användare U kan interagera med agent A som kräver system A:s identitet (t.ex. företags-LDAP), medan agent A internt behöver delegera till agent B som kräver system B:s identitet (t.ex. en extern SaaS-leverantör). Protokoll måste stödja överföring och omfattning av dessa identiteter utan att tvinga användare att autentisera om manuellt för varje hopp.

Identitetsleverantörer och OAuth/OIDC-plattformar anpassar sig snabbt till denna nya verklighet. Infrastruktur som Logto, Auth0 eller interna identitetsleverantörer kan redan utfärda tokens som agenter bär via MCP- och A2A-anrop. Den öppna frågan är inte om detta är möjligt – det är det helt klart – utan hur vi standardiserar mönster så att ett verktyg som byggs idag inte blir en säkerhets- eller styrningsrisk imorgon.

Utöver autentisering kommer observerbarhet och policytillämpning sannolikt att flyttas till delade "agentgateways". Dessa gateways kan avsluta MCP- och A2A-trafik, centralisera loggning, tillämpa hastighetsgränser, koppla användar- och agentidentiteter och till och med filtrera vilka verktyg eller agenter som är tillgängliga i vilka sammanhang. Detta börjar likna API-gateways – bara inställda för AI-trafik istället för vanlig HTTP.

Med ett steg tillbaka omformar MCP och A2A i tysthet hur vi tänker kring programvaruintegration och kodningsverktyg. För utvecklare kan en kodningsassistent som är ansluten till MCP och ACP (Agent Client Protocol för IDE) upptäcka verktyg, anropa språkservrar, integrera med versionshantering och kommunicera med andra kodares agenter – allt via standardprotokoll. För företag kan system med flera agenter samverka mellan team och leverantörer utan att allt behöver kopplas om för varje nytt användningsfall.

Det långsiktiga skiftet går från ”hårdkopplade appar” till ”agentekosystem”. Precis som USB och HTTP gjorde det möjligt att ansluta godtyckliga enheter och tjänster, strävar MCP och A2A efter att göra verktyg och agenter inkopplingsbara. Vinnarna kommer att vara de team som behandlar dessa protokoll inte som glänsande logotyper, utan som grundläggande infrastruktur för hur deras system kommunicerar, samarbetar och utvecklas över tid.