Qué es MCP (Model Context Protocol): guía detallada

Imagina que quieres que un asistente de IA acceda a documentos internos, a una base de datos, a un repositorio de código y a la web. Antes de MCP, la forma de hacerlo era escribir una integración aparte para cada herramienta en cada aplicación de asistente: un plugin de base de datos para el asistente del editor de código, otro plugin para la misma base de datos en la app de chat y una tercera versión para las herramientas internas. A medida que crecía el número de herramientas y aplicaciones, el número de integraciones se multiplicaba.

MCP (Model Context Protocol) lo resuelve permitiendo escribir una herramienta una sola vez como «servidor MCP» y usarla en todas las aplicaciones de IA compatibles con MCP. En este artículo explicamos qué es MCP, qué problema resuelve, su arquitectura host-cliente-servidor, las herramientas, recursos y prompts que ofrecen los servidores y los dos métodos de transporte estándar. Después vemos cómo llega un servidor MCP a los datos web y dónde encaja un proxy, los riesgos de seguridad del protocolo, la diferencia entre MCP y usar una API directamente y el servidor MCP más pequeño que funciona en Python.

¿Qué es MCP?#

Model Context Protocol es un protocolo abierto que estandariza cómo se conectan las aplicaciones de modelos de lenguaje grandes con fuentes de datos y herramientas externas. La especificación oficial del protocolo define la comunicación con mensajes JSON-RPC 2.0 y se compara con el Language Server Protocol (LSP), que estandarizó el soporte de lenguajes de programación en las herramientas de desarrollo. Igual que LSP permitió escribir una vez el soporte de un lenguaje y usarlo en cualquier editor, MCP pretende que una herramienta se escriba una vez y se use en cualquier aplicación de IA compatible con MCP.

Para entender MCP ayuda separar dos cosas:

• MCP no es un modelo ni un producto de IA. Es un contrato de comunicación: define el formato y el significado de los mensajes entre una aplicación y una herramienta.
• MCP no escribe la herramienta por ti. Una consulta a una base de datos, una petición web o una operación con archivos siguen siendo tu código; MCP permite exponer ese código de forma que las aplicaciones de IA puedan descubrirlo y llamarlo.

Las versiones de la especificación se nombran por fecha. Al escribir este artículo, la versión vigente es 2026-07-28, y trae un cambio importante respecto a las anteriores: el protocolo es sin estado (stateless); cada petición lleva su propia versión de protocolo y las capacidades del cliente. En versiones anteriores, se establecía una sesión con un handshake (initialize) al inicio de la conexión. Como el protocolo evoluciona rápido, recomendamos revisar la especificación vigente antes de escribir una integración.

¿Qué problema resuelve MCP?#

El problema que resuelve MCP es el de las «N × M integraciones». Si hay cinco aplicaciones de IA y diez herramientas, hacen falta cincuenta integraciones distintas para que cada aplicación hable con cada herramienta. Cada integración se escribe por separado, se prueba por separado y se actualiza por separado cuando cambia la herramienta.

Con MCP, esto pasa a ser «N + M»:

• Cada herramienta se escribe una vez como servidor MCP.
• Cada aplicación de IA incorpora soporte MCP una vez.
• Cualquier aplicación compatible con MCP puede usar cualquier servidor MCP.

En la práctica: cuando una empresa escribe un servidor MCP para su base de conocimiento interna, los empleados pueden llegar a esa base de conocimiento a través del mismo servidor desde el asistente de su editor de código, desde una app de chat de escritorio o desde un agente que hayan construido ellos mismos.

Arquitectura: host, cliente y servidor#

La sección de arquitectura de la especificación define tres roles.

Uno de los principios de diseño más importantes de la arquitectura es el aislamiento: un servidor no puede leer la conversación entera ni ver el interior de otros servidores. El historial de la conversación se queda en el host; el servidor solo recibe la información que necesita para hacer su trabajo. El host también controla las interacciones entre servidores.

La petición de un usuario recorre esta estructura así:

1. El usuario escribe una petición en la aplicación host.
2. El host da al modelo la lista de herramientas que ofrecen los servidores conectados, con sus descripciones.
3. El modelo decide usar una herramienta y produce una llamada a herramienta.
4. El host pide consentimiento al usuario si hace falta y pasa la llamada al cliente correspondiente.
5. El cliente envía la petición al servidor; el servidor ejecuta la herramienta y devuelve el resultado.
6. El host da el resultado al modelo, y el modelo produce una respuesta para el usuario.

Explicamos en detalle la lógica general del bucle de llamadas a herramientas en Agentes de IA: planificación, herramientas y memoria.

¿Qué ofrece un servidor MCP?#

Un servidor MCP puede ofrecer tres tipos básicos de capacidades:

• Herramientas (tools): funciones que el modelo puede pedir que se ejecuten. Obtener una página web, lanzar una consulta sobre una base de datos, crear un registro. Cada herramienta tiene un nombre, una descripción que ayuda al modelo a entender cuándo usarla y parámetros definidos con JSON Schema.
• Recursos (resources): datos que el usuario o el modelo pueden usar como contexto. El contenido de un archivo, un esquema de base de datos, un documento. A diferencia de las herramientas, no realizan acciones; aportan información.
• Prompts (plantillas de prompts): plantillas de mensajes y flujos de trabajo listos que el usuario puede elegir. Por ejemplo, una plantilla parametrizada como «analiza este registro de errores».

Los servidores también pueden pedir al cliente información adicional para completar una petición: pedir al usuario datos que faltan (elicitation) o hacer que el modelo del host genere texto (sampling). En la especificación vigente, estas solicitudes se transmiten dentro de la respuesta del servidor.

Sobre el núcleo del protocolo, funciones como la gestión de trabajos de larga duración o los elementos de interfaz interactivos dentro de una conversación se definen como extensiones opcionales; tanto el cliente como el servidor tienen que admitirlas explícitamente.

Transportes: stdio y Streamable HTTP#

Cómo se transportan los mensajes MCP entre ambas partes se define en la sección de transportes de la especificación. Hay dos métodos estándar:

El significado del protocolo es el mismo en ambos métodos; solo cambia la forma de entregar los mensajes. También pueden definirse otros métodos de transporte para necesidades especiales.

Recuerda que un servidor que funciona por stdio lo hace con todos los permisos del usuario que lo inició. Un servidor MCP que instalas en tu equipo puede acceder a tus archivos y a tu red en la misma medida que tú.

¿Cómo llega un servidor MCP a los datos web?#

Una de las capacidades que más necesitan las aplicaciones de IA son los datos web actuales. Un servidor MCP suele ofrecerlos de una de estas tres formas:

• Herramienta de búsqueda: envía una consulta a una API de búsqueda y devuelve una lista de títulos y direcciones.
• Herramienta de obtención de páginas: obtiene una dirección concreta con un cliente HTTP y devuelve su texto.
• Herramienta de navegador: controla un navegador headless; abre páginas que cargan con JavaScript, hace clic y toma capturas de pantalla.

La parte de red de estas herramientas son peticiones HTTP normales, y aquí también se aplican todas las reglas del web scraping. En este esquema, el proxy se sitúa en el punto de salida del servidor hacia el exterior:

• Ubicación: el servidor usa una dirección de un país concreto para ver cómo se muestra desde allí un producto o un contenido. Para trabajos que necesitan la vista de una conexión doméstica real se prefiere un Proxies residenciales.
• Reparto de carga: una herramienta que obtiene muchas páginas públicas distintas puede usar un Proxies rotativos para repartir las peticiones entre distintas IP de salida a través de una sola dirección; los límites de velocidad y las reglas de los sitios siguen aplicándose.
• Control y registro de la salida: qué dominios alcanza el servidor se vigila y limita desde un solo punto.
• Aislamiento: el tráfico web del servidor se mantiene separado de la red interna y de las direcciones IP principales de la empresa.

Explicamos con un ejemplo probado cómo hacer segura una herramienta de acceso web con lista de permitidos, límites de velocidad, bloqueo de la red interna y limpieza de contenido en Acceso web seguro para LLM: límites y permisos. Para la configuración general de recogida de datos, consulta nuestra página de solución de extracción de datos.

El servidor MCP más pequeño#

El ejemplo siguiente es un servidor MCP que ofrece una sola herramienta, escrito con el SDK oficial de Python. La herramienta solo obtiene páginas HTTPS de dominios permitidos y envía la petición a través de un proxy de salida opcional. En la versión 2 del SDK, la clase del servidor se llama MCPServer; los ejemplos con FastMCP de la versión 1 no funcionan directamente en esta versión.

pip install mcp httpx

# server.py
import os
from urllib.parse import urlsplit

import httpx
from mcp.server.mcpserver import MCPServer

ALLOWED = {d.strip().lower() for d in os.environ.get("ALLOWED_DOMAINS", "example.com").split(",")}
PROXY = os.environ.get("EGRESS_PROXY")  # p. ej. http://user:pass@pr.proxynet.io:8000

mcp = MCPServer("web-reader")


@mcp.tool()
async def fetch_page(url: str) -> str:
    """Devuelve los primeros 5.000 caracteres de una página de un dominio permitido."""
    parts = urlsplit(url)
    if parts.scheme != "https" or (parts.hostname or "").lower() not in ALLOWED:
        return f"Esta dirección no está en la lista de permitidos: {url}"
    async with httpx.AsyncClient(proxy=PROXY, timeout=15, follow_redirects=False) as client:
        response = await client.get(url, headers={"User-Agent": "ExampleMCP/1.0"})
    return response.text[:5000]


if __name__ == "__main__":
    mcp.run(transport="stdio")

El nombre de la función pasa a ser el nombre de la herramienta, el docstring su descripción y las anotaciones de tipo, el esquema de parámetros. El SDK convierte todo esto automáticamente en una definición de herramienta MCP.

Para llamar al servidor desde un cliente:

# client.py
import asyncio
import sys

from mcp.client.session import ClientSession
from mcp.client.stdio import StdioServerParameters, stdio_client

SERVER = StdioServerParameters(
    command=sys.executable,
    args=["server.py"],
    env={"ALLOWED_DOMAINS": "example.com", "EGRESS_PROXY": "http://user:pass@pr.proxynet.io:8000"},
)


async def main():
    async with stdio_client(SERVER) as (read, write):
        async with ClientSession(read, write) as session:
            await session.discover()  # conocer la versión y las capacidades del servidor
            tools = await session.list_tools()
            print([t.name for t in tools.tools])

            result = await session.call_tool("fetch_page", {"url": "https://example.com/"})
            print(result.content[0].text[:200])


asyncio.run(main())

Fíjate en dos detalles. Primero, antes de listar las herramientas, el cliente usa discover() para saber qué versión de protocolo y qué capacidades admite el servidor; si se omite ese paso, el servidor rechaza la petición con un error de parámetros no válidos. Para servidores con versiones de protocolo antiguas, el SDK también tiene una llamada initialize(). Segundo, cuando el SDK inicia un servidor stdio, no le pasa todas las variables de entorno, solo una lista limitada como PATH; los valores que necesita el servidor, como ALLOWED_DOMAINS y EGRESS_PROXY, deben pasarse explícitamente con el parámetro env.

En el uso real no escribes tú el cliente; añades el servidor a la configuración de una aplicación host compatible con MCP, y el host lo inicia. Este cliente de ejemplo basta para comprobar que el servidor funciona correctamente.

El ejemplo es pequeño a propósito. En producción habría que añadir a esta herramienta límites de velocidad, una comprobación de direcciones de red interna, un límite de tamaño de respuesta y limpieza de contenido.

Riesgos de seguridad#

Que las herramientas MCP puedan ejecutar código arbitrario y obtener contenido de fuentes externas hace que el protocolo sea tan arriesgado como potente. La propia especificación enumera como principios básicos el consentimiento del usuario, la privacidad de los datos y la seguridad de las herramientas, y pide a los hosts obtener el consentimiento explícito del usuario antes de invocar una herramienta. Los riesgos principales son:

• Envenenamiento de herramientas (tool poisoning). Como el modelo decide cómo usar una herramienta leyendo su descripción, un servidor malicioso puede esconder en la descripción instrucciones dirigidas al modelo. La especificación indica que las descripciones y anotaciones de las herramientas deben considerarse no fiables salvo que procedan de un servidor de confianza.
• Permisos excesivos. Dar a un servidor más acceso del que necesita: escritura para un trabajo que solo requiere lectura, todo el sistema de archivos en lugar de una carpeta, una cuenta de administrador en lugar de una tabla de la base de datos.
• Inyección de prompts a través de los resultados de las herramientas. El contenido que devuelve una herramienta de obtención de páginas puede contener texto que parece una instrucción para el modelo. Siguiendo esas instrucciones, el modelo puede llamar a una herramienta de otro servidor.
• Reenviar tokens. Que un servidor MCP reenvíe a otros servicios el token de acceso que recibió sin validarlo puede hacer que se salten comprobaciones de autorización. El documento de recomendaciones de seguridad del protocolo prohíbe explícitamente este reenvío de tokens y exige que los servidores acepten solo tokens emitidos para ellos.
• SSRF. Un servidor malicioso puede hacer que el cliente envíe peticiones a direcciones de la red interna o a direcciones de metadatos de la nube durante el proceso de autorización.
• Servidores locales no fiables. Como los servidores stdio funcionan con los permisos del usuario, instalar un servidor de origen no verificado equivale a ejecutar un programa no verificado.

Medidas prácticas:

• Instala solo servidores cuyo origen conozcas y cuyo código puedas revisar.
• Da a cada servidor el mínimo privilegio; separa en herramientas distintas acciones como escribir y borrar.
• No desactives el consentimiento del usuario en las llamadas a herramientas con efectos secundarios.
• Marca como datos no fiables la salida de las herramientas que obtienen contenido web.
• En los servidores remotos, valida la audiencia del token y no reenvíes tokens.
• Registra las llamadas a herramientas y vigila secuencias de llamadas inesperadas.

La diferencia entre MCP y una API#

MCP no sustituye a una API; la mayoría de los servidores MCP ya envuelven una. La diferencia está en para quién están diseñados.

¿MCP o una API directa?#

Casos de uso#

• Herramientas para desarrolladores: que el asistente del editor de código lea el repositorio, los registros de errores y la documentación.
• Acceso al conocimiento interno: que los asistentes de los empleados busquen en la wiki interna, los tickets de soporte y la documentación de producto.
• Análisis de datos: exponer una base de datos como servidor MCP de solo lectura para que los analistas consulten en lenguaje natural.
• Investigación web: agentes que llegan a información actual mediante una herramienta de obtención de páginas con lista de permitidos y límites de velocidad. Para un ejemplo de cómo pueden usarse los modelos de lenguaje para extraer información estructurada de datos web, consulta Web scraping con GPT-6 Astra.
• Herramientas de operaciones: leer métricas de los sistemas de monitorización y generar resúmenes de incidentes; las acciones de intervención, en herramientas separadas que requieren aprobación.

Errores comunes#

• Instalar servidores de origen desconocido. Instalar un servidor MCP requiere la misma confianza que ejecutar un programa.
• Dar todos los permisos a un servidor. No separar las herramientas de lectura y de escritura.
• Escribir descripciones de herramientas cortas y vagas. El modelo llama a la herramienta en la situación equivocada.
• Tratar los resultados de las herramientas como contenido fiable. El contenido web y de documentos puede llevar instrucciones.
• Desactivar los pasos de consentimiento. El consentimiento del usuario es una capa de seguridad básica, sobre todo en herramientas con efectos secundarios.
• No comprobar la versión de la especificación. Como el protocolo evoluciona rápido, los ejemplos escritos para versiones antiguas pueden no funcionar con los SDK actuales.

Preguntas frecuentes#

¿Quién desarrolló MCP?#

MCP lo anunció Anthropic como protocolo abierto y se desarrolla como proyecto de código abierto con su especificación, sus SDK y su documentación. Aplicaciones y herramientas de IA de distintas empresas admiten el protocolo.

¿MCP solo funciona con un modelo de IA concreto?#

No. MCP define la comunicación entre una aplicación y una herramienta y es independiente del modelo. Use el modelo que use la aplicación host, esta ofrece a ese modelo las herramientas de los servidores MCP.

¿En qué lenguajes puedo escribir un servidor MCP?#

El proyecto ofrece SDK oficiales para muchos lenguajes, empezando por Python y TypeScript. Como el protocolo se basa en JSON-RPC, también se puede escribir un servidor en un lenguaje sin SDK siguiendo la especificación.

¿Qué diferencia hay entre MCP y function calling?#

Function calling es la capacidad de un modelo de producir llamadas a herramientas estructuradas y es propia de la API de cada proveedor de modelos. MCP es el protocolo que permite definir, descubrir y llamar esas herramientas de forma estándar entre aplicaciones. El host ofrece al modelo, mediante function calling, las herramientas que obtiene de los servidores MCP.

¿Cómo elijo entre un servidor MCP local y uno remoto?#

Para uso personal y acceso a archivos locales basta con un servidor local por stdio. Para herramientas que compartirá un equipo o una empresa y que deben gestionarse y autorizarse de forma centralizada, encaja un servidor remoto por Streamable HTTP.

¿Cómo se usa un proxy cuando un servidor MCP accede a la web?#

El proxy se pasa al cliente HTTP o al navegador que hay dentro del servidor; no tiene nada que ver con el protocolo MCP en sí. En el ejemplo anterior, la dirección del proxy se lee de una variable de entorno y se pasa al cliente HTTP, de modo que todo el tráfico web del servidor sale por un punto controlado.

En resumen#

MCP es un protocolo abierto que conecta de forma estándar las aplicaciones de IA con herramientas y fuentes de datos. Cada cliente dentro de una aplicación host se conecta a un servidor; los servidores ofrecen herramientas, recursos y plantillas de prompts; los mensajes se transportan con JSON-RPC por stdio o Streamable HTTP. La especificación vigente ha pasado a una estructura sin estado y el protocolo evoluciona rápido. Como las herramientas pueden ejecutar código y obtener contenido externo, el mínimo privilegio, el consentimiento del usuario, el tratamiento del contenido no fiable y el registro deben formar parte del diseño. Para gestionar el acceso web de tus servidores MCP con control de ubicación y de salida, echa un vistazo a nuestros servicios de proxy.