Qué es MCP

Un modelo de lenguaje solo conoce lo que estaba en su entrenamiento y en el prompt. Para leer tu base de datos, consultar un calendario o abrir un issue en GitHub, necesita un puente hacia esos sistemas. Sin un estándar común, cada aplicación de IA construye ese puente por su cuenta, servicio por servicio.

MCP (Model Context Protocol) es ese estándar común. La documentación oficial lo compara con un puerto USB-C para aplicaciones de IA: un solo conector en lugar de un cable distinto para cada aparato.

¿Qué problema resuelve MCP?#

Sin estándar, conectar N aplicaciones de IA con M servicios exige hasta N por M integraciones, cada una con su formato. Con MCP, cada aplicación implementa el lado cliente una vez y cada servicio implementa el lado servidor una vez. A partir de ahí, cualquiera puede hablar con cualquiera.

El protocolo solo cubre el intercambio de contexto. Cómo la aplicación usa el modelo y conduce la conversación queda en manos de quien la construye. Si todavía no sabes cómo funciona un modelo, empieza por qué es un LLM.

Según la documentación, MCP ya es compatible con asistentes como Claude y ChatGPT y con herramientas de desarrollo como Visual Studio Code y Cursor.

¿Cuáles son las piezas de MCP?#

Son tres roles:

• Host: la aplicación de IA que abre el usuario, como un asistente de chat o un editor de código.
• Cliente: un componente dentro del host que mantiene la conexión con un servidor. El host crea un cliente por servidor.
• Servidor: el programa que aporta contexto y funciones. Puede correr en tu máquina o en otro lugar.

Un ejemplo de la documentación: Visual Studio Code es el host. Al conectarse a un servidor de Sentry, crea un cliente para ese servidor; al conectarse a un servidor de sistema de archivos, crea otro.

Los mensajes usan JSON-RPC 2.0, un formato de llamada remota. Si conoces las APIs REST, la diferencia es que aquí el contrato incluye descubrimiento: el cliente le pregunta al servidor qué sabe hacer.

¿Qué ofrece un servidor MCP?#

Un servidor expone hasta tres tipos de recurso:

Cada tipo tiene métodos de listado (tools/list, por ejemplo) y, en el caso de las tools, de ejecución (tools/call). Como el cliente lista los recursos en tiempo de ejecución, el servidor puede cambiar lo que ofrece sin reescribir la aplicación.

Las tools son el recurso más usado. Cada una tiene un nombre, una descripción en texto y un esquema JSON de sus argumentos. El modelo lee la descripción para decidir cuándo llamarla, así que una descripción clara importa tanto como el código.

¿Cómo se comunican cliente y servidor?#

El protocolo tiene dos capas: la de datos (los mensajes JSON-RPC) y la de transporte (cómo viajan). Hay dos transportes estándar:

• stdio: el cliente inicia el servidor como un proceso local e intercambia mensajes por la entrada y salida estándar. Es el transporte de los servidores locales, sin red.
• Streamable HTTP: cada mensaje es un POST HTTP a un único endpoint, como https://ejemplo.com/mcp. La respuesta llega como un objeto JSON o como un flujo SSE. Es el transporte de los servidores remotos, que atienden a muchos clientes.

Desde la revisión 2026-07-28 de la especificación, el protocolo es sin estado: cada solicitud lleva la versión del protocolo y las capacidades del cliente, y el servidor responde server/discover para anunciar lo que soporta. Las versiones anteriores usaban un handshake initialize y sesiones. El antiguo transporte HTTP+SSE está obsoleto.

Una llamada a una tool, a nivel de protocolo, es un JSON como este (se omiten los campos _meta con versión y capacidades):

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "weather_current",
    "arguments": { "location": "San Francisco", "units": "imperial" }
  }
}

La respuesta trae una lista content con bloques de contenido, como texto, imagen o recurso. En la práctica no escribes ese JSON: escribes una función y el SDK arma los mensajes.

¿Cómo crear un servidor MCP mínimo?#

Con el SDK oficial de Python, una tool es una función con tipos y docstring. Crea el proyecto e instala el SDK:

uv init pedidos
cd pedidos
uv add "mcp[cli]"

En pedidos.py:

from mcp.server import MCPServer

mcp = MCPServer("pedidos")

PEDIDOS = {  # datos de ejemplo, en lugar de una base real
    "1001": "enviado",
    "1002": "pendiente de pago",
}


@mcp.tool()
async def estado_del_pedido(numero: str) -> str:
    """Consulta el estado de un pedido.

    Args:
        numero: Número del pedido, por ejemplo 1001
    """
    return PEDIDOS.get(numero, "pedido no encontrado")


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

Ejecuta uv run pedidos.py para iniciar el servidor por stdio. Para probar sin una aplicación de IA, usa el MCP Inspector, la herramienta oficial de depuración.

Para conectarlo a Claude Desktop, agrega el servidor al archivo claude_desktop_config.json, cambiando la ruta por la tuya:

{
  "mcpServers": {
    "pedidos": {
      "command": "uv",
      "args": ["--directory", "/ruta/a/pedidos", "run", "pedidos.py"]
    }
  }
}

Reinicia la aplicación y la tool aparecerá disponible. Con stdio, nunca escribas logs con print() en la salida estándar: ahí viajan los mensajes del protocolo y el texto extra corrompe la conversación. Usa stderr.

El SDK oficial de TypeScript (@modelcontextprotocol/server) sigue el mismo diseño: registras tools con un esquema zod y sirves por stdio.

¿Cuáles son los riesgos y límites?#

MCP le da al modelo la capacidad de actuar, y eso exige cuidado. La especificación recomienda mantener siempre a una persona en el circuito, con poder para denegar llamadas a tools. La aplicación debe mostrar al usuario qué tools están expuestas y pedir confirmación en operaciones sensibles.

• Demasiados permisos: un servidor con acceso de escritura a tu base de datos puede borrar datos si el modelo se equivoca. Da solo el acceso necesario y, siempre que puedas, prefiere tools de solo lectura.
• Servidor no confiable: la especificación indica que el cliente debe tratar las anotaciones de tools como no confiables, salvo que vengan de un servidor confiable. Instala solo servidores de fuentes que audites.
• Inyección de prompt: el texto de un correo, una página o un issue puede traer instrucciones que intentan engañar al modelo para que llame tools que no querías. La aprobación humana en acciones destructivas es la defensa más simple.
• Servidor remoto expuesto: valida el encabezado Origin, exige autenticación y, si corre en local, escucha solo en 127.0.0.1, como recomienda la especificación.

No todo proyecto necesita MCP. Con una sola aplicación y tres funciones, declararlas directamente en la API del modelo es más simple. El protocolo vale la pena cuando las mismas herramientas sirven a varios clientes.

¿Cómo se relaciona MCP con otros términos?#

• Function calling / tool use: la capacidad del modelo de pedir que se ejecute una función. MCP estandariza de dónde vienen las funciones y cómo la aplicación las ejecuta.
• Agente: un sistema en el que el modelo decide, en bucle, qué tools llamar. Los agentes suelen usar servidores MCP como fuente de tools.
• API REST: un servidor MCP suele envolver una API REST y traducirla a tools que el modelo entiende.

Si tu tool va a generar llamadas de pago al modelo, mira también cuánto cuesta usar la API de un LLM.

Cómo hacerlo en Square Cloud#

Un servidor stdio corre en la máquina de quien lo usa y no necesita hosting. Un servidor remoto, por Streamable HTTP, es una aplicación web como cualquier otra: un proceso que escucha HTTP y tiene que estar arriba cada vez que un cliente llama. En Square Cloud, corre en un contenedor aislado y siempre encendido, sin cold start ni modo de suspensión, con un subdominio *.squareweb.app y HTTPS. El proxy delante de las aplicaciones deja pasar las respuestas SSE sin buffer, lo que importa cuando una tool transmite su propio progreso.

Para publicar el servidor de pedidos en el runtime de Python, pon mcp en un requirements.txt (al iniciar, la plataforma ejecuta pip install -r requirements.txt), cambia el transporte stdio por Streamable HTTP y haz que el servidor escuche en 0.0.0.0, en el puerto de la variable PORT. Es lo opuesto al servidor local, que escucha solo en 127.0.0.1: aquí el endpoint es público, así que validar el Origin y exigir autenticación pasan a ser tarea de tu código. Los tokens y las claves van en las variables de entorno de la aplicación. Una aplicación web usa al menos 512 MB del pool de RAM del plan, y el Hobby cuesta desde R$12,49 al mes. El paso a paso del deploy está en cómo hospedar una API.

Del lado del modelo, si construyes tu propio agente (host y cliente), el AI Gateway puede ser el LLM que decide qué tools llamar. Es una API compatible con OpenAI para el modelo cubic, con function calling en el formato de OpenAI, hasta 32 tools por petición. El cliente convierte cada tool de MCP (nombre, descripción y esquema JSON) en una definición de función; cuando la respuesta vuelve con tool_calls, llama a tools/call en el servidor MCP y devuelve el resultado en un mensaje role: "tool". El gateway está en beta, sin costo extra durante la beta, y está disponible desde el plan Standard, con hasta 2,5M tokens al día y un contexto de hasta 16k tokens, en el que también cuentan las definiciones de tools. Los límites y la disponibilidad pueden cambiar cuando termine la beta. Para el servidor en sí, mira la página de hosting de APIs.