Servidores MCP: ticketing, logs de errores y sistemas internos

Módulo 5 · Extensibilidad · Lección 1 de 8

MCP conecta Claude Code con los sistemas de tu cliente.

Al terminar esta lección podrás conectar Claude Code a los sistemas de ticketing, de monitoreo de errores o a una API interna de un cliente, y explicar el modelo de conexión al equipo de plataforma del cliente en términos que entienda.

Modelo de conexión

MCP llega fuera de la terminal para conectar Claude con las herramientas del cliente

Claude Code incluye herramientas para leer archivos, ejecutar código y buscar en la web. MCP es el estándar que permite añadir más, específicas del entorno del cliente y del engagement.

MCP (Model Context Protocol) es un estándar abierto para conectar Claude con sistemas externos. Al instalar un servidor MCP, le das a Claude tres categorías nuevas de capacidad en ese entorno. El modelo sigue siendo el mismo; lo que cambia es a qué puede llegar.

Capacidad	Qué aporta
Tools	Acciones que Claude puede realizar en el sistema externo: crear un ticket, consultar una base de datos, disparar la ejecución de un pipeline. El modelo decide qué herramienta llamar y qué parámetros le pasa.
Resources	Datos que Claude puede leer del sistema externo: tickets abiertos, logs de errores recientes, esquemas de API. Se cargan en el contexto bajo demanda, no de forma constante.
Prompts	Plantillas de contexto reutilizables que expone el servidor, como un preámbulo estandarizado que carga la documentación de API del cliente antes de cualquier tarea de código.
Scoping	Los servidores MCP pueden ser de proyecto (un repositorio), de usuario (un desarrollador) o de organización (todos los desarrolladores). El alcance correcto depende de si se trata de una configuración personal o de un despliegue de equipo.

flowchart LR
    dev["Desarrollador"] --> cc["Claude Code"]
    cc --> srv["Servidor MCP (tools, resources, prompts)"]
    srv --> tk["Ticketing: Jira, Linear, GitHub Issues"]
    srv --> obs["Errores y observabilidad: OTel, Datadog, Sentry"]
    srv --> ints["Sistemas internos: APIs privadas, bases de datos, Confluence"]

Instalación

Un solo comando de instalación: la ubicación del archivo de configuración define el alcance

El patrón de instalación es consistente en todos los servidores MCP. Lo que cambia es el archivo de configuración donde queda registrado el servidor.

Ejecuta claude mcp add seguido del nombre del servidor y de la configuración que requiera. Con --scope project, Claude Code escribe el resultado en .mcp.json; el alcance local, que es el predeterminado, escribe en ~/.claude.json. Tres ejemplos reales del starter kit del Plan de activación (Activation Plan) de 30 días:

# Ticketing: obtener el contexto del issue antes de escribir un fix
claude mcp add linear
# Automatización de navegador y pruebas end-to-end
claude mcp add --transport stdio playwright -- npx @playwright/mcp@latest
# Verificar que el servidor se cargó y revisar qué herramientas expuso
/mcp

Después de instalar, ejecuta /mcp al inicio de cualquier sesión para ver los servidores MCP conectados y las herramientas que exponen. Esa lista es lo que Claude puede alcanzar realmente en la sesión actual.

Ubicación de la configuración: .mcp.json en la raíz del proyecto limita el servidor a ese proyecto. ~/.claude.json con --scope user lo hace disponible en todos los proyectos de ese desarrollador. Nota: el alcance predeterminado (local) también escribe en ~/.claude.json, pero lo asocia al proyecto actual; el servidor no aparece en otros proyectos. El despliegue a nivel de organización pasa por managed-settings.json (se cubre en la siguiente lección, capítulo 20).

flowchart TD
    cmd["claude mcp add"] --> scope{"Alcance"}
    scope -->|"--scope project"| pj["Escribe en .mcp.json (raíz del proyecto): solo ese proyecto"]
    scope -->|"local (predeterminado)"| loc["Escribe en ~/.claude.json, asociado al proyecto actual"]
    scope -->|"--scope user"| usr["Escribe en ~/.claude.json: todos los proyectos del desarrollador"]
    scope -->|"Organización (todos los desarrolladores)"| org["managed-settings.json (lección siguiente)"]

Arquetipos de la activación

Tres arquetipos de MCP que aparecen en casi cualquier activación

El Plan de activación incluye en su checklist de pre-kickoff la pregunta: ¿qué servidores MCP usa ya este cliente? Estas son las categorías que hay que inventariar.

Arquetipo	Ejemplos	Qué aporta
Sistemas de ticketing	Jira, Linear, GitHub Issues	Claude obtiene el contexto del ticket antes de escribir un fix: sin copiar y pegar, sin pérdida de contexto. El patrón «Ticket to PR» del Enablement Deck empieza aquí. Sin esta conexión, los desarrolladores copian manualmente las descripciones de los tickets en la sesión.
Logs de errores y observabilidad	OTel, Datadog, Sentry	Claude lee directamente las trazas de errores recientes al depurar. Esto acorta el ciclo entre «apareció un error en producción» y «la corrección está en marcha». Para clientes con trabajo de modernización, es una señal de alto valor.
Sistemas internos	APIs privadas, bases de datos internas, catálogos de servicios, Confluence, herramientas propietarias	Requieren un servidor MCP personalizado o construido por el cliente, o el túnel MCP cuando el sistema no es alcanzable desde el portátil del desarrollador. Ambos se cubren en la lección 5.3 (capítulo 21).

Marco para el cliente

MCP es un amplificador de contexto, no un proyecto de integración de datos

El argumento de negocio de MCP no es «Claude puede leer Jira». Es algo más preciso.

Cuando un desarrollador corrige un bug hoy, abre el ticket, lee la descripción, cambia al editor, abre los archivos relevantes y luego empieza a escribir. MCP colapsa los dos primeros pasos: cuando el contexto del ticket ya está cargado en la sesión de Claude, el desarrollador empieza con Claude ya orientado, sin pérdida de contexto.

Qué significa esto para los equipos de seguridad y de plataforma

Para estos equipos, el encuadre depende de cómo se autentica el servidor MCP. En los servidores con alcance OAuth, Claude hereda los permisos del propio usuario: el servidor muestra solo lo que el usuario ya tiene acceso a ver, nada más. Esa distinción suele resolver la pregunta «¿qué puede ver Claude?» en la revisión de seguridad. Pero los servidores que usan API keys estáticas, cuentas de servicio o credenciales de headersHelper pueden conceder un acceso distinto al del propio usuario. Confirma siempre cómo se autentica el servidor MCP y qué herramientas expone antes de desplegarlo en un equipo.

Marco para la conversación con el cliente

Los servidores MCP bien acotados no deberían conceder acceso más allá de lo que el usuario o la credencial configurada pueden alcanzar. Reducen los cambios de contexto que los desarrolladores tienen que hacer para llegar a la información. Revisa siempre cómo se autentica el servidor MCP y qué expone antes del despliegue.

Comprueba tu comprensión

Escenario: el equipo de plataforma tiene una restricción

Estás configurando MCP el día 3 de la activación. El equipo de plataforma del cliente señala una restricción.

El equipo de plataforma dice: «Nuestra política de seguridad bloquea las llamadas de red externas desde los portátiles de los desarrolladores. Todo el tráfico debe mantenerse dentro de la red corporativa. Aun así, queremos que Claude Code alcance la instancia interna de Jira. ¿Qué configuración de MCP encaja?»

• A · Usar un servidor MCP alojado en la nube que actúe como proxy de Jira. Enruta todas las llamadas a Jira a través de un proxy MCP alojado. El portátil del desarrollador habla con el proxy; el proxy habla con Jira.
• B · Omitir MCP y que los desarrolladores copien manualmente el contexto de los tickets. Trátalo como un bloqueo y recurre a cargar el contexto a mano hasta que se revise la política.
• C · Ejecutar un servidor MCP stdio local que llame a Jira a través de la red corporativa. El servidor MCP corre como subproceso en el portátil del desarrollador. El tráfico hacia Jira sigue la ruta de red corporativa, sin llamadas externas.

Ver respuesta

C es correcta. La clave es el tipo de transporte de MCP. Un servidor stdio local se ejecuta como subproceso en la máquina del desarrollador y usa la ruta de red que el portátil ya tiene. Si el portátil puede alcanzar Jira mediante la red corporativa o la VPN, el servidor MCP también puede. Sin llamadas externas y sin nuevas excepciones de firewall.

La opción A sigue haciendo una llamada externa desde el portátil (al proxy). La opción B trata un problema de configuración solucionable como un bloqueo y desperdicia la primera semana del equipo.

Ideas clave

Ya sabes conectar. Ahora aprende a gobernar. MCP da a Claude acceso al entorno del cliente mediante una interfaz consistente: tools, resources y prompts, limitados a lo que el desarrollador ya tiene permiso de alcanzar. La instalación es un solo comando; el tipo de transporte y el nivel de alcance dependen de la postura de seguridad del cliente.

• Un servidor MCP stdio local corre como subproceso en el equipo del desarrollador y usa la ruta de red que el portátil ya tiene.
• Un servidor MCP bien acotado no debe conceder acceso más allá de lo que el usuario o la credencial configurada pueden alcanzar.
• Antes de desplegar, confirma cómo se autentica el servidor MCP y qué herramientas expone.
• MCP es un amplificador de contexto: el desarrollador empieza con Claude ya orientado en el ticket, sin copiar y pegar.

El CISO del cliente preguntará: ¿pueden los desarrolladores instalar cualquier servidor MCP que quieran? La allowlist es tu respuesta. Configúrala antes del kickoff, no después.

Siguiente: Gobernanza de servidores aprobados y la allowlist MCP