MCP, WebMCP i A2A: quin protocol triar per als teus agents IA el 2026

Per l'equip de Kiwop · Agència Digital especialitzada en Desenvolupament de Programari i Intel·ligència Artificial aplicada per a clients globals a Europa i els EUA · Publicat el 19 d'abril de 2026 · Última actualització: 19 d'abril de 2026

TL;DR — A l'abril de 2026 conviuen tres protocols clau per a agents IA. MCP (Model Context Protocol) connecta un agent amb les seves eines i dades; és l'estàndard de facto, donat a la Linux Foundation. WebMCP és la variant navegador perquè els llocs exposin accions a agents; segueix emergent. A2A (Agent-to-Agent) connecta agents entre si; v1.0 en producció amb 150+ organitzacions. Fes servir MCP per a tools, A2A per orquestrar i WebMCP per a la teva web.

Cada setmana rebem la mateixa pregunta des de comitès de direcció i equips de producte: "Estem construint un agent IA, quin protocol fem servir?". La resposta correcta ja no és "MCP i punt" — ho era el 2025, però 2026 ha portat una constel·lació d'estàndards que es complementen més del que competeixen. L'interessant no és quin guanya: és quin resol cada problema.

Aquest article és la comparativa tècnica que ens hauria estalviat setmanes de recerca fa sis mesos. Està basada en la nostra experiència real construint assistents personals amb Claude Code i MCP, en el treball intern sobre Nexo (el nostre SaaS de workspace en desenvolupament), i en les fonts oficials més recents publicades per Anthropic, Google, Cloudflare, Vercel, la Linux Foundation i el mateix W3C. Si busques una resposta binària, no la tindràs aquí. Si busques criteri de decisió, segueix llegint.

Per què 2026 és l'any dels protocols agents IA

2023 va ser l'any del prompt. 2024 va ser l'any de l'eina (tool use). 2025 va ser l'any de l'agent. I 2026 està sent, sens dubte, l'any dels protocols. La raó és simple: quan hi ha un sol agent parlant amb una sola API, qualsevol contracte ad hoc funciona. Quan tens desenes d'agents, dotzenes de models de diferents proveïdors, centenars d'eines internes i externes, i clients que volen connectar els seus propis agents als teus, el caos es menja el producte.

L'explosió ha estat brutal. Anthropic reporta més de 10.000 servidors MCP públics actius i 97 milions de descàrregues mensuals de SDK entre Python i TypeScript segons la nota oficial de donació de MCP a la Linux Foundation. A2A, per la seva part, va passar d'una proposta de Google a l'abril de 2025 a comptar amb més de 150 organitzacions i estar sota el paraigua de la Linux Foundation a principis de 2026. El 9 de desembre de 2025 es va formalitzar l'Agentic AI Foundation (AAIF) sota la Linux Foundation, amb Anthropic, OpenAI, Google, Microsoft, AWS, Block, Cloudflare i Bloomberg com a membres platí — un moviment cobert per TechCrunch que marca la fi de l'era de protocols propietaris.

La foto a l'abril de 2026 és la següent. Hi ha tres protocols que qualsevol equip tècnic necessita entendre: MCP, WebMCP i A2A. Hi ha un quart, ACP (Agent Communication Protocol) d'IBM, que conceptualment se solapa amb A2A i l'adopció del qual a dia d'avui és considerablement menor. I hi ha una plèiade d'iniciatives adjacents — AGENTS.md, Open Responses, ANP, LLMFeed — que orbiten sense arribar encara a la mateixa massa crítica. Ens centrarem en els tres que importen per a decisions d'arquitectura reals.

La fragmentació és un problema real. Com s'apunta a l'enquesta acadèmica d'arXiv sobre protocols d'interoperabilitat d'agents, cada protocol resol una capa diferent de l'stack: el problema no és triar-ne un, és entendre en quina capa opera cadascun i combinar-los sense crear acoblaments innecessaris. Aquesta és la tesi que desenvoluparem.

MCP — Model Context Protocol (Anthropic, 2024)

MCP és, a l'abril de 2026, l'estàndard de facto per connectar un agent IA amb eines externes. Va ser publicat per Anthropic el novembre de 2024 com a protocol obert, i en el seu primer any va recórrer el camí que altres estàndards han trigat una dècada a recórrer: de proposta individual a infraestructura compartida de la indústria.

Què és MCP conceptualment

MCP defineix un contracte entre dues parts: un client MCP (generalment l'agent o l'host del model) i un servidor MCP (generalment un adaptador cap a un servei extern: Gmail, GitHub, una base de dades, un sistema intern). El client descobreix quines eines ofereix el servidor, llegeix el seu esquema, i les invoca amb paràmetres tipats. La comunicació fa servir JSON-RPC 2.0 sobre un transport.

El protocol no només cobreix eines (tools): defineix també resources (contingut llegible estàticament, com arxius o registres), prompts (plantilles reusables) i — des de l'especificació del 25 de novembre de 2025 — operacions asíncrones, stateless servers, server identity i extensions oficials segons l'especificació oficial. Aquesta evolució és la que va permetre a MCP passar de "connectar un client local" a "alimentar infraestructura d'agents en producció".

Transports: stdio i Streamable HTTP

MCP suporta dos transports oficials segons la documentació de transports de l'spec:

• stdio: el client arrenca el servidor com un subprocés local i es comunica per entrada/sortida estàndard. Ideal per a execucions locals, CLI i assistents personals.
• Streamable HTTP: el servidor viu com a procés independent i exposa un únic endpoint HTTP que accepta POST i GET. Pot fer servir Server-Sent Events per a streaming. És l'estàndard de facto per a servidors remots el 2026, i reemplaça l'antic transport HTTP+SSE.

La regla ràpida: stdio per a assistents personals en una màquina, Streamable HTTP per a serveis compartits en producció.

Servidors disponibles i ecosistema

A l'abril de 2026, l'ecosistema MCP cobreix pràcticament qualsevol servei empresarial rellevant: Gmail, Google Calendar, Google Drive, Slack, Linear, GitHub, Notion, Jira, Confluence, Salesforce, HubSpot, Stripe, PostgreSQL, Snowflake, BigQuery i desenes més. L'adopció creua fronteres de proveïdor: OpenAI el va suportar nativament a ChatGPT el març de 2025, Microsoft el va integrar a Copilot, Google el suporta a Gemini, i editors com Cursor, Windsurf i VS Code parlen MCP de forma nativa.

Casos d'ús òptims

MCP brilla quan hi ha un agent que necessita accés a moltes fonts heterogènies: un assistent personal que llegeix el teu correu i el teu calendari, un copilot de desenvolupament que consulta el teu codi i els teus tickets, un agent de vendes que creua dades de CRM i facturació. En tots aquests casos, el patró és el mateix: l'agent invoca eines tipades en servidors que parlen amb sistemes concrets.

Limitacions

MCP no és l'eina correcta quan el trànsit és agent↔agent (allà entra A2A), quan el consumidor és un navegador i no un procés amb credencials OAuth preinstal·lades (allà entra WebMCP), ni quan l'operació requereix streams binaris massius o latències submil·lisegon (allà entren APIs específiques). I encara que l'adopció és enorme, la seguretat segueix sent una àrea de treball activa: hi ha literatura creixent sobre tool poisoning, prompt injection a través de descripcions d'eines, i permisos difícils d'auditar. Qualsevol agent MCP en producció necessita una capa de sandboxing i confirmació que el protocol no imposa per si mateix.

WebMCP — el MCP per a la web (2025-2026)

WebMCP és l'aposta de Google i Microsoft per traslladar la filosofia MCP al navegador i a la pròpia web. No és una extensió de MCP: és un estàndard paral·lel, coordinat dins del W3C Web Machine Learning Community Group, que adapta el contracte client-servidor a l'entorn específic del navegador. Ja vam cobrir la proposta inicial a WebMCP: la teva web preparada per a agents IA; aquí ens centrem en com es posiciona davant MCP i A2A.

Per què WebMCP i no simplement MCP sobre HTTP

A priori sona redundant: si MCP ja té transport Streamable HTTP, per a què un altre estàndard? L'ecosistema WebMCP està en early-preview a l'abril de 2026, però la raó d'existir va més enllà de la immaduresa. La resposta tècnica és que el navegador és un entorn radicalment diferent a un servidor. Al navegador:

• L'autenticació la gestiona l'usuari, no l'agent (la cookie de sessió viu al navegador, no viatja amb l'agent).
• Les accions han de ser visibles i supervisables per l'humà (no hi ha espai per a automatitzacions opaques).
• La superfície exposada és la del lloc web visitat, no un endpoint dedicat.
• La descobribilitat ocorre quan l'usuari navega a la pàgina, no a través d'un registre global.

WebMCP resol exactament aquestes diferències. Segons la documentació oficial de Cloudflare Browser Run sobre WebMCP, el lloc web exposa un conjunt de tools — per exemple searchFlights() o bookTicket() — amb paràmetres tipats. Un agent que navega la pàgina pot descobrir aquestes tools, llegir-ne els esquemes i cridar-les directament sense simular clics ni fer scraping del DOM.

Implementació: Cloudflare i Vercel

Els dos proveïdors que més ràpid han mogut fitxa són Cloudflare i Vercel, encara que amb aproximacions diferents.

• Cloudflare va afegir suport WebMCP al seu producte Browser Run (abans Browser Rendering) el 15 d'abril de 2026, segons el seu changelog oficial. La integració permet que un agent IA connecti el seu client MCP contra Browser Run via l'endpoint CDP i descobreixi tools exposades per qualsevol lloc que implementi WebMCP — fins i tot quan aquest lloc no controla la infraestructura.
• Vercel ha orientat el seu producte al desplegament de servidors MCP sobre la seva plataforma Functions, aprofitant Fluid Compute per optimitzar patrons d'ús irregulars típics d'agents. La documentació oficial de Vercel MCP descriu com muntar endpoints Streamable HTTP amb OAuth built-in, i el seu AI SDK inclou client MCP experimental. Encara que Vercel és més MCP clàssic que WebMCP pur, és el proveïdor de referència quan el teu backend ja viu a Next.js.

Casos d'ús òptims

WebMCP és la resposta correcta quan el teu producte és un lloc web públic i vols que els agents IA el facin servir bé: e-commerce (cerca, filtres, cistella, checkout), SaaS amb formularis complexos (configuradors, pressupostos), marketplaces, sistemes de reserves. Tot cas en què un usuari humà faria servir botons i formularis i vols que un agent faci el mateix amb menys fricció.

Estat d'adopció a abril de 2026

Aquí cal ser honestos: WebMCP és emergent, no madur. Chrome el suporta de forma experimental a Canary, Cloudflare té producció parcial, i la cobertura d'AB Magency sobre la "guerra de formats agentic" recull que WebMCP competeix simultàniament amb propostes com Markdown for Agents de Cloudflare (llançada el 12 de febrer de 2026). Totes dues coexisteixen; cap ha guanyat. Per a un equip que necessiti decidir avui, WebMCP és una aposta de futur raonable per a llocs amb trànsit agent previsible, però no és un estàndard sobre el qual apostar tota l'arquitectura.

A2A — Agent-to-Agent protocol (2026)

Si MCP connecta un agent amb les seves eines, A2A connecta agents entre si i, a l'abril de 2026, és l'estàndard horitzontal de referència. És la diferència entre "un treballador fa servir les seves eines" i "un treballador delega tasca a un altre treballador". No és una distinció acadèmica: resol problemes reals que MCP no pot resoldre.

Origen i estat actual

A2A va ser anunciat per Google a Google Cloud Next 2025 el 9 d'abril de 2025, amb més de 50 socis de llançament (Accenture, Atlassian, Box, Cohere, Deloitte, LangChain, MongoDB, PayPal, Salesforce, SAP, ServiceNow, UiPath, entre d'altres). Al juny de 2025 Google el va donar a la Linux Foundation. Al març de 2026 es va publicar A2A v1.0, la versió que la comunitat considera apta per a producció. La documentació oficial a a2a-protocol.org descriu el model en detall; l'anunci d'upgrade del Google Cloud Blog documenta les millores de v1.0.

Arquitectura: Agent Cards i descobriment

El concepte central d'A2A és l'Agent Card: un document JSON que descriu què sap fer un agent, quines skills exposa, quina autenticació requereix i on contactar-lo. Els agents es descobreixen llegint les Agent Cards d'altres agents, igual que els serveis web es descobreixen per OpenAPI. A v1.0 les Agent Cards porten firma criptogràfica (Signed Agent Cards), el que permet verificar que una card va ser emesa pel domini propietari de l'agent — una millora important contra impersonació.

El transport és JSON-RPC 2.0 sobre HTTP, Server-Sent Events, o gRPC, amb autenticació via API keys, HTTP auth, OAuth 2.0/OIDC i mutual TLS. És a dir: les mateixes peces que qualsevol backend empresarial fa servir des de fa una dècada, sense reinventar res.

Casos d'ús òptims

A2A és la resposta correcta quan hi ha diversos agents especialitzats que necessiten col·laborar: un agent orquestrador que delega "buscar un vol" a un agent de viatges, "reservar un hotel" a un agent d'hotels, i "pagar" a un agent de pagaments. Cada agent especialitzat té les seves pròpies eines (MCP internament) i ofereix la seva Agent Card a l'exterior per ser orquestrat. Escenaris típics: purchasing concierges multi-proveïdor, workflows multi-departament en grans empreses, marketplaces d'agents.

Diferència fonamental amb MCP

La clau, ben resumida per IBM al seu article sobre A2A, és que MCP és vertical (agent↔tool) i A2A és horitzontal (agent↔agent). Tots dos són complementaris. Un agent A2A pot fer servir internament MCP per accedir a les seves dades. Un agent MCP pot no necessitar A2A mai si és un sol agent. La decisió no és "MCP o A2A"; és "necessito un, l'altre, o tots dos".

Limitacions i maduresa

A2A v1.0 és recent. Encara que hi ha desplegaments de producció a Microsoft, AWS, Salesforce, SAP i ServiceNow segons la cobertura de Stellagent, l'ecosistema d'agents interoperables és encara petit comparat amb el d'eines MCP. Construir amb A2A avui implica construir moltes de les peces que MCP ja té madures: llibreries, gateways, debuggers, observabilitat. Si el teu problema és "un agent amb moltes tools", A2A afegeix complexitat sense resoldre res nou.

Taula comparativa: MCP vs WebMCP vs A2A

La taula és densa a propòsit. Si l'haguéssim de resumir en una frase: MCP mana dins de l'agent, A2A mana entre agents, WebMCP mana al navegador. Qualsevol decisió arquitectònica comença per identificar on ets i treballar des d'allà.

Exemple real 1: PA de Kiwop fa servir MCP stdio

El nostre PA (Personal Assistant) — l'assistent personal IA que vam construir a Kiwop després del tall OAuth d'Anthropic del 4 d'abril de 2026, documentat al detall a d'OpenClaw a PA amb Claude Code i MCP — és un cas d'escola de l'ús òptim de MCP stdio.

L'arquitectura en una frase

Claude Code corre en una màquina local (macOS, amb launchd com a gestor de processos). Necessita accés a Gmail, Google Calendar, Google Drive i Slack. Per a cadascun d'aquests quatre serveis, tenim un servidor MCP local arrencat com a subprocés de la sessió. El client MCP incrustat a Claude Code llança els servidors per stdio, descobreix les seves tools, i les invoca quan cal.

Per què stdio i no Streamable HTTP

La temptació era desplegar els servidors MCP en un endpoint HTTP i que Claude Code es connectés per xarxa. Ho vam descartar per tres raons:

1. Credencials: les OAuth tokens de Gmail, Calendar, Drive i Slack viuen al Keychain de macOS. Exposar aquests tokens per xarxa implicaria tunneling, rotació, i un model de secrets que no volíem.
2. Latència: stdio és procés local amb pipe UNIX. Cada invocació és submil·lisegon. Un endpoint HTTP afegeix temps de xarxa sense guany funcional.
3. Simplicitat operativa: el dia que alguna cosa es trenca, inspeccionar un procés local és infinitament més fàcil que depurar un servei remot.

La decisió encaixa amb la lògica general que descrivim a LLMOps: gestionar models de llenguatge en producció — mantenir a prop el que pot estar a prop redueix superfície de fallada. Aquesta és la filosofia que reflectirem també al proper post sobre patrons i antipatrons d'agents IA en producció.

Què NO hem tocat

Ni WebMCP ni A2A. El PA és un sol agent (Claude Code) amb moltes eines, operat per una sola persona. Introduir A2A seria sobre-enginyeria pura: no hi ha un altre agent amb qui coordinar-se. Introduir WebMCP no aplica: no hi ha un navegador pel mig, i els serveis MCP ja cobreixen tot el que necessitem.

Això és important: un bon disseny és tan valuós pel que deixa fora com pel que inclou. Cada protocol afegit és codi a mantenir, superfície d'atac, i dependència de polítiques de proveïdor.

Exemple real 2: Nexo (el nostre SaaS) planeja WebMCP per a clients

Nexo és el SaaS intern que estem construint a Kiwop — un workspace col·laboratiu amb capacitats d'agents integrats. Sense entrar en detalls de producte (es llançarà oficialment més endavant), sí que podem explicar la decisió arquitectònica sobre protocols, perquè il·lustra perfectament el dilema que afrontaran la majoria de SaaS en els pròxims 12-18 mesos.

El problema: clients que volen connectar els seus propis agents

Els clients beta ens demanaven dues coses molt diferents:

1. "Volem que els nostres propis agents (Claude, GPT, agents interns del client) accedeixin a les dades del seu workspace a Nexo."
2. "Volem que els vostres agents interns a Nexo puguin col·laborar amb els agents que ja té la meva empresa."

Són dos problemes de protocols completament diferents.

Decisió: WebMCP (i MCP remot) per al primer, A2A per al segon

Per al primer problema (clients connectant agents externs a les seves dades a Nexo) vam decidir exposar un servidor MCP Streamable HTTP per tenant i, en paral·lel, preparar endpoints WebMCP perquè quan els usuaris naveguin la UI de Nexo des d'un navegador amb agent, aquest agent pugui descobrir les accions disponibles sense scrapejar el DOM. Les tools exposades són les mateixes en tots dos transports; canvia qui les consumeix i com s'autentiquen. Encaixa amb el que ja recomanem a clients al nostre servei d'integració de LLMs.

Per al segon problema (orquestració d'agents de client amb els nostres agents) apostem per A2A. Publicarem Agent Cards firmades per a cada capability interna (classify-document, summarize-meeting, draft-email), el client podrà descobrir-les des del seu agent orquestrador, i el trànsit serà JSON-RPC sobre HTTP amb OAuth 2.0. L'avantatge clau d'A2A davant "faig una altra API REST" és que el client no ha d'aprendre la nostra API: el seu agent descobreix, llegeix la card, i opera.

Què NO hem escollit i per què

Vam descartar muntar-ho tot sobre MCP pur encara que tècnicament és possible. La raó és que MCP està optimitzat per a agent↔tool: si un client vol delegar a Nexo amb un agent propi i obtenir resultats complexos (multi-step, amb estats intermedis, amb raonaments exposats), A2A encaixa millor. MCP no està pensat per a converses agent↔agent amb memòria compartida.

Vam descartar també començar amb A2A per a tot, ja que per al cas "client que vol llegir/escriure dades del seu workspace amb Claude" un servidor MCP és la ruta curta i estàndard, amb el més gran ecosistema de clients al darrere.

La lliçó més àmplia, per a qualsevol SaaS que estigui pensant com obrir-se a agents: no és una decisió binària, és una decisió per cas d'ús. Exposar dades a un únic agent client → MCP remot. Exposar una web pública a agents que la visiten → WebMCP. Interoperar amb agents de clients com a iguals → A2A.

Quan NO fer servir MCP (ni WebMCP ni A2A)

Un capítol que falta a molts articles. Els protocols d'agents són molt bons per al seu domini i molt dolents fora d'ell. Alguns senyals que NO hauries de ficar MCP, WebMCP ni A2A a la teva arquitectura:

• Latència extrema. Si l'operació requereix resposta submil·lisegon (trading d'alta freqüència, control industrial, videojocs), la sobrecàrrega de JSON-RPC, el handshake, la descripció de tools i el round-trip del model maten qualsevol protocol d'agents. Fes servir APIs binàries específiques.
• Streams binaris massius. Transcodificació de vídeo, processament d'imatges en volum, streaming d'àudio en temps real. MCP pot invocar el job, però no és el canal pel qual viatgen els bytes. Conserva els teus pipelines específics.
• Processos batch llargs sense agent. Si el teu cas és "cron job processa un CSV totes les nits", un agent IA amb MCP és artilleria contra pardals. Un script i un scheduler segueixen sent la resposta correcta.
• Determinisme estricte. Operacions bancàries, transaccions crítiques, logs d'auditoria. Un agent amb tools pot quedar al loop, però el motor transaccional ha de ser determinista, amb reintents documentats i sense marge a "el model va triar una altra tool".
• Compliance regulat amb auditoria exhaustiva. Si cada crida ha de deixar traça legalment reproduïble, necessites una capa per sota dels protocols d'agents — no per sobre — que garanteixi aquest registre. Es pot fer, però afegir un agent IA no simplifica el compliance; el complica.

Relacionat: en sectors regulats (sanitari, legal, financer), qualsevol arquitectura d'agents IA requereix passar per una fase de consultoria d'intel·ligència artificial per entendre què està permès abans de triar protocol. Triar protocol sense passar per allà és l'antipatró clàssic.

Interoperabilitat: pots combinar els tres?

Sí, i de fet és probable que ho facis. El patró més net a l'abril de 2026 combina els tres protocols en un stack coherent.

El diagrama conceptual:

1. Un agent orquestrador (nivell més alt, parla A2A cap a fora).
2. Quan necessita fer servir una eina interna (llegir una base de dades, cridar una API empresarial) → MCP.
3. Quan necessita delegar una subtasca complexa a un altre agent especialitzat → A2A cap a aquest agent.
4. Quan necessita actuar sobre un lloc web extern que no exposa API pròpia però sí WebMCP → client WebMCP via navegador.

L'agent receptor a A2A, alhora, internament fa servir MCP per a les seves pròpies tools. I si l'agent receptor és un SaaS públic amb frontend, probablement exposi també una superfície WebMCP per a usuaris humans amb agents. El sistema és recursiu i componible: cada agent és un client dels tres protocols i (potencialment) un servidor de dos (MCP i A2A).

Aquesta composició és precisament el que descriuen fonts com el mapa de protocols de Digital Applied o la guia de WorkOS sobre MCP/ACP/A2A: els protocols no competeixen perquè resolen capes diferents. Competeixen amb les seves alternatives a la mateixa capa (WebMCP vs Markdown for Agents; A2A vs ACP), no entre ells.

Un matís: evita la sobre-orquestració

Abans de ficar els tres protocols en un sistema, pregunta't si els necessites. La majoria d'aplicacions IA en producció a dia d'avui necessiten només MCP. Una minoria gran necessita MCP + WebMCP (SaaS amb frontend públic). Una minoria petita però creixent necessita MCP + A2A (ecosistemes multi-agent). El cas triple és real però rar. Si no pots justificar per què cada capa resol un problema diferent, probablement en sobra alguna.

Taula: quan fer servir cadascun

Taula: maduresa d'adopció a abril de 2026

Roadmap i adopció el 2026

Què està a cada etapa segons fonts oficials a l'abril de 2026:

• MCP: especificació estable del 25 de novembre de 2025 amb operacions asíncrones i servers stateless; proper fita rellevant, el MCP Dev Summit Europe anunciat per al 17-18 de setembre de 2026 a Amsterdam. Senyals a observar: consolidació del transport Streamable HTTP com a default remot, retirada progressiva del SSE legacy, estandardització de patrons de seguretat per a tool poisoning.
• A2A: v1.0 publicada al març de 2026 amb Signed Agent Cards i extensió formal AP2. Senyals a observar: creixement del registre públic d'Agent Cards, aparició de gateways A2A (equivalents a API gateways tradicionals), integració nativa amb els grans orquestradors (LangGraph, CrewAI, AutoGen).
• WebMCP: programa early preview obert, implementació parcial a Cloudflare, suport limitat a Chrome Canary. Senyals a observar: acceptació de l'esborrany al W3C, decisió de Chromium Stable sobre suport per defecte, posicionament definitiu davant Markdown for Agents.
• Estàndards adjacents: AGENTS.md (proposat per OpenAI, sota AAIF), Open Responses (especificació oberta d'OpenAI per a loops agents interoperables, reportada per InfoQ al febrer de 2026), i Skills (contribuïts per Block/Anthropic). Cap competeix amb MCP/WebMCP/A2A directament, sinó que resolen peces complementàries: descripció de repos, interoperabilitat de loops, bundling de prompts.

La predicció menys arriscada per als pròxims 6-12 mesos és que MCP es consolidi com a commodity, A2A assoleixi la seva primera gran ona de desplegaments B2B, i WebMCP segueixi sent un terreny en disputa fins que Chrome Stable decideixi suportar-lo o no. En el cas de decidir no suportar-lo, la proposta pot morir o migrar a una solució alternativa (Markdown for Agents o una altra).

Preguntes freqüents

MCP és només d'Anthropic?

No des del desembre de 2025. Anthropic va donar MCP a la recent creada Agentic AI Foundation sota la Linux Foundation, amb Anthropic, OpenAI, Google, Microsoft, AWS, Block, Cloudflare i Bloomberg com a membres platí. Avui MCP és governança comunitària. Anthropic segueix contribuint fortament al desenvolupament però ja no és l'únic decisor.

WebMCP substitueix la meva REST API?

No. WebMCP exposa una superfície pensada per a agents que operen des de navegadors. La teva REST API segueix sent la via correcta per a integracions backend-backend, apps mòbils, i clients autenticats amb credencials pròpies. WebMCP afegeix una capa orientada a l'agent de l'usuari, no la reemplaça.

A2A està llest per a producció a abril de 2026?

Sí per a casos estàndard. La v1.0 publicada al març de 2026 inclou Signed Agent Cards i es considera apta per a producció. Hi ha desplegaments a Microsoft, AWS, Salesforce, SAP i ServiceNow. No obstant això, l'ecosistema de llibreries i tooling està menys madur que el de MCP — espera dedicar més enginyeria pròpia a gateways, observabilitat i gestió d'Agent Cards.

Quin SDK fer servir per començar amb MCP?

Els SDKs oficials en Python i TypeScript cobreixen la majoria de casos. Per construir servidors a l'ecosistema Anthropic, el SDK TypeScript oficial és la ruta recomanada. Per a scripting i servidors locals, el SDK Python és l'estàndard. Tots dos estan mantinguts per Anthropic amb suport oficial.

Puc fer servir MCP amb models que no són d'Anthropic?

Sí. Des del març de 2025, ChatGPT suporta MCP nativament; Copilot i Gemini també. Els servidors MCP són agnòstics al model: qualsevol client que parli el protocol pot consumir-los. Aquesta és la raó principal per la qual MCP va guanyar — la portabilitat entre proveïdors és real, no màrqueting.

WebMCP és el mateix que Markdown for Agents de Cloudflare?

No. Són dues propostes competidores amb filosofies diferents. WebMCP exposa accions tipades que l'agent invoca; Markdown for Agents exposa una representació markdown estructurada del lloc perquè l'agent la interpreti. A l'abril de 2026 totes dues coexisteixen i cap ha guanyat. Si vols cobrir ambdós flancs, Cloudflare documenta com implementar suport paral·lel.

Quina és la diferència real entre A2A i ACP?

Conceptualment resolen el mateix problema: comunicació horitzontal entre agents. A2A és impulsat per Google i té molta més tracció (150+ organitzacions, Linux Foundation, v1.0 producció). ACP és impulsat per IBM (BeeAI) amb adopció més limitada. Tècnicament ACP fa servir convencions HTTP més directes; A2A fa servir JSON-RPC amb Agent Cards firmades. Si avui comences de zero, A2A té millor relació valor/risc per ecosistema.

Necessito els tres protocols al meu projecte?

Gairebé mai. La majoria de projectes IA comencen amb només MCP. Un SaaS amb frontend públic afegeix WebMCP quan el trànsit agent justifica la inversió. Un ecosistema amb múltiples agents interoperant afegeix A2A. L'error comú és ficar els tres des del dia u sense cas de negoci clar; el patró sa és començar amb MCP i afegir la resta només quan hi hagi problema real a resoldre.

Conclusió: tria per capa, no per marca

La pregunta correcta el 2026 no és "quin protocol és millor?" sinó "quina capa estic resolent?". MCP mana dins de l'agent, al vincle agent↔tool. A2A mana entre agents, al vincle horitzontal. WebMCP mana a la frontera entre la teva web pública i els agents que la visiten. Són tres capes diferents; no competeixen, es componen.

La lliçó operativa, després de construir el PA sobre MCP stdio i dissenyar Nexo sobre MCP remot + A2A + WebMCP, és que el cost de triar malament un protocol és enorme. Cada protocol porta amb si un model mental, un conjunt de llibreries, una corba d'adopció de clients i un compromís de manteniment a llarg termini. Però també és cert — i això és potser el més important — que la portabilitat entre capes mai ha estat més gran. Un servidor MCP ben dissenyat es consumeix des de Claude, ChatGPT, Copilot, Gemini i Cursor sense canvis. Un agent A2A ben dissenyat és visible des de qualsevol orquestrador que parli el protocol. Un lloc amb WebMCP respon a qualsevol agent que el visiti. La inversió en protocols oberts s'amortitza ràpid.

A Kiwop — Agència Digital especialitzada en Desenvolupament de Programari i Intel·ligència Artificial aplicada per a clients globals a Europa i els EUA — fa dos anys que construïm sobre LLMs en producció i des de principis de 2025 sobre MCP. Si el teu equip està decidint avui com obrir la vostra plataforma a agents IA o com orquestrar un sistema multi-agent, us podem ajudar a triar l'arquitectura correcta sense sobre-enginyeria. Fes un cop d'ull als nostres serveis de desenvolupament d'agents IA, consultoria d'intel·ligència artificial i integració de LLMs — o escriu-nos i seiem.

I si t'ha interessat el recorregut tècnic, segueix el fil amb els altres posts del cluster: d'OpenClaw a PA amb Claude Code i MCP, construeix el teu PA amb Claude Code i MCP, agents IA en producció: patrons i antipatrons 2026 i WebMCP: la teva web preparada per a agents IA.