IA /

IA:Model Context Protocol

Descripción

El Model Context Protocol (MCP) es la vía estándar para conectar Claude Code con herramientas externas (bases de datos, navegadores, APIs, repositorios) sin salir de la sesión. Esta guía recoge los comandos esenciales, los tres scopes que determinan dónde está disponible cada servidor, y las particularidades que diferencian a Claude Code de otros clientes MCP.

En Github puedes encontrar la lista completa de servidores MCP

1. Servidor de desarrollo compartido para el equipo de ingeniería

El caso más directo, y probablemente el más interesante para la mayoría de empresas, es montar Claude Code en una máquina potente dentro de la red corporativa (o en un VPS/servidor dedicado) y permitir que varios desarrolladores lo consuman vía MCP desde sus clientes habituales: Claude Desktop, un IDE con plugin MCP, o incluso scripts internos.

El problema que resuelve

En un equipo real, el entorno de desarrollo de cada miembro diverge con el tiempo. Uno tiene Python 3.11, otro 3.12; uno usa pnpm, otro npm; uno tiene Docker bien configurado, otro sufre con WSL. Cuando encima entra en juego la IA agéntica, esas diferencias se multiplican: Claude Code necesita acceso al código, a bases de datos de staging, a credenciales internas, a herramientas CLI propietarias. Replicar todo eso en el portátil de cada desarrollador es caro, lento y genera problemas de seguridad (credenciales dispersas en equipos personales).

Arquitectura

Se despliega Claude Code en un servidor dedicado (típicamente una máquina con buena CPU, RAM abundante y, si hace falta, GPU) expuesto como servidor MCP a través de la red interna o una VPN. El servidor tiene clonado el monorepo (o los repos relevantes), acceso a las bases de datos de desarrollo, las credenciales corporativas gestionadas mediante un vault (Vault de HashiCorp, AWS Secrets Manager, etc.), y las herramientas CLI específicas de la empresa.

Cada desarrollador se conecta desde su cliente MCP habitual. Puede usar Claude Desktop para conversación interactiva, un plugin de su IDE para ediciones puntuales, o incluso enviar tareas desde Slack mediante un bot que actúa como cliente MCP.

Beneficios concretos

El onboarding baja de días a minutos: un desarrollador nuevo no instala nada, simplemente conecta su cliente MCP al servidor. Las credenciales no salen del servidor, los desarrolladores trabajan sobre él pero no las ven. Los builds y tareas pesadas (compilar un proyecto grande, ejecutar la suite de tests completa, correr un análisis estático sobre todo el monorepo) usan los recursos del servidor, no los del portátil del desarrollador. Y la consistencia de entorno deja de ser un problema: todo el mundo ejecuta código en el mismo sitio.

Consideraciones

Requiere pensar bien el aislamiento entre usuarios si comparten la misma instancia: trabajar en ramas separadas, posiblemente workspaces o directorios por usuario, y políticas claras sobre qué puede tocar cada uno. Para equipos grandes, lo razonable es escalar horizontalmente (varias instancias de Claude Code, una por equipo o por proyecto) en lugar de saturar una sola máquina.

2. Orquestación multi-agente sobre varios repositorios o microservicios

Este es probablemente el caso más ambicioso y el que más se acerca a lo que podríamos llamar "ingeniería agéntica a escala". La idea: tener varias instancias de Claude Code corriendo como servidores MCP, cada una especializada en un dominio (un repositorio, un microservicio, una capa del sistema), y un agente orquestador (puede ser otro Claude Code, o Claude Desktop, o un agente custom) que las consume para resolver tareas que cruzan varios de esos dominios.

El problema que resuelve

En arquitecturas de microservicios o en organizaciones con decenas de repositorios, una tarea de producto rara vez vive en un solo sitio. "Añadir un nuevo campo al perfil de usuario" puede implicar tocar el servicio de auth, el de perfiles, el front-end web, la app móvil, la documentación de la API y los scripts de migración. Una sola instancia de Claude Code con todo el código no escala: el contexto se vuelve inmanejable, y la IA pierde foco.

Arquitectura

Cada instancia de Claude Code se despliega como servidor MCP con acceso únicamente a su dominio: repo de auth, repo de perfiles, repo de frontend, etc. Cada una se configura con las convenciones, herramientas y comandos propios de ese repo (linters, test runners, scripts de build). El orquestador (típicamente una instancia principal de Claude Code o Claude Desktop) tiene configurados todos estos servidores MCP como herramientas disponibles.

Cuando le llega una tarea transversal, el orquestador la descompone y delega cada parte al servidor MCP correspondiente. El agente de auth hace sus cambios, el de perfiles los suyos, el de frontend los suyos. El orquestador coordina, revisa que los contratos de API coincidan y consolida el resultado final.

Beneficios concretos

Cada agente trabaja con contexto acotado y relevante, no intenta entender todo el sistema a la vez. Se puede paralelizar: varios subservicios pueden estar siendo modificados simultáneamente. El conocimiento específico de cada repo (el CLAUDE.md, las convenciones, los scripts personalizados) vive con ese repo y no se mezcla. Y es naturalmente extensible: añadir un nuevo microservicio al orquestador es simplemente desplegar un nuevo Claude Code MCP y registrarlo.

Consideraciones

La orquestación requiere pensar bien los contratos entre agentes. Conviene que el orquestador tenga una visión de alto nivel (por ejemplo, los OpenAPI specs de todos los servicios) incluso si no tiene el código. Y hay que monitorizar bien: cuando algo falla, saber qué agente falló y por qué es fundamental.

3. Integración en pipelines CI/CD y automatización de ingeniería

Exponer Claude Code como servidor MCP lo convierte en un recurso consumible desde procesos automatizados, no solo desde humanos. Eso abre toda una categoría de casos de uso alrededor de CI/CD, revisión de código y mantenimiento del codebase.

El problema que resuelve

Hay muchas tareas repetitivas de ingeniería que son demasiado contextuales para una regla estática de linter, pero demasiado frecuentes para que tenga sentido que las haga un humano: revisar un PR según las convenciones internas, actualizar documentación cuando cambia un endpoint, migrar un patrón antiguo a uno nuevo en todos los sitios donde aparece, investigar por qué un test se ha vuelto intermitente, responder a una alerta de producción con un primer diagnóstico.

Arquitectura

Claude Code corre como servidor MCP en un entorno al que el orquestador de CI (GitHub Actions, GitLab CI, Jenkins, Buildkite) puede llamar. Se definen "jobs" que, en lugar de ejecutar un script fijo, abren una conexión MCP y mandan una instrucción estructurada: "revisa este PR siguiendo las reglas en review-guidelines.md", "actualiza el changelog con estos commits", "investiga este fallo de test y propón un fix".

El agente trabaja con el código real, ejecuta tests, investiga logs, y devuelve su resultado como comentario en el PR, como commit automático en una rama, o como incidencia en Jira. Webhooks de GitHub/GitLab pueden disparar estas acciones ante eventos: PR abierto, test fallando, issue etiquetado con needs-investigation.

Beneficios concretos

Los revisores humanos llegan al PR con la primera pasada ya hecha: estilo revisado, tests corridos, inconsistencias señaladas. Las migraciones masivas (actualizar una librería, cambiar una convención) dejan de ser proyectos de semanas. Las investigaciones de incidentes empiezan con un primer análisis automático, no desde cero. Y a diferencia de scripts tradicionales, el agente puede razonar sobre código que no había visto antes, no hace falta programarle cada caso.

Consideraciones

Es fundamental acotar el blast radius: el agente no debe poder hacer merge directo a main, ni tocar producción, ni ejecutar comandos arbitrarios. Se le da permisos de lectura amplios y permisos de escritura limitados a ramas feature y a comentarios. Conviene también definir un presupuesto de tokens y de tiempo por tarea, un agente que se atasca puede consumir mucho sin producir nada. Y los resultados deben ser auditables: quién pidió qué, qué hizo el agente, qué cambió.

4. Plataforma interna self-service para perfiles no-desarrolladores

Este caso es menos técnico pero probablemente el que más impacto tiene en la productividad de la organización a nivel global. La idea es usar Claude Code como MCP detrás de interfaces pensadas para perfiles que no son desarrolladores: product managers, analistas de datos, equipos de soporte, marketing.

El problema que resuelve

En toda empresa hay una cola permanente de "peticiones pequeñas" que van al equipo de ingeniería: añadir un campo a un formulario interno, cambiar el texto de un email transaccional, generar un informe ad-hoc con datos del warehouse, ajustar un feature flag, crear una landing para una campaña. Individualmente son tareas triviales; acumuladas, consumen una parte no despreciable del tiempo de los desarrolladores y generan frustración en ambos lados (el PM espera días por algo "fácil", el desarrollador pierde foco en su trabajo profundo).

Arquitectura

Claude Code vive en un servidor con acceso al código y a los entornos relevantes, expuesto como servidor MCP. Por delante se construye una interfaz adaptada al perfil del usuario no-técnico: puede ser un bot de Slack con comandos conversacionales, un dashboard interno con formularios para los casos más comunes, una extensión de herramientas como Retool o n8n, o un chat embebido en la intranet.

El cliente MCP detrás de esa interfaz traduce la petición del usuario ("añade una columna tipo_cliente al informe mensual de ventas") en una instrucción para Claude Code, que hace el cambio en una rama, abre el PR, y devuelve al usuario el enlace para que lo valide un desarrollador antes del merge. Se puede ir más allá con sistemas de aprobación automáticos para cambios muy acotados (textos, feature flags, configuración).

Beneficios concretos

La cola de tareas menores deja de bloquear al equipo de ingeniería. Los PMs y analistas trabajan más rápido porque no dependen de la disponibilidad de un desarrollador para cosas simples. El desarrollador sigue en el loop como revisor (no se pierde control) pero su trabajo pasa de "ejecutar tareas pequeñas" a "validar cambios pequeños", que es mucho más rápido. Y el conocimiento del código se democratiza: los perfiles no-técnicos entienden mejor qué hay detrás de las herramientas que usan.

Consideraciones

Hay que pensar muy bien los permisos: qué tipos de cambios puede iniciar cada rol, qué requiere aprobación humana, qué está completamente vedado. La interfaz debe guiar hacia peticiones bien formuladas, un formulario estructurado funciona mejor que un chat libre cuando el usuario no sabe expresar bien lo que quiere en términos técnicos. Y es importante tener observabilidad: saber qué peticiones se hacen, cuáles se completan bien, cuáles fallan, para iterar sobre la interfaz.

5. Entornos restringidos, regulados o air-gapped

Por último, un caso que en ciertos sectores es prácticamente la única forma viable de usar IA agéntica sobre código: entornos donde el código no puede salir de una infraestructura controlada.

El problema que resuelve

Banca, salud, defensa, administración pública, empresas con propiedad intelectual crítica: hay sectores donde mandar el código fuente a un servicio externo, o incluso tenerlo en el portátil de un desarrollador fuera de la oficina, no es una opción. Las políticas de seguridad exigen que el código viva en servidores específicos, con auditoría completa de accesos, y que cualquier herramienta que lo toque esté dentro del perímetro.

Históricamente esto ha dejado a estos sectores fuera de muchas herramientas modernas de productividad. La IA agéntica corría el riesgo de quedarse igual de fuera.

Arquitectura

Claude Code se despliega como servidor MCP dentro del perímetro controlado: puede ser un datacenter on-premise, una VPC aislada en un cloud privado, o un entorno air-gapped conectado solo a la API de Anthropic (o a un modelo desplegado también dentro del perímetro, si se usa un setup de Bedrock/Vertex privado). El código nunca sale de ahí.

Los desarrolladores acceden al servidor MCP a través de una VPN corporativa o un bastion host. Desde su portátil solo fluye la conversación (los prompts y las respuestas) pero los ficheros, los diffs y los comandos se ejecutan en el servidor. Toda la actividad queda auditada: quién pidió qué, qué cambió, a qué hora.

Beneficios concretos

Compatible con políticas de seguridad estrictas porque el código no abandona el perímetro. Auditoría completa por diseño, todo pasa por un punto controlado. Revocación instantánea: dar de baja a un desarrollador es cerrar su acceso al servidor, no recuperar código de su equipo. Y en entornos con certificaciones (ISO 27001, SOC 2, esquemas sectoriales), es mucho más fácil defender este modelo ante auditores que "cada desarrollador tiene el código y una herramienta de IA en su portátil".

Consideraciones

La latencia de red entre el desarrollador y el servidor se nota en la experiencia, si la VPN es lenta, el flujo conversacional sufre. Hay que dimensionar bien el hardware para aguantar varios desarrolladores concurrentes. Y conviene tener un plan para trabajo offline o degradado: qué pasa cuando un desarrollador está viajando, qué pasa cuando el servidor tiene mantenimiento.

Conclusión

El hilo común entre los cinco casos es el mismo: Claude Code como servidor MCP deja de ser una herramienta personal para convertirse en un recurso compartido del equipo, gobernable, auditable y compuesto con el resto del stack. Ahí está el salto cualitativo respecto al caso básico que ya habéis visto en el curso, y ahí es donde esta arquitectura empieza a justificar la inversión de tiempo en configurarla bien.

Seguridad con MCP y Claude Code

Reglas fundamentales de seguridad cuando utilices servidores MCP:

Audita antes de instalar. Lee el código fuente de cualquier servidor MCP antes de ejecutarlo. Prefiere servidores oficiales (publicados por el vendor de la herramienta) sobre forks comunitarios.
Principio de menor privilegio. Usa usuarios de solo lectura para bases de datos, tokens con permisos mínimos para APIs, y acceso limitado al filesystem. Nunca le des a un servidor más acceso del necesario.
Controla los scopes. Los servidores --scope user están disponibles en todos tus proyectos, solo promueve a user los servidores en los que confías completamente.
Nunca commits secrets. Las credenciales van en variables de entorno, nunca en .mcp.json. Usa $VARIABLE en la configuración.
Cuidado con prompt injection. Los servidores MCP que obtienen contenido de fuentes no confiables (web scraping, emails, mensajes de chat) pueden exponer a ataques de prompt injection. El contenido externo podría contener instrucciones maliciosas dirigidas al modelo.
Limita servidores activos. Cada servidor MCP arranca un subproceso. Más de 5-6 servidores activos simultáneamente pueden ralentizar tu entorno. Usa /mcp disable para desactivar los que no necesites.

Toda la administración de servidores MCP se hace a través del subcomando claude mcp:

    # Añadir un servidor MCP (transporte stdio, por defecto)
    claude mcp add <nombre> -- <comando>

    # Añadir un servidor MCP remoto (transporte HTTP)
    claude mcp add --transport http <nombre> <url>

    # Añadir con variables de entorno
    claude mcp add -e API_KEY=xxx <nombre> -- <comando>

    # Añadir desde configuración JSON directa
    claude mcp add-json <nombre> '{"command": "npx", "args": [...]}'

    # Listar servidores instalados y su estado de conexión
    claude mcp list

    # Inspeccionar la configuración y estado de un servidor concreto
    claude mcp get <nombre>

    # Eliminar un servidor
    claude mcp remove <nombre>

    # Importar servidores desde Claude Desktop
    claude mcp add-from-claude-desktop

    Nota sobre transportes: a día de hoy el transporte HTTP (con soporte para OAuth 2.1) es el recomendado para servidores remotos. El antiguo transporte SSE sigue funcionando por compatibilidad, pero está considerado legacy y no debería usarse para implementaciones nuevas.

Los tres scopes de MCP

Cada servidor que añades tiene un scope que determina dónde está disponible. Es una de las características que diferencia a Claude Code de otros clientes MCP, y elegirlo bien evita tanto filtrar credenciales como obligar al equipo a reconfigurar lo mismo.

Scope local (por defecto)

Flag: --scope local
Almacenamiento: ~/.claude.json, bajo la ruta del proyecto
Disponibilidad: solo tú, solo en el proyecto actual
Uso típico: servidores experimentales o credenciales sensibles que no quieres compartir

Scope project

Flag: --scope project
Almacenamiento: .mcp.json en la raíz del proyecto
Disponibilidad: todo el equipo (el archivo se versiona con Git)
Uso típico: servidores que todos los desarrolladores del proyecto necesitan

Scope user

Flag: --scope user
Almacenamiento: ~/.claude.json (global)
Disponibilidad: solo tú, pero en todos tus proyectos
Uso típico: herramientas personales que usas siempre (buscadores, notas, etc.)

Atención con la terminología: el scope local de MCP se guarda en ~/.claude.json (tu home), mientras que la configuración local general de Claude Code vive en .claude/settings.local.json (dentro del proyecto). No los confundas.

Ejemplos prácticos


    # Servidor disponible solo para ti en este proyecto (por defecto)
    claude mcp add playwright -- npx -y @playwright/mcp --headless

    # Servidor compartido con el equipo vía git
    claude mcp add --scope project github --transport http https://api.githubcopilot.com/mcp

    # Servidor disponible en todos tus proyectos
    claude mcp add --scope user brave-search -- npx -y @brave/brave-search-mcp-server

Precedencia: cuando un mismo nombre de servidor existe en varios scopes, el orden de resolución es local → project → user.

Gestión en sesión con /mcp

Dentro de una sesión interactiva de Claude Code puedes gestionar servidores sin cerrarla:

    /mcp                     Abrir el panel de gestión MCP
    /mcp enable <nombre>     Habilitar un servidor
    /mcp disable <nombre>    Deshabilitar un servidor
    /mcp enable all          Habilitar todos
    /mcp disable all         Deshabilitar todos

El comando /mcp también se encarga de la autenticación OAuth 2.1 para los servidores remotos que la requieran, guiándote por el flujo de autorización en el navegador.

Tool Search: carga inteligente de herramientas

Una característica exclusiva de Claude Code es Tool Search (lazy loading). A diferencia de otros clientes MCP que cargan por adelantado todas las definiciones de herramientas de todos los servidores en el contexto, Claude Code las descubre bajo demanda: solo carga el schema de las herramientas que realmente va a usar.

Esto reduce el consumo de contexto en aproximadamente un 95%, lo que permite conectar más de 10 servidores MCP sin saturar la ventana de contexto. En la práctica, puedes tener todos tus servidores conectados a la vez sin preocuparte por el coste en tokens.

Configuración manual en .mcp.json

Para equipos, la configuración compartida se define en .mcp.json en la raíz del proyecto:

{
"mcpServers": {
"playwright": {
"command": "npx",
"args": ["-y", "@playwright/mcp", "--headless"]
},
"github": {
"type": "http",
"url": "https://api.githubcopilot.com/mcp",
"headers": {
"Authorization": "Bearer $GITHUB_TOKEN"
}
},
"postgres": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-postgres"],
"env": {
"POSTGRES_CONNECTION_STRING": "$DATABASE_URL"
}
}
}
}

[$[Get Code]]

    Variables de entorno: los valores en command, args, url y headers soportan la sintaxis $VAR y ${VAR}. Se expanden desde el entorno del shell al iniciar la sesión. Si una variable referenciada no existe, Claude Code muestra un warning pero intenta conectar de todos modos. Lo veremos en la siguiente clase con un ejemplo real.

    Buena práctica de seguridad: nunca incrustes secretos directamente en .mcp.json. Usa referencias a variables de entorno y carga los valores reales desde tu shell o un .env fuera del control de versiones. Lo veremos en la siguiente clase con un ejemplo real.

Claude Code como servidor MCP

El patrón "Claude Code expuesto como MCP" empieza a brillar cuando dejamos de pensarlo como una herramienta personal y lo empezamos a pensar como infraestructura de desarrollo: algo que corre en un servidor, que varios usuarios consumen, y que se integra con el resto del stack de la empresa.

En este artículo repasamos cinco escenarios donde este patrón aporta un valor real, con la arquitectura que tienen detrás y el tipo de problema que resuelven. No son ideas teóricas: son configuraciones que cobran sentido en equipos de ingeniería medianos y grandes, y que se vuelven casi inevitables en ciertos entornos regulados.

1. Servidor de desarrollo compartido para el equipo de ingeniería

El problema que resuelve

Arquitectura

Beneficios concretos

Consideraciones

2. Orquestación multi-agente sobre varios repositorios o microservicios

El problema que resuelve

Arquitectura

Beneficios concretos

Consideraciones

3. Integración en pipelines CI/CD y automatización de ingeniería

El problema que resuelve

Arquitectura

Beneficios concretos

Consideraciones

4. Plataforma interna self-service para perfiles no-desarrolladores

El problema que resuelve

Arquitectura

Beneficios concretos

Consideraciones

5. Entornos restringidos, regulados o air-gapped

Por último, un caso que en ciertos sectores es prácticamente la única forma viable de usar IA agéntica sobre código: entornos donde el código no puede salir de una infraestructura controlada.

El problema que resuelve

Históricamente esto ha dejado a estos sectores fuera de muchas herramientas modernas de productividad. La IA agéntica corría el riesgo de quedarse igual de fuera.

Arquitectura

Beneficios concretos

Consideraciones

Conclusión

Seguridad con MCP y Claude Code

Reglas fundamentales de seguridad cuando utilices servidores MCP:

Audita antes de instalar. Lee el código fuente de cualquier servidor MCP antes de ejecutarlo. Prefiere servidores oficiales (publicados por el vendor de la herramienta) sobre forks comunitarios.
Principio de menor privilegio. Usa usuarios de solo lectura para bases de datos, tokens con permisos mínimos para APIs, y acceso limitado al filesystem. Nunca le des a un servidor más acceso del necesario.
Controla los scopes. Los servidores --scope user están disponibles en todos tus proyectos, solo promueve a user los servidores en los que confías completamente.
Nunca commits secrets. Las credenciales van en variables de entorno, nunca en .mcp.json. Usa $VARIABLE en la configuración.
Cuidado con prompt injection. Los servidores MCP que obtienen contenido de fuentes no confiables (web scraping, emails, mensajes de chat) pueden exponer a ataques de prompt injection. El contenido externo podría contener instrucciones maliciosas dirigidas al modelo.
Limita servidores activos. Cada servidor MCP arranca un subproceso. Más de 5-6 servidores activos simultáneamente pueden ralentizar tu entorno. Usa /mcp disable para desactivar los que no necesites.

IA : Prompts : Claude : Copilot : MCP

Última modificación de la página el 20 May 2026 a las 19h38