El Host: El Orquestador de MCP

Descripción de la cápsula

Cuando usas Claude Code y le pides "lee mi archivo package.json", no te detienes a pensar quién decide usar el MCP server de filesystem, quién verifica que tengas permiso, o quién presenta la respuesta. Todo eso lo hace el Host — la primera capa de la arquitectura MCP y la más cercana a ti como usuario.

En esta cápsula vas a entender qué es un MCP Host, qué responsabilidades tiene, y por qué Claude Code como Host es más que una interfaz bonita — es el orquestador que coordina múltiples MCP servers, maneja permisos, y decide cuándo y cómo usar cada capability disponible.

La analogía del restaurante aplica perfectamente: el Host es el maître. No cocina (eso lo hace el Server), no lleva platos (eso lo hace el Client), pero sin él, el restaurante no funciona. Decide qué cocina puede satisfacer cada pedido, verifica que el cliente tenga reservación, y coordina todo el servicio.

¿Qué es un MCP Host?

Definición

Un MCP Host es la aplicación que el usuario utiliza directamente y que orquesta las conexiones con MCP Servers a través de MCP Clients.

En términos concretos:

MCP Hosts actuales:
├── Claude Code (CLI) — Lo que usas en esta guía
├── Claude Desktop (app de escritorio)
├── Cursor (IDE con AI)
├── Windsurf (IDE de Codeium)
├── Zed (editor de texto)
├── Continue.dev (extensión open source)
└── Cualquier aplicación que implemente el protocolo MCP

El Host es la puerta de entrada al ecosistema MCP. Todo empieza y termina aquí.

El Host en la arquitectura

┌─────────────────────────────────────────────────┐
│                  MCP HOST                        │
│              (Claude Code)                       │
│                                                  │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐      │
│  │ MCP      │  │ MCP      │  │ MCP      │      │
│  │ Client 1 │  │ Client 2 │  │ Client 3 │      │
│  └────┬─────┘  └────┬─────┘  └────┬─────┘      │
│       │              │              │            │
└───────┼──────────────┼──────────────┼────────────┘
        │              │              │
        ▼              ▼              ▼
   ┌─────────┐   ┌─────────┐   ┌─────────┐
   │ MCP     │   │ MCP     │   │ MCP     │
   │ Server  │   │ Server  │   │ Server  │
   │ (files) │   │ (GitHub)│   │ (DB)    │
   └─────────┘   └─────────┘   └─────────┘

Observa un detalle clave: el Host contiene múltiples Clients, uno por cada Server conectado. No hay un solo Client que habla con todos los Servers — cada conexión tiene su propio Client dedicado.

Las 5 responsabilidades del Host

1. Gestión de conexiones

El Host es responsable de iniciar y mantener las conexiones con MCP Servers. Cuando Claude Code arranca, lee su configuración y lanza cada MCP server definido:

// ~/.claude/settings.json
{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/dev/projects"]
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_TOKEN": "ghp_xxxxxxxxxxxx"
      }
    },
    "memory": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-memory"]
    }
  }
}

Al iniciar, Claude Code:

1. Lee la configuración
2. Lanza cada server como un proceso separado
3. Crea un MCP Client para cada server
4. Inicia la conexión MCP con cada uno

Claude Code startup:
├── Lee settings.json
├── Encuentra 3 MCP servers configurados
├── Lanza proceso: npx @modelcontextprotocol/server-filesystem ...
│   └── Crea MCP Client 1 → Conecta con Filesystem Server
├── Lanza proceso: npx @modelcontextprotocol/server-github ...
│   └── Crea MCP Client 2 → Conecta con GitHub Server
└── Lanza proceso: npx @modelcontextprotocol/server-memory ...
    └── Crea MCP Client 3 → Conecta con Memory Server

2. Descubrimiento de capabilities

Una vez conectado, el Host necesita saber qué puede hacer cada Server. Esto sucede durante la fase de inicialización — el Client pregunta al Server qué capabilities expone:

Host → Client 1 → Filesystem Server:
  "¿Qué puedes hacer?"
  
Filesystem Server responde:
  "Tengo estos tools:
   - read_file(path)
   - write_file(path, content)
   - list_directory(path)
   - search_files(pattern)
   ..."

Host registra: Filesystem Server tiene 11 tools disponibles

Host → Client 2 → GitHub Server:
  "¿Qué puedes hacer?"
  
GitHub Server responde:
  "Tengo estos tools:
   - search_repositories(query)
   - create_issue(repo, title, body)
   - list_pull_requests(repo)
   ..."

Host registra: GitHub Server tiene 8 tools disponibles

Después de esta fase, el Host tiene un catálogo completo de todas las capabilities disponibles de todos sus Servers conectados.

3. Routing de requests

Cuando escribes algo en Claude Code, el Host decide qué Server (o Servers) pueden responder. Esta es la responsabilidad más importante del Host:

Usuario: "Lee el archivo README.md y crea un issue en GitHub con su contenido"

Host analiza:
├── "Lee el archivo README.md"
│   → Necesita: read_file
│   → Server: Filesystem ✅
│
└── "Crea un issue en GitHub con su contenido"
    → Necesita: create_issue
    → Server: GitHub ✅

Host orquesta:
1. Pide a Client 1 → Filesystem: read_file("README.md")
2. Recibe contenido del archivo
3. Pide a Client 2 → GitHub: create_issue(repo, title, content)
4. Recibe confirmación del issue creado
5. Presenta resultado al usuario

El Host puede usar múltiples Servers en una sola operación. Esa capacidad de orquestación es lo que hace al Host poderoso.

4. Gestión de permisos

El Host controla qué puede y qué no puede hacer cada Server. Cuando un MCP Server intenta ejecutar una operación, Claude Code puede pedir confirmación al usuario:

Usuario: "Crea un archivo llamado config.json"

Host → Client → Filesystem Server: write_file("config.json", ...)

Claude Code muestra:
┌─────────────────────────────────────────┐
│ ⚠️  MCP tool: filesystem.write_file     │
│                                         │
│ Path: /Users/dev/projects/config.json   │
│ Content: { "key": "value" }             │
│                                         │
│ ¿Permitir esta operación? [Y/n]         │
└─────────────────────────────────────────┘

El modelo de permisos del Host incluye:

Permisos del Host:
├── Scope de acceso
│   ├── Qué directorios puede ver el Filesystem server
│   ├── Qué repos puede acceder el GitHub server
│   └── Qué databases puede consultar el DB server
│
├── Confirmación de operaciones
│   ├── Lectura → Generalmente automática
│   ├── Escritura → Pide confirmación
│   └── Destructiva → Requiere confirmación explícita
│
└── Variables de entorno
    ├── GITHUB_TOKEN → Solo disponible para el GitHub server
    ├── DB_CONNECTION → Solo disponible para el DB server
    └── Cada server tiene acceso solo a SUS variables

Este aislamiento es crítico para seguridad: un MCP server de filesystem no tiene acceso al token de GitHub, y el server de GitHub no puede leer archivos del filesystem.

5. Presentación de resultados

El Host recibe las respuestas de los Servers y las presenta al usuario de forma coherente. No muestra el JSON crudo — lo procesa, lo formatea, y lo integra en la conversación:

MCP Server retorna (JSON crudo):
{
  "content": [
    {
      "type": "text",
      "text": "Found 3 files matching pattern '*.py':\n- main.py\n- utils.py\n- test_main.py"
    }
  ]
}

Host presenta al usuario:
"Encontré 3 archivos Python en tu proyecto:
 - main.py
 - utils.py
 - test_main.py"

El Host también decide cómo combinar resultados de múltiples Servers en una respuesta coherente cuando una operación involucra varios.

Claude Code como Host: detalles específicos

Cómo Claude Code gestiona MCP Servers

Claude Code tiene 3 niveles de configuración para MCP servers:

Niveles de scope:
├── user (-s user)
│   └── Disponible en TODAS las sesiones de Claude Code
│       Archivo: ~/.claude/settings.json
│
├── project (-s project)
│   └── Disponible solo en el proyecto actual
│       Archivo: .claude/settings.json (en el repo)
│
└── local (-s local, default)
    └── Disponible solo en la sesión actual
        Archivo: .claude/settings.local.json

Esto permite configuraciones como:

# Server de filesystem: disponible siempre (user scope)
claude mcp add filesystem -s user -- npx -y @modelcontextprotocol/server-filesystem ~/projects

# Server de database: solo para este proyecto (project scope)
claude mcp add db -s project -- npx -y @modelcontextprotocol/server-postgres $DB_URL

# Server experimental: solo esta sesión (local scope)
claude mcp add test-server -s local -- node ./my-server.js

Comandos de gestión del Host

Claude Code expone comandos para gestionar MCP servers en runtime:

# Ver todos los servers y su estado
claude mcp list

# Ver estado detallado dentro de una sesión
/mcp

# Agregar un server
claude mcp add <nombre> -s <scope> -- <comando> <args>

# Remover un server
claude mcp remove <nombre> -s <scope>

# Ver la configuración raw
cat ~/.claude/settings.json

El comando /mcp dentro de una sesión activa es especialmente útil porque muestra:

MCP Servers:
  filesystem: connected ✅
    Tools: read_file, write_file, list_directory, ...
    
  github: connected ✅
    Tools: search_repositories, create_issue, ...
    
  memory: disconnected ❌
    Error: ENOENT - npx not found

Flujo de decisión del Host

Cuando le pides algo a Claude Code, el modelo (Claude) actúa como el "cerebro" del Host que decide qué tools usar:

Input del usuario: "¿Cuántos archivos .ts hay en mi proyecto?"

Proceso de decisión del Host:
│
├── 1. Claude procesa el lenguaje natural
│   └── Identifica: necesita contar archivos con extensión .ts
│
├── 2. Revisa capabilities disponibles
│   ├── Filesystem server: search_files(pattern) ✅ Puede buscar archivos
│   ├── GitHub server: search_code(query) — No aplica (busca en GitHub, no local)
│   └── Memory server: retrieve() — No aplica
│
├── 3. Selecciona el tool más apropiado
│   └── filesystem.search_files con pattern "*.ts"
│
├── 4. Ejecuta via Client
│   └── Client 1 → Filesystem Server → search_files("*.ts")
│
├── 5. Recibe resultado
│   └── [lista de archivos .ts]
│
└── 6. Presenta al usuario
    └── "Hay 47 archivos TypeScript en tu proyecto..."

Múltiples Servers: el poder del Host

Un Host, muchos Servers

Un setup típico de Claude Code para un developer profesional incluye múltiples MCP servers:

Claude Code (Host)
├── Client 1 → Filesystem Server (archivos locales)
├── Client 2 → GitHub Server (repos, PRs, issues)
├── Client 3 → PostgreSQL Server (database)
├── Client 4 → Slack Server (comunicación)
└── Client 5 → Memory Server (persistencia)

Cada Server es un proceso independiente. Si uno falla, los demás siguen funcionando:

Estado de conexiones:
├── filesystem: connected ✅
├── github: connected ✅
├── postgres: disconnected ❌ (DB no disponible)
├── slack: connected ✅
└── memory: connected ✅

→ Claude Code sigue funcionando con 4 de 5 servers
→ Solo las operaciones de database fallan

Orquestación cross-server

La capacidad más poderosa del Host es coordinar operaciones entre múltiples Servers:

Usuario: "Lee los últimos commits de GitHub y guárdalos en un archivo local"

Host orquesta:
│
├── Paso 1: GitHub Server
│   └── list_commits(repo="my-project", limit=10)
│   └── Resultado: [lista de 10 commits]
│
├── Paso 2: Filesystem Server
│   └── write_file(path="commits.md", content=formatted)
│   └── Resultado: archivo creado
│
└── Paso 3: Presenta resultado
    └── "Guardé los últimos 10 commits en commits.md"

Sin el Host como orquestador, cada Server opera en aislamiento. El Host es quien conecta los puntos.

Host vs las otras capas

Qué hace el Host (y qué NO hace)

El Host SÍ hace:
├── ✅ Inicia conexiones con Servers
├── ✅ Descubre capabilities de cada Server
├── ✅ Decide qué Server/tool usar para cada petición
├── ✅ Maneja permisos y confirmaciones
├── ✅ Presenta resultados al usuario
└── ✅ Coordina operaciones cross-server

El Host NO hace:
├── ❌ Ejecutar operaciones (eso lo hace el Server)
├── ❌ Manejar el protocolo de comunicación (eso lo hace el Client)
├── ❌ Conectarse directamente con APIs externas (via MCP, no directo)
├── ❌ Mantener el estado de los Servers (cada Server maneja el suyo)
└── ❌ Implementar la lógica de negocio de las capabilities

Comparación con el Client y Server

Troubleshooting

"Claude Code no detecta mi MCP server"

Causa más probable: El comando de arranque del server falla silenciosamente.

Solución:

# 1. Prueba el comando manualmente
npx -y @modelcontextprotocol/server-filesystem /tu/directorio

# 2. Si falla, verifica que npx/node estén instalados
which npx
node --version

# 3. Verifica la configuración
claude mcp list

# 4. Re-agrega con el scope correcto
claude mcp remove my-server
claude mcp add my-server -s user -- npx -y @modelcontextprotocol/server-filesystem /tu/directorio

"El server aparece como disconnected"

Causa más probable: El proceso del server crashea al iniciar.

Solución:

# 1. Revisa si hay errores en el startup
# Abre una nueva sesión de Claude Code y observa los mensajes iniciales

# 2. Verifica que las variables de entorno estén configuradas
# Para servers que requieren tokens:
echo $GITHUB_TOKEN

# 3. Revisa permisos del directorio configurado
ls -la /tu/directorio/configurado

"Claude Code no usa el tool correcto"

Causa: Claude (el modelo) decide qué tool usar basado en tu petición. Si tu pregunta es ambigua, puede elegir un tool diferente al que esperas.

Solución: Sé específico en tu petición:

• ❌ "Busca información sobre mi proyecto"
• ✅ "Usa el filesystem server para listar los archivos en ./src"

"Un server funciona pero los otros no"

Causa: Cada server es un proceso independiente. Uno puede fallar sin afectar a los demás.

Solución:

# Ver el estado de cada server
/mcp

# Identificar cuál falla y re-verificar su configuración
claude mcp list

"El server es lento para responder"

Causa probable: El server se inicia con npx, que descarga el package cada vez.

Solución:

# Instalar globalmente para arranque más rápido
npm install -g @modelcontextprotocol/server-filesystem

# Reconfigurar para usar el binario global
claude mcp remove filesystem
claude mcp add filesystem -s user -- server-filesystem /tu/directorio

Ejercicios

Ejercicio 1: Identificar responsabilidades del Host (Fácil)

Clasifica cada acción como responsabilidad del Host, del Client, o del Server:

1. Pedir confirmación al usuario antes de escribir un archivo
2. Enviar un mensaje JSON-RPC al server
3. Ejecutar una query SQL en la database
4. Decidir que se necesita el tool read_file para responder una pregunta
5. Descubrir qué tools expone un server durante la inicialización
6. Formatear la respuesta del server para mostrarla al usuario

Ejercicio 2: Diseñar la configuración de un Host (Medio)

Tu equipo trabaja en un proyecto que necesita:

• Acceso al filesystem local
• Conexión con GitHub para gestionar PRs
• Acceso a una database PostgreSQL
• Integración con Slack para notificaciones

Escribe la configuración JSON de Claude Code (settings.json) que conecte estos 4 MCP servers. Define qué scope usarías para cada uno y por qué.

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/dev/my-project"]
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_TOKEN": "ghp_xxxxxxxxxxxx"
      }
    },
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": {
        "DATABASE_URL": "postgresql://user:pass@localhost:5432/mydb"
      }
    },
    "slack": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-slack"],
      "env": {
        "SLACK_BOT_TOKEN": "xoxb-xxxxxxxxxxxx"
      }
    }
  }
}

claude mcp add filesystem -s user -- npx -y @modelcontextprotocol/server-filesystem ~/projects
claude mcp add github -s user -- npx -y @modelcontextprotocol/server-github
claude mcp add postgres -s project -- npx -y @modelcontextprotocol/server-postgres
claude mcp add slack -s user -- npx -y @modelcontextprotocol/server-slack

Ejercicio 3: Trazar el routing del Host (Medio)

El usuario escribe: "Lee mi archivo .env, busca la variable DATABASE_URL, y dime cuántas tablas tiene esa database."

Traza el flujo de routing del Host: qué Servers usa, en qué orden, y qué tools invoca. Asume que tiene configurados Filesystem server y PostgreSQL server.

Input: "Lee mi archivo .env, busca DATABASE_URL, y dime cuántas tablas tiene esa database"

Routing del Host:
│
├── Paso 1: Filesystem Server
│   Tool: read_file(path=".env")
│   Resultado: "DATABASE_URL=postgresql://user:pass@localhost:5432/mydb\nAPI_KEY=abc..."
│
├── Paso 2: Host procesa (Claude extrae)
│   Extrae: DATABASE_URL = postgresql://user:pass@localhost:5432/mydb
│
├── Paso 3: PostgreSQL Server
│   Tool: query(sql="SELECT COUNT(*) FROM information_schema.tables WHERE table_schema='public'")
│   Resultado: { "count": 12 }
│
└── Paso 4: Host presenta
    "Tu archivo .env contiene DATABASE_URL apuntando a mydb.
     Esa database tiene 12 tablas en el schema público."

Ejercicio 4: Analizar el modelo de permisos (Medio)

Explica por qué es importante que cada MCP server tenga sus propias variables de entorno aisladas. ¿Qué pasaría si un MCP server de filesystem tuviera acceso al GITHUB_TOKEN?

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["server-filesystem", "/dir"]
      // NO tiene acceso a GITHUB_TOKEN
    },
    "github": {
      "command": "npx",
      "args": ["server-github"],
      "env": {
        "GITHUB_TOKEN": "ghp_xxx"
        // Solo github server ve este token
      }
    }
  }
}

Ejercicio 5: Simular un Host con múltiples Servers (Difícil)

Dibuja el diagrama de un Host (Claude Code) conectado a 3 MCP servers. Para cada server, lista al menos 3 tools que expondría. Luego, escribe 3 peticiones de usuario que requieran que el Host use 2 o más servers en una sola operación.

Claude Code (Host)
│
├── Client 1 → Filesystem Server
│   ├── read_file(path)
│   ├── write_file(path, content)
│   └── list_directory(path)
│
├── Client 2 → GitHub Server
│   ├── list_pull_requests(repo)
│   ├── create_issue(repo, title, body)
│   └── get_commit_history(repo, limit)
│
└── Client 3 → Slack Server
    ├── send_message(channel, text)
    ├── list_channels()
    └── search_messages(query)

Ejercicio 6: Debugging del Host (Difícil)

Tu Claude Code muestra este estado al ejecutar /mcp:

MCP Servers:
  filesystem: connected ✅
    Tools: read_file, write_file, ...
  github: disconnected ❌
  postgres: connected ✅
    Tools: query, list_tables, ...

El usuario reporta: "Claude Code no me deja crear issues en GitHub." Describe tu proceso de debugging paso a paso, identificando en qué capa (Host, Client, Server) buscarías el problema.

Paso 1: Identificar la capa del problema
└── El server github aparece como "disconnected"
└── Esto es un problema de CONEXIÓN, no de uso
└── Capa: Host → Client (la conexión falla antes de llegar al Server)

Paso 2: Verificar la configuración del Host
$ claude mcp list
→ ¿Aparece github en la lista?
→ Si NO aparece: el server no está configurado (problema de Host)
→ Si SÍ aparece: la configuración existe pero la conexión falla

Paso 3: Verificar el comando del server
$ npx -y @modelcontextprotocol/server-github
→ ¿Se ejecuta correctamente?
→ Si falla: problema del Server o sus dependencias
→ Error común: GITHUB_TOKEN no configurado

Paso 4: Verificar variables de entorno
$ echo $GITHUB_TOKEN
→ ¿Está definido?
→ ¿Está en la configuración del MCP server?

Paso 5: Re-configurar
$ claude mcp remove github
$ claude mcp add github -s user -- npx -y @modelcontextprotocol/server-github
→ Con env: GITHUB_TOKEN configurado

Paso 6: Verificar conexión
$ /mcp
→ github: connected ✅

Resumen

En esta cápsula aprendiste:

• El Host es la aplicación que el usuario usa directamente (Claude Code) y actúa como orquestador
• Tiene 5 responsabilidades clave: gestión de conexiones, descubrimiento de capabilities, routing de requests, gestión de permisos, presentación de resultados
• Claude Code gestiona servers en 3 scopes: user, project, local
• Un Host puede tener múltiples Clients, uno por cada Server conectado
• El poder del Host está en la orquestación cross-server — coordinar múltiples Servers en una operación
• El Host no ejecuta operaciones directamente — las delega a Servers via Clients
• El Host aísla cada Server con sus propias variables de entorno por seguridad

Próxima cápsula: El Client: el conector — el componente invisible que maneja el protocolo MCP, el lifecycle de conexión, y la comunicación entre Host y Server.

Recursos adicionales

1. MCP Architecture — Hosts - Documentación oficial sobre el rol del Host
2. Claude Code MCP Configuration - Guía de configuración de MCP en Claude Code
3. MCP Server Scopes in Claude Code - Documentación de scopes (user, project, local)
4. MCP Security Considerations - Modelo de seguridad y permisos del Host
5. Claude Code CLI Reference - Referencia completa de comandos CLI incluyendo claude mcp
6. Awesome MCP Servers - Directorio de servers para configurar en tu Host

Siguiente cápsula: El Client: el conector — cómo funciona el protocolo de comunicación MCP, el lifecycle de una conexión, y qué pasa entre el Host y el Server.