MCP explicado: cómo conectar herramientas a tu agente sin reinventar la rueda

Cada agente necesita herramientas, y hasta hace poco cada agente necesitaba herramientas propias: schemas JSON específicos, clientes a medida y código de integración que no servía en ningún otro lado. El Model Context Protocol (MCP) estandariza esa capa: un servidor de herramientas habla un protocolo común y cualquier cliente compatible —Claude Code, Cursor, n8n, tu propia app— puede usarlo sin reescribir nada. Esta guía explica qué es MCP con precisión, cómo conectar un servidor real y, sobre todo, cuándo no usarlo.

Qué es MCP en una frase

MCP es un protocolo de comunicación (JSON-RPC 2.0) entre un host —la aplicación que ejecuta el agente— y uno o más servidores MCP que exponen capacidades. En lugar de que cada herramienta tenga su propia API y su propio formato, todo se reduce a tres tipos de capacidades estandarizadas:

• Herramientas (tools): funciones que el modelo puede invocar con parámetros tipados. La pieza que convierte a un chatbot en un agente.
• Recursos (resources): datos que el host puede leer, como archivos, documentos o resultados de APIs. Contexto bajo demanda, sin meter todo en el prompt.
• Prompts: plantillas de interacción reutilizables que el servidor ofrece al host.

La especificación define el transporte (stdio para procesos locales, Streamable HTTP para servidores remotos), el ciclo de vida de las sesiones y los formatos de los mensajes. Cuando un cliente se conecta a un servidor, primero negocia capacidades y luego intercambia llamadas: listar herramientas, invocar una, leer un recurso.

Por qué importa la estandarización

Antes de MCP, conectar tu agente a una base de datos implicaba: escribir el cliente, definir el schema de la función, mapear errores y mantenerlo todo. Con MCP:

• Un servidor, muchos clientes: el mismo servidor MCP funciona en Claude Code, Cursor, n8n y apps propias.
• La comunidad ya construyó los conectores: hay servidores públicos para GitHub, bases de datos, navegadores, Slack y cientos de servicios más. Instalas, no programas.
• Cambio de herramienta sin migración: mover un agente de un host a otro no reescribe las integraciones, solo re-apunta los servidores.

Cómo conectar un servidor MCP a Claude Code

La vía más rápida para probar MCP con un agente de código es Claude Code. Ejemplo real conectando el servidor de GitHub:

claude mcp add github \
  --transport http \
  https://mcp.github.com/mcp \
  --header "Authorization: Bearer $GITHUB_TOKEN"

Después de agregarlo, el comando claude mcp list muestra el servidor y su estado. Al reiniciar la sesión, el agente ya puede llamar las herramientas de GitHub (crear issues, listar PRs) como si fueran funciones nativas. La documentación de Claude Code sobre MCP cubre los tres transportes: stdio, HTTP y SSE, y los comandos para probar (claude mcp get), actualizar y eliminar servidores.

En Cursor el flujo es equivalente desde Settings → MCP: agregas un servidor con su comando o URL, y las herramientas aparecen disponibles para los agentes del editor. Cada host tiene su configuración, pero el contrato es el mismo protocolo.

Buenas prácticas al conectar servidores

1. Empieza con pocos servidores: cada herramienta extra aumenta la superficie de decisión del modelo y el riesgo de llamadas incorrectas. Dos servidores bien elegidos superan a diez acumulados.
2. Usa tokens con permisos mínimos: el servidor MCP ejecuta con tu credencial; un token de solo lectura para empezar.
3. Revisa qué herramientas expone cada servidor: si un servidor trae herramientas de escritura que no necesitas, elige uno más acotado o implementa tu propio servidor con solo lo necesario.
4. Mide el costo: cada llamada a herramienta consume tokens; una sesión con MCP activo siempre cuesta más que una conversación simple.

Cuándo NO usar MCP

MCP es la respuesta correcta para conectar capacidades reutilizables entre sistemas, pero no es la respuesta para todo:

• Una herramienta única e interna: si tu agente solo necesita llamar un endpoint propio, un function call directo en tu código es más simple, más barato en latencia y más fácil de auditar. No necesitas un protocolo para una función.
• Requisitos de seguridad estrictos: cada servidor MCP añade un proceso o endpoint con acceso a datos. Si tu herramienta maneja datos sensibles, evaluar el servidor (¿quién lo mantiene?, ¿a dónde envía datos?) es obligatorio antes de conectarlo. Un servidor remoto de terceros con credenciales tuyas es un riesgo real.
• Latencia crítica: las llamadas MCP locales (stdio) son rápidas, pero los servidores remotos agregan red y estados intermedios. Para loops de baja latencia, integraciones directas pueden ser necesarias.
• Prototipos de una tarde: si estás validando una idea, un prompt con la herramienta embebida o un script simple gana en velocidad. MCP brilla cuando la herramienta se reutiliza en varios agentes y hosts.

Decisión práctica

Situación	Recomendación
Mismo servidor de herramientas usado por varios agentes	Usa MCP
Herramienta pública de un servicio conocido (GitHub, Slack, DB)	Usa el servidor MCP oficial
Endpoint privado de una sola app	Function call directo
Datos sensibles con servidores de terceros	Audita primero o implementa servidor propio
Prototipo rápido	Lo más simple que funcione hoy

MCP no elimina el diseño de herramientas: elimina el trabajo repetido de conectarlas. La regla que define si usarlo es la misma que define todo buen agente: si la capacidad se reutiliza, estandarízala; si es de un solo uso, no la envuelvas en protocolo. Para ver MCP aplicado al despliegue real de agentes, Vercel y MCP en deploy muestra el patrón en producción. Para profundizar en la construcción de agentes completos —arquitectura, memoria y herramientas— sigue las guías del hub de construcción de agentes, y si partes de cero con el runtime, el curso gratuito de instalación te aterriza los conceptos con un agente real funcionando.