Arquitectura MCP: análise técnica completa con diagramas

A arquitectura MCP é o conxunto fundamental de compoñentes e regras de comunicación que fan posible o MCP (Model Context Protocol). O MCP é un estándar de código aberto, e a arquitectura MCP é a infraestrutura subxacente sobre a que funciona.

Calquera arquitectura MCP contén tres compoñentes principais, arredor dos cales se constrúe: un host, un cliente e un servidor. O marco de comunicación do MCP adoita describirse como composto por unha capa de datos e unha capa de transporte. A capa de datos é o conxunto de regras que determina como se formatan as mensaxes (as solicitudes MCP envíanse en JSON-RPC 2.0). A capa de transporte leva esas mensaxes e emprega HTTP en streaming para as conexións externas.

A arquitectura MCP é un marco de servidor que implementa o Model Context Protocol, un estándar aberto para conectar modelos de IA a ferramentas, a recursos como bases de datos e a prompts que amplían o contexto de entrada. Todos estes elementos denomínanse colectivamente “primitivas”. En definitiva, a arquitectura MCP permite que os LLM descubran que ferramentas están dispoñibles e executen fluxos de traballo, sen necesidade de actualizacións periódicas no lado do cliente.

Diagrama da arquitectura MCP: unha aplicación de IA intercambia solicitudes cun servidor MCP, que proporciona ferramentas, recursos e prompts.

Desde que Anthropic a presentou, a arquitectura MCP pasou a usarse amplamente nos fluxos de traballo de IA. Isto débese en boa medida a que substitúe sistemas que requiren máis mantemento, como os construídos arredor de múltiples conexións de API, sen sacrificar o rendemento. Como toda a funcionalidade dispoñible se atopa detrás do servidor MCP, só fai falta unha conexión, e as actualizacións e novidades están dispoñibles de inmediato para a aplicación cliente.

O MCP ofrece aos LLM un medio para descubrir e chamar as ferramentas, os prompts e os recursos dos que dispoñen, xa sexa no sistema local da aplicación host ou a través dun provedor externo.

No caso das ferramentas, que dan acceso a funcionalidades externas, o descubrimento consiste en que o host faga unha chamada tools/list ao servidor MCP para saber que ferramentas están dispoñibles. Despois, o LLM (ou, nalgúns casos, o host) pode ler as descricións das ferramentas dispoñibles e solicitalas segundo sexa necesario. Os prompts e os recursos seguen un proceso similar.

Diagrama dos compoñentes da arquitectura MCP: un host que contén un LLM, un orquestrador e un cliente conéctase a un servidor MCP en dous pasos, primeiro o descubrimento e despois as solicitudes, e o servidor MCP expón ferramentas, recursos e prompts.

Isto contrasta coa arquitectura baseada en API personalizadas, que foi a norma no desenvolvemento de software, na que a funcionalidade externa á aplicación tiña que chamarse mediante conexións dedicadas con solicitudes cun formato preciso.

A aplicación host é a plataforma central de orquestración e conéctase a un LLM. Ferramentas coñecidas como Perplexity e Claude Desktop poden actuar como hosts dentro dun sistema MCP.

Nun fluxo de traballo sinxelo, o usuario fai unha pregunta a través da interface de chat. A continuación, o compoñente orquestrador do host engade contexto á pregunta e indica ao LLM que primitivas MCP están dispoñibles, xunto cunha descrición das súas capacidades.

O cliente é un compoñente de software da aplicación de IA. O MCP proporciona unha interface estándar para que o cliente se comunique con servidores MCP internos e externos segundo as instrucións do host ou do LLM. A súa función é establecer unha conexión, formatar mensaxes JSON-RPC, enviar solicitudes e recibir respostas.

Os termos “host MCP” e “cliente MCP” úsanse ás veces indistintamente. Porén, é unha distinción útil, porque un host, como Perplexity, pode orquestrar varios clientes MCP á vez. Un fluxo de traballo de IA complexo podería requirir acceso a decenas ou mesmo centos de servidores MCP distintos, e cada un deles empregará unha conexión separada.

Diagrama dun host MCP, como Perplexity, que orquestra tres clientes MCP, cada un conectado ao seu propio servidor MCP, como unha base de datos, ficheiros ou unha API externa.

O servidor expón todas as ferramentas que pode usar a ferramenta baseada en IA. Desde unha perspectiva arquitectónica, o servidor MCP interpreta a solicitude entrante e, cando é necesario, conéctase ás primitivas solicitadas.

Os servidores MCP poden dar acceso a tres categorías de primitivas:

Ferramentas: son, esencialmente, funcionalidades de software externas. Se pensas nun enfoque tradicional baseado en API, unha aplicación de analítica web podería obter datos mediante unha solicitude formatada a un servidor externo. Na arquitectura MCP, toda a funcionalidade de terceiros dun provedor está dispoñible a través dunha única conexión, e as solicitudes créanse segundo regras de formato estándar.
Recursos: os recursos son fontes de datos que proporcionan contexto de só lectura. Os esquemas de bases de datos son un bo exemplo. O servidor MCP expón as distintas fontes de información que están dispoñibles para o host. Se o host consulta a base de datos, por exemplo cunha busca SQL xerada por un LLM, considérase unha solicitude de ferramenta.
Prompts: son modelos de prompts reutilizables que axudan aos LLM a realizar tarefas específicas. Un usuario ou un host chamará a un prompt en lugar de a unha ferramenta porque necesita instrucións xa preparadas para completar unha tarefa. A miúdo, as tarefas predefinidas dunha aplicación host, como a opción de “revisar código” ou “analizar datos”, gárdanse como prompts que o usuario pode seleccionar.

Tamén convén sinalar que MCP e API non son tecnoloxías mutuamente excluíntes. O servidor MCP pode expoñer chamadas de API que estean dispoñibles en resposta a unha solicitude de descubrimento. O fundamental é que lle corresponde ao provedor do MCP mantelas, non ao cliente.

A capa de datos na arquitectura MCP é o conxunto de regras que definen como se formatan as solicitudes, as respostas e as notificacións. A linguaxe estándar para as mensaxes é JSON-RPC.

Toda arquitectura MCP segue un proceso básico de (1) inicialización e descubrimento por parte do host, (2) resposta do servidor MCP e (3) chamada por parte do host (decidida ás veces polo LLM), e cada etapa representa unha mensaxe JSON separada.

Diagrama da capa de datos do MCP: un usuario envía un prompt á aplicación host, onde o LLM traballa co cliente MCP; o cliente envía unha solicitude ao servidor MCP (ferramentas, recursos, prompts) e recibe un resultado, e o host devolve unha resposta ao usuario.

Vexamos como funciona o descubrimento de ferramentas a través de dous exemplos (poderían aplicarse tamén a recursos ou prompts):

Descubrir ferramentas antes da xeración do LLM: o host inicia o cliente MCP, que envía unha solicitude tools/list (a lista de ferramentas dispoñibles do servidor MCP). O LLM revísaa durante o proceso de xeración e determina se se necesita unha ferramenta, un recurso ou un prompt concreto.
Darlle ao LLM a opción de realizar unha busca: nun sistema axéntico, o host engade unha opción de descubrimento, como search-tools, á entrada de contexto, e o LLM pode solicitar unha busca se é necesario.

As ferramentas, que en xeral son funcionalidades de aplicacións externas, adoitan ser seleccionadas polo LLM ou polo host. Os recursos e os prompts adoitan solicitarse a petición do usuario ou por parte do host.

Así se ve unha solicitude tools/list a un servidor MCP desde unha aplicación de notas imaxinaria:

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": {}
    }
  }
}

Neste exemplo, “id”:101 identifica a solicitude mediante un ID para que o cliente poida emparellar as respostas, e o campo “params” contén información adicional sobre o cliente, como o nome do cliente (notes-app-client) e as súas capacidades.

Como resposta, o servidor MCP devolverá as definicións das ferramentas, que inclúen os nomes das ferramentas dispoñibles e os detalles asociados. Por exemplo, a lista podería incluír unha ferramenta add-task que permita á aplicación de notas crear tarefas nunha aplicación de xestión de tarefas ou de calendario conectada, asignando a cada tarefa un título e unha prioridade.

Así podería ser unha solicitude:

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": {}
    }
  }
}

O campo “method” indica ao servidor MCP que se trata dunha chamada a unha ferramenta, “name” especifica que ferramenta se debe chamar e “arguments” proporciona as entradas necesarias.

Se a capa de datos é o que da conexión entre un cliente e un servidor MCP, a capa de transporte é o como. Define a forma en que viaxan as mensaxes: a canle específica e as regras que rexen como se entregan as solicitudes e as respostas.

O MCP ten dúas vías de transporte:

Entrada/saída estándar: úsase cando o servidor MCP se executa no mesmo contorno local que a aplicación host. O cliente escribe a solicitude JSON na entrada estándar do servidor. O servidor le a solicitude, realiza a operación solicitada e escribe a resposta na saída estándar.
Streamable HTTP: cando o servidor MCP se executa fóra da aplicación host, o cliente MCP envía solicitudes ao servidor mediante HTTP POST. O servidor responde cunha única mensaxe JSON ou cun fluxo de Server-Sent Events (SSE), unha canle persistente de “escoita” que lle permite devolver varias mensaxes ao longo do tempo.

A arquitectura MCP multiinquilino é un tipo de implementación que pode atender a varios usuarios (inquilinos) simultaneamente.

Neste caso, un inquilino pode ser unha persoa, un grupo de persoas ou unha organización. A implementación pode consistir en executar un servidor MCP separado para cada inquilino, dar acceso a un único servidor compartido ou situar un conxunto de servidores detrás dunha pasarela central. Cando se usa unha pasarela, esta encamiña as solicitudes aos puntos finais correctos en función da identidade do usuario ou da natureza da solicitude.

Funciona segundo o mesmo principio básico que a arquitectura MCP estándar, pero as solicitudes de cada usuario operan no seu propio espazo de traballo (aínda que isto implique recursos compartidos) e autentícanse por separado. É habitual en contornos empresariais, e adoitan preferirse os recursos compartidos porque executar varios servidores MCP resultaría innecesariamente custoso.

Como é na práctica unha solicitude MCP de principio a fin? Hai oito etapas fundamentais, e cada unha delas implica un compoñente distinto da arquitectura.

Diagrama de fluxo dunha solicitude MCP de principio a fin en oito pasos: descubrimento de ferramentas, entrada do usuario, procesamento do modelo, selección da ferramenta, solicitude, execución da ferramenta, resultado e xeración da resposta.

Así funciona na práctica unha chamada a unha ferramenta MCP, co exemplo anterior dunha aplicación de notas conectada a un servizo de xestión de tarefas:

Descubrimento de ferramentas: a aplicación de notas (host) usa o seu cliente MCP para solicitar as ferramentas dispoñibles do servidor mediante unha solicitude tools/list. O servidor devolve os seus nomes, descricións e entradas esperadas, incluídas as da ferramenta add-task. Isto pode ocorrer antes de que envíes un prompt.
Entrada do usuario: envías unha solicitude á aplicación de notas baseada nun LLM a través do chatbot integrado, por exemplo: “Crea unha tarefa no meu calendario para revisar o meu novo borrador con prioridade media”.
Procesamento do modelo: o host envía a túa solicitude e as definicións das ferramentas relevantes ao LLM.
Selección da ferramenta: o LLM xera unha solicitude de ferramenta estruturada, na que especifica a ferramenta e as súas entradas: add-task con title: Revisar o borrador e priority: Medium. O host comproba se a acción está permitida e pasa a solicitude ao cliente MCP, que envía unha mensaxe JSON-RPC.
Solicitude: o cliente MCP envía unha solicitude tools/call ao seu servidor MCP.
Execución da ferramenta: o servidor MCP chama á API da aplicación de xestión de tarefas para crear unha nova tarefa co título e a prioridade especificados.
Devolución do resultado: o servidor envía o resultado de volta ao cliente MCP, que llo pasa ao host. O host engádeo á información proporcionada ao LLM.
Xeración da resposta: o LLM usa o resultado para xerar unha resposta para o usuario, como “Creei unha tarefa para revisar o borrador con prioridade media”.

O MCP e a arquitectura de API tradicional confúndense a miúdo, pero son tecnoloxías complementarias. O MCP deseñouse especificamente para aplicacións baseadas en IA. Supera a elevada carga de mantemento que supón implementar e xestionar múltiples conexións de API codificadas de forma fixa.

Ao proporcionar a unha aplicación host unha única conexión por provedor de funcionalidades ou recurso interno, o MCP axuda a resolver o problema dunha entrada de contexto sobrecargada (na que se enumeran todas as API) ou de scripts de aplicacións baseados en API limitados.

En cambio, os MCP poden expoñer API (ou, mellor dito, a funcionalidade que chama as API) como parte da súa lista de ferramentas. Sempre que un provedor actualiza a súa aplicación e hai unha nova API, ou se cambia a documentación, abonda con actualizar o servidor MCP. Non se require ningún cambio de código no lado da aplicación host.

A seguridade do MCP foi obxecto de moito debate desde a súa introdución. Aínda que en xeral se considera unha tecnoloxía segura, presenta varios riscos de seguridade, moitos dos cales son máis destacados en implementacións de arquitectura complexas.

A arquitectura MCP presenta as seguintes posibles debilidades:

Inxección de prompts: un usuario insire un prompt malicioso en datos externos que o modelo de IA interpreta erroneamente como unha instrución.
Acceso con privilexios excesivos: os servidores MCP poden expoñer un gran número de ferramentas a un modelo de IA, o que pode aumentar o potencial de problemas de seguridade (o radio de impacto).
Fugas de datos accidentais: as implementacións mal configuradas poden provocar que información confidencial, como chaves de API ou credenciais de bases de datos, se transmita a un LLM.
Manipulación do sistema local: os servidores MCP locais son tan vulnerables a problemas do sistema local, como scripts maliciosos, como calquera outra aplicación, co problema engadido de que poden ter efectos prexudiciais en cadea nos sistemas de IA axénticos.

Ningún destes problemas é insuperable. A miúdo, as medidas establecidas son todo o que se necesita para garantir a seguridade do sistema. Medidas como contar cunha persoa no circuíto de decisión, aplicar controis estritos sobre os datos confidenciais e protexerse contra ataques ao servidor son prácticas habituais.

O MCP demostrou ser un estándar aberto útil e popular entre os desenvolvedores. Supera moitos dos problemas das API codificadas de forma fixa en aplicacións baseadas en LLM e reduce considerablemente a carga de programación dos desenvolvedores.

De cara ao futuro, a arquitectura subxacente de host e servidor do MCP case con seguridade seguirá sendo a mesma. As innovacións futuras centraranse en capacidades axénticas avanzadas en fluxos de traballo de varios pasos.

Ademais, será necesario contar con salvagardas de seguridade máis sólidas conforme se implementen esas funcionalidades axénticas, así como cunha arquitectura escalable, especialmente na capa de transporte, a medida que os sistemas de IA se fagan máis extensos e complexos.

Que é a arquitectura MCP?

Compoñentes da arquitectura MCP: hosts, clientes e servidores

Host

Cliente

Servidor

Que é a capa de datos na arquitectura MCP?

Que é a capa de transporte na arquitectura MCP?

Que é a arquitectura MCP multiinquilino?

Diagrama da arquitectura MCP: percorrido paso a paso

En que se diferencia a arquitectura MCP da arquitectura de API tradicional?

É segura a arquitectura MCP?

Que lle espera á arquitectura MCP?