Cómo Construir un Agente de IA con MCP + n8n + Claude API: Guía Práctica 2026

Nexa

• 7 min read

El Model Context Protocol (MCP) cambió las reglas del juego para la automatización con IA. Lo que antes requería código custom para cada integración, hoy se resuelve con un servidor MCP que cualquier modelo compatible puede usar. En marzo de 2026, con más de 3,000 servidores publicados y adopción oficial de OpenAI, Google, Microsoft y Amazon, MCP es el estándar.

Esta guía muestra cómo construir un agente de IA funcional y en producción combinando tres piezas: MCP como capa de herramientas, n8n como orquestador de workflows, y Claude Sonnet 4.6 como cerebro. Sin vendor lock-in, sin código innecesario, con casos de uso reales.

¿Qué es MCP y por qué importa?

MCP es un protocolo abierto creado por Anthropic en noviembre de 2024 que estandariza cómo los modelos de IA se conectan con herramientas y datos externos. La analogía más precisa: es el USB-C para la inteligencia artificial.

Antes de MCP, cada integración era una isla:

  • Querías que tu agente leyera emails → código custom para Gmail API
  • Querías que creara tareas en Notion → otra integración desde cero
  • Cambiabas de modelo (de Claude a GPT) → reescribías todas las integraciones

Con MCP, un mismo servidor funciona con cualquier modelo compatible. Construyes una vez, usas en cualquier lado.

Sin MCP Con MCP
Integración custom por herramienta Un servidor MCP reutilizable
Acoplado a un modelo específico Compatible con Claude, GPT, Gemini
Difícil de escalar y mantener Modular, composable, estándar
Cada cambio requiere reingeniería Swappable sin tocar el agente

La Arquitectura: Tres Capas, Un Agente

El sistema que vamos a construir tiene tres capas bien definidas:

┌─────────────────────────────────────────────┐
│              CAPA DE ORQUESTACIÓN           │
│                    n8n                       │
│   (trigger → workflow → respuesta final)    │
└──────────────────┬──────────────────────────┘
                   │ HTTP / Webhook
┌──────────────────▼──────────────────────────┐
│              CAPA DE RAZONAMIENTO           │
│           Claude Sonnet 4.6 API             │
│   (entiende, planifica, decide qué tools    │
│    usar y en qué orden)                     │
└──────────────────┬──────────────────────────┘
                   │ MCP Protocol
┌──────────────────▼──────────────────────────┐
│              CAPA DE HERRAMIENTAS           │
│              Servidores MCP                 │
│  Gmail │ Notion │ Slack │ GitHub │ Calendar  │
└─────────────────────────────────────────────┘

n8n es el orquestador: recibe el trigger (mensaje de Slack, email entrante, webhook, cron), arma el contexto y llama a la API de Claude. Claude razona sobre la tarea, decide qué herramientas necesita y las invoca a través de MCP. Los servidores MCP ejecutan las acciones reales en los sistemas externos.

Paso 1: Configurar los Servidores MCP

Los servidores MCP son procesos que exponen herramientas via el protocolo estándar. Puedes usar servidores existentes del ecosistema o construir los tuyos. Para este agente usaremos servidores disponibles públicamente.

Instalación de servidores MCP clave

# Servidor MCP para Gmail
npx @modelcontextprotocol/server-gmail

# Servidor MCP para Notion
npx @notionhq/notion-mcp-server

# Servidor MCP para Slack
npx @modelcontextprotocol/server-slack

# Servidor MCP para GitHub
npx @modelcontextprotocol/server-github

# Servidor MCP para búsqueda web (Brave)
npx @modelcontextprotocol/server-brave-search

Configuración en claude_desktop_config.json (o tu runtime)

{
  "mcpServers": {
    "gmail": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-gmail"],
      "env": { "GMAIL_CREDENTIALS": "path/to/credentials.json" }
    },
    "notion": {
      "command": "npx",
      "args": ["-y", "@notionhq/notion-mcp-server"],
      "env": { "NOTION_API_KEY": "secret_xxx" }
    },
    "slack": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-slack"],
      "env": { "SLACK_BOT_TOKEN": "xoxb-xxx" }
    }
  }
}

Paso 2: Configurar el Workflow en n8n

n8n es el director de orquesta. Su rol es simple pero crítico: recibir el evento, preparar el contexto, llamar a Claude con las herramientas disponibles, y manejar la respuesta.

Estructura del workflow

[Trigger] → [Preparar contexto] → [Claude API con MCP] → [Procesar respuesta] → [Enviar output]

Ejemplo de trigger: Webhook POST con mensaje del usuario
Ejemplo de output: Respuesta en Slack + tarea creada en Notion

Nodo HTTP Request en n8n para llamar Claude API con herramientas MCP

// Configuración del nodo HTTP Request en n8n
{
  "method": "POST",
  "url": "https://api.anthropic.com/v1/messages",
  "headers": {
    "x-api-key": "{{ $env.ANTHROPIC_API_KEY }}",
    "anthropic-version": "2023-06-01",
    "content-type": "application/json"
  },
  "body": {
    "model": "claude-sonnet-4-6",
    "max_tokens": 4096,
    "system": "Eres un asistente de productividad. Tienes acceso a Gmail, Notion, Slack y GitHub. Cuando el usuario te pida algo, usa las herramientas disponibles para completar la tarea de forma autónoma. Confirma siempre lo que hiciste.",
    "messages": [
      { "role": "user", "content": "{{ $json.message }}" }
    ],
    "mcp_servers": [
      { "type": "url", "url": "https://gmail.mcp.tudominio.com/mcp", "name": "gmail" },
      { "type": "url", "url": "https://mcp.notion.com/mcp", "name": "notion" },
      { "type": "url", "url": "https://slack.mcp.tudominio.com/mcp", "name": "slack" }
    ]
  }
}

Paso 3: El System Prompt — La Parte Más Crítica

El system prompt es el cerebro del agente. Define qué puede hacer, cómo debe comportarse y qué restricciones tiene. Un system prompt mal diseñado produce un agente impredecible, sin importar qué tan buenas sean las herramientas.

Anatomía de un system prompt efectivo para agentes

## ROL Y CONTEXTO
Eres el asistente de automatización de [Empresa]. Tienes acceso a las herramientas
de la empresa: Gmail, Notion, Slack, GitHub y Google Calendar.

## CAPACIDADES
- Leer y redactar emails en nombre del usuario
- Crear, actualizar y buscar páginas en Notion
- Enviar mensajes y leer canales en Slack
- Crear issues y revisar PRs en GitHub
- Consultar y crear eventos en Calendar

## REGLAS DE COMPORTAMIENTO
1. Siempre confirma acciones destructivas o irreversibles antes de ejecutarlas
2. Cuando completes una tarea multi-paso, reporta cada paso ejecutado
3. Si una tarea es ambigua, pide clarificación ANTES de ejecutar
4. Prefiere hacer las cosas en el orden más lógico, no el más rápido
5. Si algo falla, reporta el error con contexto específico

## FORMATO DE RESPUESTA
- Para tareas completadas: resume qué hiciste en bullets
- Para errores: explica qué falló y sugiere alternativas
- Para confirmaciones pendientes: describe exactamente qué vas a hacer

Paso 4: Manejo del Loop de Herramientas

Cuando Claude necesita usar herramientas, la API devuelve bloques tool_use. En n8n necesitas manejar este loop correctamente — Claude puede necesitar múltiples rondas de herramientas para completar una tarea compleja.

// Lógica de loop en n8n con nodo Code

const response = items[0].json;
const messages = [...$node["Preparar contexto"].json.messages];

// Procesar bloques de la respuesta
for (const block of response.content) {
  if (block.type === "text") {
    // Respuesta final de texto — el agente terminó
    return [{ json: { finalResponse: block.text, done: true } }];
  }
  
  if (block.type === "mcp_tool_use") {
    // Claude quiere usar una herramienta — n8n la ejecuta via MCP
    // Los resultados se pasan de vuelta a Claude en el siguiente turno
    console.log(`Tool: ${block.name}, Input: ${JSON.stringify(block.input)}`);
  }
}

// Si hay tool_use, continuar el loop
return [{ json: { messages, done: false, toolCalls: response.content } }];

Caso de Uso Real: Agente de Gestión de Proyectos

Para hacerlo concreto, aquí está el flujo completo de un agente que gestiona el pipeline de un equipo de desarrollo:

Trigger: Mensaje en Slack

Un desarrollador escribe en #agente-ia: "Hay un bug crítico en producción, el endpoint /api/users devuelve 500. Crea el issue en GitHub, avisa al equipo en #dev-ops y agrégalo a la página de Incidentes en Notion."

Lo que hace el agente (automáticamente)

Paso 1 → github:create_issue
  title: "Bug crítico: /api/users devuelve 500 en producción"
  labels: ["bug", "critical", "production"]
  body: "Reportado vía Slack por @developer..."
  → Issue #247 creado ✓

Paso 2 → slack:post_message
  channel: "#dev-ops"
  message: "🚨 Bug crítico en prod: /api/users → 500
            Issue: github.com/org/repo/issues/247
            Asignado a: @on-call-engineer"
  → Mensaje enviado ✓

Paso 3 → notion:search
  query: "Incidentes producción"
  → Página "Log de Incidentes 2026" encontrada ✓

Paso 4 → notion:append_block
  page_id: "xxx"
  content: "| 2026-03-19 | /api/users 500 | Crítico | #247 | En investigación |"
  → Registro añadido ✓

Respuesta final: "Listo. Creé el issue #247 en GitHub,
notifiqué a #dev-ops y registré el incidente en Notion."

Todo eso en segundos, sin que el desarrollador cambie de contexto ni toque tres herramientas distintas.

Paso 5: Manejo de Errores y Reintentos

Un agente en producción necesita manejar fallos gracefully. La estrategia recomendada:

// En n8n: nodo Error Trigger + lógica de reintento

// 1. Timeout: si Claude no responde en 30s, retry x2
// 2. Tool failure: si un MCP server falla, notificar al usuario
// 3. Rate limit (429): exponential backoff automático
// 4. Respuesta inválida: log + fallback a respuesta manual

{
  "onError": "continueRegularOutput",
  "retryOnFail": true,
  "maxTries": 3,
  "waitBetweenTries": 2000
}

Paso 6: Memoria y Contexto Persistente

Un agente sin memoria es un agente que empieza de cero en cada conversación. Para sesiones de trabajo largas necesitas persistir el historial de mensajes.

// Estrategia de memoria en n8n con Redis o variables de workflow

// Al inicio del workflow:
const sessionId = $json.userId + "_" + $json.channelId;
const history = await getFromRedis(sessionId) || [];

// Construir messages con historial
const messages = [
  ...history.slice(-10),   // últimos 10 turnos
  { role: "user", content: $json.message }
];

// Al finalizar, guardar el turno:
history.push({ role: "user", content: $json.message });
history.push({ role: "assistant", content: finalResponse });
await saveToRedis(sessionId, history, 3600); // TTL: 1 hora

Costos: Lo que Realmente Cuesta Este Stack

Componente Costo Notas
n8n (self-hosted) $0–$20/mes (VPS) Docker en un VPS de 2GB RAM es suficiente para empezar
Claude Sonnet 4.6 API $3/$15 por 1M tokens Una conversación típica usa ~2K tokens. ~1,500 conversaciones por $1
Servidores MCP (OSS) $0 Mayoría son open source, self-hosteable
Total para MVP $20–$50/mes Para un equipo de 5-10 personas con uso moderado

Patrones Avanzados: Multi-Agente con MCP

Una vez que tienes un agente funcionando, el siguiente nivel es la arquitectura multi-agente: varios agentes especializados que se coordinan entre sí, cada uno con su propio set de herramientas MCP.

┌─────────────────────────────────────────────────┐
│           AGENTE ORQUESTADOR                    │
│         Claude Opus 4.6                         │
│   (decide qué sub-agente usar)                  │
└──────┬──────────────┬──────────────┬────────────┘
       │              │              │
┌──────▼──────┐ ┌──────▼──────┐ ┌──────▼──────┐
│  Agente     │ │  Agente     │ │  Agente     │
│  Ventas     │ │  Soporte    │ │  Dev        │
│  Sonnet 4.6 │ │  Sonnet 4.6 │ │  Sonnet 4.6 │
│  CRM + Email│ │  Tickets +  │ │  GitHub +   │
│  + Calendar │ │  Notion     │ │  CI/CD      │
└─────────────┘ └─────────────┘ └─────────────┘

El orquestador recibe la solicitud, determina qué agente es el más adecuado y delega. Cada sub-agente solo tiene acceso a las herramientas de su dominio — mejor seguridad, mejor rendimiento, más fácil de mantener.

Tips de Producción: Lo que Aprendemos en el Camino

  1. Empieza con un solo servidor MCP. La complejidad crece rápido. Valida el loop completo con una sola herramienta antes de agregar más.
  2. Loguea todo al inicio. En n8n, activa el modo debug y guarda cada request/response de Claude en un nodo Set. Cuando algo falla, necesitas el contexto completo.
  3. Define límites explícitos en el system prompt. Dile al agente qué NO puede hacer: "nunca elimines archivos sin confirmar", "nunca envíes emails externos sin aprobación". Los LLMs siguen instrucciones negativas mejor de lo que parece.
  4. Usa Sonnet 4.6 en producción, no Opus. El ratio costo/rendimiento de Sonnet es superior para tareas agénticas repetitivas. Reserva Opus para razonamiento realmente complejo.
  5. Versiona tus system prompts. Trátalos como código. Un cambio en el prompt es un cambio de comportamiento del agente — necesitas historial y posibilidad de rollback.
  6. Implementa un kill switch. Un nodo en n8n que puedas activar para pausar el agente sin tocar código. Cuando algo sale mal en producción, necesitas poder detenerlo en segundos.

¿Por Qué MCP Gana a Largo Plazo?

La razón estratégica más importante para construir sobre MCP en 2026 no es técnica — es de portabilidad. Hoy usas Claude. Mañana puede que Gemini 3.2 o GPT-6 sea mejor para tu caso de uso. Con MCP, cambiar de modelo es cambiar una línea en tu configuración. Tus herramientas, tu lógica de negocio, tu infraestructura — todo sigue igual.

Las empresas que construyen sus agentes sobre estándares abiertos hoy son las que van a escalar sin deuda técnica mañana.

Conclusión: El Stack Mínimo Viable para Empezar

Si quieres tener tu primer agente funcionando esta semana:

  1. n8n self-hosted en un VPS de $20/mes con Docker
  2. Un servidor MCP — empieza con Notion o Gmail, el que uses más
  3. Claude Sonnet 4.6 via API con un system prompt bien definido
  4. Un caso de uso concreto — no "un asistente general", sino "cuando llegue un email de cliente, crear una tarea en Notion y avisarme en Slack"

La complejidad viene sola. Lo difícil no es el código — es definir bien qué quieres que haga el agente y en qué casos debe preguntar antes de actuar.