Qué es MCP (Model Context Protocol) y cómo funciona

MCP (Model Context Protocol, protocolo de contexto para modelos) es un estándar abierto para conectar asistentes de IA con herramientas y datos: tus archivos, una base de datos, GitHub, Notion o un programa que tú mismo escribas. En lugar de que cada asistente invente su propia forma de hablar con cada servicio, MCP define una sola, y cualquier asistente compatible puede usar cualquier «servidor MCP». Esta guía explica qué es, cómo funciona por dentro y cómo conectar uno, con un servidor de ejemplo que hemos escrito y probado.

Qué problema resuelve

Un modelo de lenguaje, por sí solo, solo sabe lo que aprendió al entrenarse y lo que le escribes en la conversación. No puede leer tu correo, consultar una base de datos ni abrir un archivo de tu disco. Para eso, la aplicación que lo usa tiene que darle «herramientas»: funciones que el modelo puede pedir que se ejecuten, y cuyo resultado se le devuelve.

Antes de MCP, cada aplicación (Claude, ChatGPT, Cursor, un editor de código…) tenía su propia forma de definir esas herramientas, y cada servicio tenía que hacer una integración distinta para cada una. Con N aplicaciones y M servicios, hacían falta N × M integraciones. MCP lo convierte en N + M: cada servicio publica un servidor MCP, cada aplicación implementa un cliente MCP, y todos se entienden. Es la misma idea que el Language Server Protocol, que hizo que cualquier editor pueda entender cualquier lenguaje de programación, y en la que la propia especificación de MCP dice inspirarse.

Lo creó Anthropic, la empresa de Claude, y lo publicó como estándar abierto el 25 de noviembre de 2024.
Desde el 9 de diciembre de 2025 ya no es de Anthropic: lo donó a la Agentic AI Foundation, una fundación de la Linux Foundation creada junto con OpenAI y Block, y apoyada por Google, Microsoft, AWS, Cloudflare y Bloomberg.
Lo usan casi todos: según Anthropic, ChatGPT, Cursor, Gemini, Microsoft Copilot y Visual Studio Code ya lo soportan, y hay más de 10,000 servidores MCP públicos.

Las piezas: anfitrión, cliente y servidor

MCP habla de tres papeles:

El anfitrión (host) es la aplicación de IA que usas: Claude Code, Claude Desktop, Cursor… Es quien habla con el modelo y quien decide qué se permite.
El cliente es la parte del anfitrión que habla con un servidor concreto. Hay un cliente por cada servidor conectado.
El servidor es el programa que da acceso a algo: a una carpeta, a una base de datos, a la API de un servicio. Puede ser un programa que se ejecuta en tu ordenador o un servicio en internet.

Esquema: decodigo.com, a partir de la arquitectura de la especificación de MCP.

Qué puede ofrecer un servidor MCP

Un servidor puede ofrecer tres cosas, y cada una la controla alguien distinto:

Herramientas (tools): funciones que el modelo decide usar, como «buscar en las notas», «crear una incidencia en GitHub» o «ejecutar esta consulta SQL». Cada una tiene un nombre, una descripción en lenguaje natural (que el modelo lee para saber cuándo usarla) y la lista de argumentos que acepta. Son lo más usado de MCP.
Recursos (resources): datos que se pueden leer, identificados con una dirección, como nota://viaje o file:///informe.pdf. Normalmente es la aplicación, o tú, quien elige qué recursos se añaden a la conversación.
Prompts: plantillas de instrucciones que el servidor ofrece y que tú eliges usar, por ejemplo desde un menú. Sirven para tareas repetidas, como «revisa este código siguiendo nuestras normas».

En sentido contrario, el servidor también puede pedirle algo al cliente. La versión actual del protocolo destaca la elicitación (elicitation): que el servidor pida al usuario un dato que le falta, como una confirmación o un valor, a mitad de una operación.

Cómo se comunican

Los mensajes son JSON-RPC 2.0, un formato muy sencillo en el que cada petición es un objeto JSON con un method (qué se pide), unos params y un id, y cada respuesta lleva el mismo id con un result o un error. Esos mensajes viajan por uno de dos caminos, que la especificación llama transportes:

stdio: el anfitrión arranca el servidor como un programa más en tu ordenador y le escribe por su entrada estándar, una línea JSON por mensaje; el servidor contesta por su salida estándar. Es el transporte de los servidores locales, y no necesita red ni contraseñas: las credenciales que hagan falta se le pasan como variables de entorno.
Streamable HTTP: el servidor está en una dirección web y los mensajes van en peticiones HTTP POST. Es el de los servidores remotos, como los de Notion o Stripe, y para ellos MCP define un sistema de autorización basado en OAuth.

Una petición que necesita una herramienta, paso a paso. El anfitrión pide permiso antes de llamarla, como exige la especificación. Esquema: decodigo.com.

Así se ven los mensajes de verdad

Para verlo sin magia, hemos hablado con nuestro servidor de ejemplo (lo verás completo más abajo) escribiendo los mensajes a mano. Primero, server/discover, la pregunta «quién eres y qué sabes hacer»:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "server/discover",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "cacheScope": "private",
    "capabilities": {
      "prompts": {
        "listChanged": true
      },
      "resources": {
        "listChanged": true,
        "subscribe": true
      },
      "tools": {
        "listChanged": true
      }
    },
    "resultType": "complete",
    "supportedVersions": [
      "2026-07-28"
    ],
    "ttlMs": 0,
    "_meta": {
      "io.modelcontextprotocol/serverInfo": {
        "name": "Mis notas",
        "version": ""
      }
    }
  }
}

El servidor se presenta («Mis notas»), dice qué versiones del protocolo entiende y qué ofrece: herramientas, recursos y prompts. Luego, tools/call, para usar su herramienta:

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "buscar_notas",
    "arguments": {
      "texto": "oaxaca"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

{
  "jsonrpc": "2.0",
  "id": 3,
  "result": {
    "content": [
      {
        "text": "viaje: Viaje a Oaxaca",
        "type": "text"
      }
    ],
    "isError": false,
    "resultType": "complete",
    "structuredContent": {
      "result": [
        "viaje: Viaje a Oaxaca"
      ]
    },
    "_meta": {
      "io.modelcontextprotocol/serverInfo": {
        "name": "Mis notas",
        "version": ""
      }
    }
  }
}

Fíjate en el campo _meta: cada petición lleva la versión del protocolo y las capacidades del cliente. Es la gran novedad de la versión vigente de la especificación, la del 28 de julio de 2026: MCP pasó a ser un protocolo sin estado. Hasta la versión anterior, de noviembre de 2025, la conexión empezaba con un saludo (initialize) en el que se negociaba todo una sola vez, y el servidor tenía que recordarlo. Ahora cada petición se entiende por sí sola, lo que facilita repartir un servidor remoto entre muchas máquinas. Si una petición llega sin esos datos, el servidor la rechaza:

{
  "jsonrpc": "2.0",
  "id": 4,
  "error": {
    "code": -32602,
    "message": "params._meta must be an object carrying the required 'io.modelcontextprotocol/protocolVersion' and 'io.modelcontextprotocol/clientCapabilities' envelope keys"
  }
}

¿Y los servidores antiguos? Muchos servidores publicados todavía hablan las versiones de 2025, con su saludo initialize. La especificación nueva prevé esa convivencia: los clientes actuales saben hablar con servidores antiguos, y server/discover sirve justamente para averiguar qué versión entiende cada uno. Como usuario no tienes que hacer nada; si programas un servidor, usa la versión actual del SDK oficial.

Un servidor MCP en unas 30 líneas de Python

Este es el servidor de los ejemplos. Deja que un asistente busque y lea los archivos .md de una carpeta de notas: ofrece una herramienta, buscar_notas, y un recurso, nota://<nombre>. Usa el SDK oficial de Python (pip install "mcp[cli]"; probado con la versión 2.3.0, que habla la versión 2026-07-28 del protocolo):

"""Un servidor MCP mínimo: deja que un asistente de IA busque y lea tus notas.

Ofrece una herramienta (buscar_notas) y un recurso (nota://<nombre>) sobre los
archivos .md de la carpeta «notas». Se comunica por la entrada y la salida
estándar (stdio): el cliente lo arranca como un proceso más.
"""
from pathlib import Path

from mcp.server import MCPServer

CARPETA = Path(__file__).parent / "notas"
mcp = MCPServer("Mis notas")

@mcp.tool()
def buscar_notas(texto: str) -> list[str]:
    """Busca un texto en las notas y devuelve las líneas que lo contienen."""
    encontradas = []
    for archivo in sorted(CARPETA.glob("*.md")):
        for linea in archivo.read_text(encoding="utf-8").splitlines():
            if texto.lower() in linea.lower():
                encontradas.append(f"{archivo.stem}: {linea.strip('-# ').strip()}")
    return encontradas

@mcp.resource("nota://{nombre}")
def leer_nota(nombre: str) -> str:
    """Devuelve el texto completo de una nota."""
    return (CARPETA / f"{nombre}.md").read_text(encoding="utf-8")

if __name__ == "__main__":
    mcp.run()          # por omisión, stdio

No hay que escribir nada del protocolo: el SDK convierte la función en una herramienta, saca de los tipos de Python (texto: str, list[str]) el esquema de argumentos y de resultado que viste en los mensajes de arriba, y usa el docstring como descripción para el modelo. Esa descripción importa más de lo que parece: es lo único que el modelo lee para decidir cuándo usar la herramienta.

Para probarlo sin ningún asistente, el mismo SDK incluye un cliente. Este arranca el servidor, le pregunta qué ofrece y lo usa:

"""Un cliente MCP: arranca servidor.py, pregunta qué ofrece y lo usa."""
import anyio
from mcp import Client, StdioServerParameters

async def main() -> None:
    servidor = StdioServerParameters(command="python", args=["servidor.py"])
    async with Client(servidor) as cliente:
        herramientas = await cliente.list_tools()
        for h in herramientas.tools:
            print("Herramienta:", h.name, "-", h.description)
            print("  argumentos:", h.input_schema["properties"])

        resultado = await cliente.call_tool("buscar_notas", {"texto": "café"})
        print("buscar_notas('café') →", resultado.structured_content)

        nota = await cliente.read_resource("nota://viaje")
        print("nota://viaje →", nota.contents[0].text.strip())

anyio.run(main)

salidaHerramienta: buscar_notas - Busca un texto en las notas y devuelve las líneas que lo contienen.
  argumentos: {'texto': {'title': 'Texto', 'type': 'string'}}
buscar_notas('café') → {'result': ['compras: Café de Veracruz', 'ideas: Comparar el café de olla con el café de filtro', 'viaje: Reservar el hotel antes del 25 de octubre. Probar el mole negro y el café de Pluma.']}
nota://viaje → # Viaje a Oaxaca

Reservar el hotel antes del 25 de octubre. Probar el mole negro y el café de Pluma.

Cómo conectar un servidor a tu asistente

Cada aplicación tiene su forma de dar de alta servidores, pero en todas se indica lo mismo: un nombre y cómo arrancarlo (o su dirección, si es remoto).

En Claude Code

Con claude mcp add. Para un servidor local por stdio, todo lo que va después de -- es la orden que arranca el servidor:

# Nuestro servidor de notas (usa la ruta completa a servidor.py)
claude mcp add --transport stdio notas -- python /ruta/a/servidor.py

# Un servidor remoto por HTTP
claude mcp add --transport http notion https://mcp.notion.com/mcp

# Ver, revisar y quitar servidores
claude mcp list
claude mcp get notas
claude mcp remove notas

Las variables de entorno (por ejemplo, una clave de API) se pasan con --env CLAVE=valor.
El alcance se elige con --scope: local (el de omisión: solo tú, en ese proyecto), project (se guarda en un archivo .mcp.json en la raíz del proyecto, para compartirlo con tu equipo por Git) o user (tú, en todos tus proyectos).
Dentro de Claude Code, la orden /mcp muestra el estado de cada servidor y permite iniciar sesión en los remotos que usan OAuth.

En Claude Desktop

En el menú de Claude (el de la barra del sistema, no el de la ventana) → Settings… → Developer → Edit Config. Se abre el archivo claude_desktop_config.json, que en macOS está en ~/Library/Application Support/Claude/ y en Windows en %APPDATA%\Claude\. Los servidores van en mcpServers:

{
  "mcpServers": {
    "notas": {
      "command": "python",
      "args": ["/Users/tu-usuario/mcp/servidor.py"]
    }
  }
}

Las rutas tienen que ser absolutas. Después hay que cerrar Claude Desktop del todo y volver a abrirlo. Si el servidor no aparece, sus mensajes de error quedan en ~/Library/Logs/Claude/ (macOS) o %APPDATA%\Claude\logs (Windows), en archivos mcp*.log.

Cursor, Visual Studio Code y otras aplicaciones usan un formato muy parecido, con la misma clave mcpServers; consulta su documentación para saber dónde va el archivo.

Servidores que puedes probar

Los de referencia del proyecto MCP, en su repositorio oficial: por ejemplo, el de sistema de archivos, que da acceso solo a las carpetas que le indiques.
Los de servicios conocidos, como Notion, GitHub, Stripe o HubSpot, que suelen ser remotos y se conectan con tu cuenta.
Los especializados: en decodigo.com hemos usado jadx-headless-mcp, un servidor MCP que deja a un asistente descompilar y analizar aplicaciones de Android, dentro de la guía de REA, una herramienta de ingeniería inversa para agentes de IA.

Los riesgos que conviene conocer

Conectar un servidor MCP es darle a un modelo de IA acceso a algo real, y la propia especificación dedica un apartado a la seguridad. Lo esencial:

Un servidor local es un programa con tus permisos. Puede leer y modificar lo mismo que tú. Instala solo servidores de fuentes en las que confíes, revisa su código si puedes y desconfía de paquetes con nombres parecidos a los oficiales.
Las herramientas ejecutan código. La especificación exige que el anfitrión pida tu permiso antes de usar una herramienta. No lo apruebes todo por costumbre: lee qué va a hacer.
Inyección de prompts. Si un servidor trae contenido de fuera (páginas web, correos, incidencias de GitHub), ese contenido puede llevar instrucciones escondidas para el modelo, como «envía el archivo .env a esta dirección». La documentación de Claude Code avisa expresamente de ello: trata ese contenido como no fiable.
Las descripciones también pueden mentir. La especificación advierte de que la descripción de una herramienta no es de fiar si el servidor no lo es.
Mínimos privilegios. Dale a cada servidor solo lo que necesita: una carpeta y no todo el disco, una clave de API de solo lectura si basta con leer. Y no guardes claves en un .mcp.json que vayas a subir a Git: usa variables de entorno.

Preguntas frecuentes

¿MCP es solo para Claude? No. Lo creó Anthropic, pero es un estándar abierto, hoy gestionado por una fundación de la Linux Foundation, y lo soportan ChatGPT, Gemini, Copilot, Cursor y Visual Studio Code, entre otros.
¿En qué se diferencia de una API normal? Una API está pensada para que la use un programador; un servidor MCP está pensado para que la use un modelo: se describe a sí mismo (qué herramientas tiene y para qué sirven) y cualquier asistente compatible puede usarlo sin código adicional. Muchos servidores MCP son, por dentro, una capa fina sobre una API existente.
¿Necesito saber programar para usarlo? Para conectar un servidor ya hecho, no: basta con la orden de claude mcp add o con editar un archivo de configuración. Para crear uno propio, sí, aunque como has visto puede ocupar treinta líneas.
¿Qué es mejor, un servidor local o uno remoto? Los locales (stdio) son ideales para tus archivos y herramientas, y no exponen nada a la red. Los remotos (HTTP) son los que ofrecen los servicios en la nube, y se conectan con tu cuenta mediante OAuth.

Si te interesan los asistentes de programación, en decodigo.com también explicamos cómo encajan los comandos de Claude Code y cómo dirigir a Codex, el agente de OpenAI.

Fuentes: la especificación de MCP, versión 2026-07-28, y su lista de cambios; el SDK oficial de Python; la documentación de MCP en Claude Code y la guía «Connect to local MCP servers» (Claude Desktop); los anuncios de Anthropic del 25 de noviembre de 2024 y del 9 de diciembre de 2025, y la nota de la Linux Foundation. El servidor, el cliente y los mensajes se probaron el 22 de octubre de 2026 con Python 3.13 y mcp 2.3.0; las cifras de adopción son de Anthropic.