MCP - model context protocol

MCP (Model Context Protocol) estandariza cómo un cliente LLM descubre, lista y llama capacidades expuestas por servidores: tools (acciones), resources (datos) y prompts (plantillas). Una interfaz única para integrarse con cualquier fuente.

Anthropic MCPMCP Python SDKMCP TypeScript SDKFastMCP

Qué es

MCP () es un protocolo abierto que estandariza la conversación entre un cliente LLM (el host, generalmente un IDE o una app de chat) y servidores externos que exponen capacidades. En vez de que cada proveedor de herramientas invente su propia API, todo servidor MCP habla el mismo JSON-RPC y todo cliente MCP descubre todo de la misma forma.

Piensa en USB-C para agentes. La pieza física cambió una vez; el ecosistema ganó. La misma idea aquí: el protocolo cambia una vez, y un servidor escrito para Claude Desktop funciona en Cursor, en Continue y en cualquier host que reenvíe el mensaje.

las observaciones de este tema están fijadas a la revisión 2025-06-18 de la especificación del Model Context Protocol. Releases posteriores pueden introducir capacidades nuevas (sampling, elicitation, roots) y cambiar contratos existentes; verifica la versión de la spec que declara el SDK antes de adoptar.

Host, client y server: la topología

Tres roles coexisten en la especificación. Confundirlos es el error más común al leer la documentación.

host: la aplicación donde está el usuario (IDE, chat, agente). Aloja a los clientes y coordina permisos. En general un host corre muchos clientes.

client: vive dentro del host, habla con un único servidor vía JSON-RPC. Es el objeto que serializa las llamadas y negocia las capabilities.

server: el proceso que expone tools, resources y prompts. Puede correr localmente vía stdin/stdout, o remotamente vía HTTP con SSE. Es donde vive la lógica de integración.

El transporte local típico es stdio: el host lanza el server como subproceso y habla JSON-RPC línea a línea. En entornos distribuidos, el transporte es Streamable HTTP, con POST para mensajes y GET con text/event-stream para notificaciones.

topología típicatext

  Host (Claude Desktop, Cursor, VS Code, app propia)
  |
  | 1:N
  |
  +-- Client MCP (stdio)   <--> Server MCP local  (ej: filesystem)
  +-- Client MCP (stdio)   <--> Server MCP local  (ej: postgres)
  +-- Client MCP (HTTP+SSE)<--> Server MCP remoto (ej: API SaaS)

  El transporte siempre es JSON-RPC 2.0. El estado de sesión es por conexión.

Tools, resources y prompts

El server expone tres tipos de capacidad, cada uno con un rol claro en el ciclo del agente:

tools: acciones que el modelo puede invocar. Análogas a las function calls: nombre, schema JSON, efectos secundarios. El LLM elige cuándo llamar según la descripción.

resources: datos que el host puede leer. Pasivos, identificados por nombre o URI (ej: file:///docs/spec.pdf, db://customers/42). El host decide cuándo incluirlos en el contexto; el modelo solo ve el contenido que el host eligió.

prompts: plantillas de prompt que el usuario invoca explícitamente (ej: '/summarize este archivo'). El modelo no las descubre; quedan como slash commands en el host.

manifest de un server MCPjson

{
  "name": "docs-server",
  "version": "0.2.1",
  "capabilities": {
    "tools":     { "listChanged": true },
    "resources": { "subscribe":   true, "listChanged": true }
  },
  "tools": [
    {
      "name": "search_docs",
      "description": "Busca pasajes relevantes en la base de documentación.",
      "inputSchema": {
        "type": "object",
        "properties": {
          "query":   { "type": "string" },
          "top_k":   { "type": "integer", "default": 5 }
        },
        "required": ["query"]
      }
    }
  ],
  "resources": [
    {
      "uri":  "file:///docs/architecture.md",
      "name": "arquitectura",
      "mimeType": "text/markdown"
    }
  ]
}

Cómo el cliente descubre capacidades

Cuando el host levanta un client MCP, el primer mensaje es initialize, con la versión del protocolo y las capabilities del cliente. El server responde con sus propias capabilities. De ahí en adelante, el host llama a tools/list, resources/list y prompts/list para armar el catálogo disponible.

Cada capacidad puede declarar listChanged: true, indicando que el server emitirá notifications/resources/list_changed o notifications/tools/list_changed cuando algo cambie. El host vuelve a listar y actualiza el catálogo sin necesidad de reiniciar.

client.tsxtypescript

import { Client } from '@modelcontextprotocol/sdk/client/index.js';
import { StdioClientTransport } from '@modelcontextprotocol/sdk/client/stdio.js';

const transport = new StdioClientTransport({
  command: 'npx', args: ['-y', '@modelcontextprotocol/server-filesystem', '/docs'],
});

const client = new Client({ name: 'host', version: '1.0.0' }, { capabilities: {} });
await client.connect(transport);

const { tools }     = await client.listTools();     // -> catálogo para el LLM
const { resources } = await client.listResources(); // -> datos disponibles

const result = await client.callTool({
  name: 'search_docs',
  arguments: { query: 'cómo funciona el checkpoint', top_k: 3 },
});

Puntos fuertes

interoperabilidad: un server MCP sirve a varios hosts sin reescritura; cambiar de IDE no es reescribir la integración
descubrimiento dinámico: tools y resources aparecen en tiempo de conexión, sin reiniciar el host
separación clara de roles: tools son acciones, resources son datos, prompts son plantillas, sin ambigüedad
transporte flexible: stdio para local, HTTP+SSE para distribuido; el contrato sobre el cable es el mismo

Limitaciones

las tools siguen siendo acciones del modelo: el server puede llamar APIs peligrosas, y la autorización y el sandboxing quedan a cargo del host
la spec evoluciona rápido: 2025-06-18 es la versión fijada de este tema; sampling/elicitation/roots son áreas en expansión
depurar en remoto es más difícil: HTTP+SSE esconde el ciclo de vida; los logs y los handlers son igual de importantes
trust on first connect: el host necesita confiar en el server; la firma de paquetes y las allowlists siguen siendo responsabilidad del deployment

MCPModel Context ProtocolUn protocolo abierto para conectar agents con herramientas y fuentes de datos mediante servidores. Cada servidor que conectas amplía lo que el agent puede hacer y, por lo tanto, también amplía la superficie de ataque.ver en el glosario →

conexiones en el mapa

Tool callinghabla el protocoloMCP - model context protocol

actualizado el 14/10/2026 · fuentes para profundizar · reportar un error

en otros dominios

Proteger al propio agentvibecodingcada servidor MCP conectado amplía lo que el agente puede hacer
Secrets Scanningappseclos tokens de servidores MCP se filtran de la misma manera

Estudia antes

Tool calling

pon a prueba lo que entendiste

Cargando preguntas…