Arquitectura MCP: anàlisi tècnica completa amb diagrames

L'arquitectura MCP és el conjunt fonamental de components i regles de comunicació que fan possible l'MCP (Model Context Protocol). L'MCP és un estàndard de codi obert, i l'arquitectura MCP és la infraestructura subjacent sobre la qual funciona.

Qualsevol arquitectura MCP conté tres components principals, al voltant dels quals es construeix: un amfitrió (host), un client i un servidor. Sovint es descriu el marc de comunicació de l'MCP com a format per una capa de dades i una capa de transport. La capa de dades és el conjunt de regles que defineixen com es formaten els missatges (les sol·licituds MCP s'envien en JSON-RPC 2.0). La capa de transport transporta aquests missatges i utilitza Streaming HTTP per a les connexions externes.

L'arquitectura MCP és un marc de servidor que implementa el Model Context Protocol, un estàndard obert per connectar models d'IA amb eines, recursos com ara bases de dades i indicacions (prompts) que amplien el context d'entrada. Col·lectivament, s'anomenen «primitives». En definitiva, l'arquitectura MCP permet que els LLM descobreixin quines eines tenen disponibles i executin fluxos de treball, sense necessitat d'actualitzacions periòdiques al costat del client.

Diagrama de l'arquitectura MCP: una aplicació d'IA intercanvia sol·licituds amb un servidor MCP, que proporciona eines, recursos i indicacions.

Des que Anthropic la va presentar, l'arquitectura MCP s'ha estès àmpliament en els fluxos de treball d'IA. Això es deu en gran part al fet que substitueix sistemes que requereixen més manteniment, com els que es basen en múltiples connexions d'API, sense sacrificar el rendiment. Com que tota la funcionalitat disponible es troba darrere del servidor MCP, només cal una connexió, i les actualitzacions i les novetats estan disponibles immediatament per a l'aplicació client.

L'MCP ofereix als LLM una manera de descobrir i cridar les eines, les indicacions i els recursos que tenen disponibles, ja sigui al sistema local de l'aplicació amfitriona o a través d'un proveïdor extern.

En el cas de les eines, que donen accés a funcionalitats externes, la descoberta consisteix en el fet que l'amfitrió fa una crida tools/list al servidor MCP per saber quines eines hi ha disponibles. Aleshores, l'LLM (o, en alguns casos, l'amfitrió) pot llegir les descripcions de les eines disponibles i sol·licitar-les segons calgui. Les indicacions i els recursos segueixen un procés similar.

Diagrama dels components de l'arquitectura MCP: un amfitrió que conté un LLM, un orquestrador i un client es connecta a un servidor MCP en dos passos, primer la descoberta i després les sol·licituds, i el servidor MCP exposa eines, recursos i indicacions.

Això contrasta amb l'arquitectura basada en API a mida, que ha estat la norma en el desenvolupament de programari, en què les funcionalitats externes a l'aplicació s'havien de cridar mitjançant connexions dedicades i sol·licituds amb un format precís.

L'aplicació amfitriona és la plataforma central d'orquestració i es connecta a un LLM. Eines conegudes com Perplexity i Claude Desktop poden actuar com a amfitrions dins d'un sistema MCP.

En un flux de treball senzill, l'usuari fa una pregunta mitjançant la interfície de xat. Aleshores, el component orquestrador de l'amfitrió afegeix context a la pregunta i indica a l'LLM quines primitives MCP hi ha disponibles, juntament amb una descripció de les seves capacitats.

El client és un component de programari de l'aplicació d'IA. L'MCP proporciona una interfície estàndard perquè el client es comuniqui amb servidors MCP interns i externs segons les instruccions de l'amfitrió o de l'LLM. La seva funció és establir una connexió, formatar missatges JSON-RPC, enviar sol·licituds i rebre respostes.

Els termes «amfitrió MCP» i «client MCP» de vegades s'utilitzen indistintament. Tanmateix, és una distinció útil, perquè un amfitrió, com Perplexity, pot orquestrar diversos clients MCP alhora. Un flux de treball d'IA complex pot requerir accés a desenes o fins i tot centenars de servidors MCP diferents, i cadascun utilitzarà una connexió separada.

Diagrama d'un amfitrió MCP, com Perplexity, que orquestra tres clients MCP, cadascun connectat al seu propi servidor MCP, com ara una base de dades, fitxers o una API externa.

El servidor exposa totes les eines que pot utilitzar l'eina basada en IA. Des d'un punt de vista arquitectònic, el servidor MCP interpreta la sol·licitud entrant i, quan cal, es connecta a les primitives sol·licitades.

Els servidors MCP poden donar accés a tres categories de primitives:

Eines: són, essencialment, funcionalitats de programari externes. Si es pren com a referència un enfocament tradicional basat en API, una aplicació d'analítica web podria obtenir dades mitjançant una sol·licitud formatada a un servidor extern. En l'arquitectura MCP, tota la funcionalitat de tercers d'un proveïdor està disponible a través d'una única connexió, i les sol·licituds es creen segons regles de format estàndard.
Recursos: els recursos són fonts de dades que proporcionen context de només lectura. Els esquemes de bases de dades en són un bon exemple. El servidor MCP exposa les diverses fonts d'informació que estan disponibles per a l'amfitrió. Si l'amfitrió consulta la base de dades, per exemple amb una cerca SQL generada per un LLM, es considera una sol·licitud d'eina.
Indicacions: són plantilles d'indicacions reutilitzables que ajuden els LLM a fer tasques específiques. Un usuari o un amfitrió cridarà una indicació en lloc d'una eina perquè necessita instruccions predefinides per completar una tasca. Sovint, les tasques predefinides d'una aplicació amfitriona, com l'opció de «revisar el codi» o «analitzar dades», s'emmagatzemen com a indicacions que l'usuari pot seleccionar.

També cal tenir en compte que l'MCP i les API no són tecnologies mútuament excloents. El servidor MCP pot exposar crides d'API disponibles en resposta a una sol·licitud de descoberta. La clau és que és el proveïdor de l'MCP qui les ha de mantenir, no el client.

La capa de dades de l'arquitectura MCP és el conjunt de regles que defineixen com es formaten les sol·licituds, les respostes i les notificacions. El llenguatge estàndard per als missatges és JSON-RPC.

Tota arquitectura MCP segueix un procés bàsic: (1) inicialització i descoberta per part de l'amfitrió, (2) resposta del servidor MCP i (3) una crida de l'amfitrió (de vegades decidida per l'LLM). Cada fase correspon a un missatge JSON independent.

Diagrama de la capa de dades de l'MCP: un usuari envia una indicació a l'aplicació amfitriona, on l'LLM treballa amb el client MCP; el client envia una sol·licitud al servidor MCP (eines, recursos, indicacions) i en rep un resultat, i l'amfitrió retorna una resposta a l'usuari.

Vegem com funciona la descoberta d'eines amb dos exemples (també es podrien aplicar a recursos o indicacions):

Descobrir eines abans de la generació de l'LLM: l'amfitrió inicia el client MCP, que envia una sol·licitud tools/list (la llista d'eines disponibles del servidor MCP). L'LLM la revisa durant el procés de generació i determina si cal una eina, un recurs o una indicació concrets.
Donar a l'LLM l'opció de fer una cerca: en un sistema agèntic, l'amfitrió afegeix una opció de descoberta, com ara search-tools, al context d'entrada, i l'LLM pot sol·licitar una cerca si cal.

Les eines, que en general són funcionalitats d'aplicacions externes, normalment les selecciona l'LLM o l'amfitrió. Els recursos i les indicacions se solen sol·licitar a petició de l'usuari o de l'amfitrió.

Així és una sol·licitud tools/list a un servidor MCP des d'una aplicació de notes imaginària:

json

{
  "jsonrpc": "2.0",
  "id": 101,
  "method": "tools/list",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "notes-app-client",
        "version": "0.1.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

En aquest exemple, “id”:101 identifica la sol·licitud amb un ID perquè el client pugui fer coincidir les respostes, i el camp “params” conté informació addicional sobre el client, com ara el nom del client (notes-app-client) i les seves capacitats.

Com a resposta, el servidor MCP retornarà les definicions de les eines, que inclouen els noms de les eines disponibles i els detalls associats. Per exemple, la llista podria incloure una eina add-task que permeti a l'aplicació de notes crear tasques en una aplicació connectada de gestió de tasques o de calendari, i assignar a cada tasca un títol i una prioritat.

Així podria ser una sol·licitud:

json

{
  "jsonrpc": "2.0",
  "id": 202,
  "method": "tools/call",
  "params": {
    "name": "add-task",
    "arguments": {
      "title": "Review the draft",
      "priority": "medium"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "notes-app-client",
        "version": "0.1.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

El camp “method” indica al servidor MCP que es tracta d'una crida d'eina, “name” especifica quina eina s'ha de cridar i “arguments” proporciona les entrades necessàries.

Si la capa de dades és el què de la connexió entre un client i un servidor MCP, la capa de transport n'és el com. Defineix la manera com viatgen els missatges: el canal específic i les regles que regeixen com es lliuren les sol·licituds i les respostes.

L'MCP té dues vies de transport:

Entrada/sortida estàndard: s'utilitza quan el servidor MCP s'executa al mateix entorn local que l'aplicació amfitriona. El client escriu la sol·licitud JSON a l'entrada estàndard del servidor. El servidor la llegeix, fa l'operació sol·licitada i escriu la resposta a la sortida estàndard.
Streamable HTTP: quan el servidor MCP s'executa fora de l'aplicació amfitriona, el client MCP envia sol·licituds al servidor mitjançant HTTP POST. El servidor respon amb un únic missatge JSON o amb un flux Server-Sent Events (SSE), un canal persistent «d'escolta» que li permet retornar diversos missatges al llarg del temps.

L'arquitectura MCP multiinquilí és un tipus d'implementació que pot donar servei a diversos usuaris (inquilins) simultàniament.

En aquest cas, un inquilí pot ser una persona, un grup de persones o una organització. La implementació pot consistir a executar un servidor MCP independent per a cada inquilí, a donar accés a un únic servidor compartit o a situar un conjunt de servidors darrere d'una passarel·la central. Quan s'utilitza una passarel·la, aquesta encamina les sol·licituds als punts de connexió correctes segons la identitat de l'usuari o la naturalesa de la sol·licitud.

Funciona amb el mateix principi bàsic que l'arquitectura MCP estàndard, però les sol·licituds de cada usuari operen en el seu propi espai de treball (encara que això impliqui recursos compartits) i s'autentiquen per separat. És habitual en entorns empresarials, i sovint es prefereixen els recursos compartits perquè executar diversos servidors MCP seria innecessàriament costós.

Com és, a la pràctica, una sol·licitud MCP de principi a fi? Hi ha vuit fases principals, i cadascuna implica un component diferent de l'arquitectura.

Diagrama de flux d'una sol·licitud MCP de principi a fi en vuit passos: descoberta d'eines, entrada de l'usuari, processament del model, selecció d'eines, sol·licitud, execució de l'eina, resultat i generació de la resposta.

Així és a la pràctica una crida a una eina MCP, a partir de l'exemple anterior d'una aplicació de notes connectada a un servei de gestió de tasques:

Descoberta d'eines: l'aplicació de notes (amfitrió) utilitza el seu client MCP per sol·licitar les eines disponibles del servidor mitjançant una sol·licitud tools/list. El servidor en retorna els noms, les descripcions i les entrades esperades, incloses les de l'eina add-task. Això pot passar abans que enviïs una indicació.
Entrada de l'usuari: envies una sol·licitud a l'aplicació de notes basada en un LLM mitjançant el xatbot integrat, per exemple: «Crea una tasca al meu calendari per revisar el meu nou esborrany amb prioritat mitjana».
Processament del model: l'amfitrió envia la teva sol·licitud i les definicions d'eines pertinents a l'LLM.
Selecció d'eines: l'LLM genera una sol·licitud d'eina estructurada, que especifica l'eina i les seves entrades: add-task amb title: Review the draft i priority: Medium. L'amfitrió comprova si l'acció està permesa i passa la sol·licitud al client MCP, que envia un missatge JSON-RPC.
Sol·licitud: el client MCP envia una sol·licitud tools/call al seu servidor MCP.
Execució de l'eina: el servidor MCP crida l'API de l'aplicació de gestió de tasques per crear una tasca nova amb el títol i la prioritat especificats.
Retorn del resultat: el servidor envia el resultat al client MCP, que el passa a l'amfitrió. L'amfitrió l'afegeix a la informació que es proporciona a l'LLM.
Generació de la resposta: l'LLM utilitza el resultat per generar una resposta per a l'usuari, com ara «He creat una tasca per revisar l'esborrany amb prioritat mitjana».

Sovint es confonen l'MCP i l'arquitectura d'API tradicional, però són tecnologies complementàries. L'MCP es va dissenyar específicament per a aplicacions basades en IA. Supera l'elevada càrrega de manteniment que suposa implementar i gestionar diverses connexions d'API codificades de manera fixa.

En proporcionar a una aplicació amfitriona una única connexió per proveïdor de funcionalitats o recurs intern, l'MCP ajuda a resoldre el problema d'un context d'entrada sobrecarregat (amb la llista de totes les API) o d'uns scripts d'aplicació basats en API limitats.

En canvi, els MCP poden exposar API (o, més ben dit, la funcionalitat que crida les API) com a part de la seva llista d'eines. Cada cop que un proveïdor actualitza la seva aplicació i hi ha una API nova, o si canvia la documentació, només ha d'actualitzar el servidor MCP. No cal fer cap canvi de codi al costat de l'aplicació amfitriona.

La seguretat de l'MCP ha estat objecte de molt debat des que es va presentar. Tot i que en general es considera una tecnologia segura, presenta diversos riscos de seguretat, molts dels quals són més rellevants en implementacions d'arquitectura complexes.

L'arquitectura MCP presenta els punts febles potencials següents:

Injecció d'indicacions: un usuari insereix una indicació maliciosa en dades externes que el model d'IA interpreta erròniament com una instrucció.
Accés amb privilegis excessius: els servidors MCP poden exposar un gran nombre d'eines a un model d'IA, cosa que pot augmentar el potencial de problemes de seguretat (el radi d'impacte).
Filtracions de dades accidentals: les implementacions mal configurades poden fer que informació confidencial, com ara claus d'API o credencials de bases de dades, es transmeti a un LLM.
Manipulació del sistema local: els servidors MCP locals són tan vulnerables com qualsevol altra aplicació als problemes del sistema local, com els scripts maliciosos, amb el problema afegit que poden tenir efectes nocius en cascada sobre els sistemes d'IA agèntica.

Cap d'aquests problemes és insalvable. Sovint, n'hi ha prou amb mesures establertes per garantir la seguretat del sistema. Mesures com mantenir una persona en el procés, aplicar controls estrictes sobre les dades confidencials i protegir-se dels atacs als servidors són pràctiques habituals.

L'MCP ha demostrat ser un estàndard obert útil i popular entre els desenvolupadors. Supera molts dels problemes de les API codificades de manera fixa en aplicacions basades en LLM i redueix considerablement la càrrega de programació dels desenvolupadors.

De cara al futur, és gairebé segur que l'arquitectura subjacent d'amfitrió i servidor de l'MCP es mantindrà igual. Les innovacions futures se centraran en capacitats agèntiques avançades en fluxos de treball de diversos passos.

A més, caldran salvaguardes de seguretat més sòlides a mesura que s'implementin aquestes funcionalitats agèntiques, així com una arquitectura escalable, especialment a la capa de transport, a mesura que els sistemes d'IA es facin més amplis i complexos.

Què és l'arquitectura MCP?

Components de l'arquitectura MCP: amfitrions, clients i servidors

Amfitrió

Client

Servidor

Què és la capa de dades de l'arquitectura MCP?

Què és la capa de transport de l'arquitectura MCP?

Què és l'arquitectura MCP multiinquilí?

Diagrama de l'arquitectura MCP: explicació pas a pas

En què es diferencia l'arquitectura MCP de l'arquitectura d'API tradicional?

L'arquitectura MCP és segura?

Quin és el futur de l'arquitectura MCP?