Trazar, hacer triage y depurar: herramientas MCP para workspaces agénticos

El artículo principal presentó MCP como la capa que permite a las skills acceder a sistemas externos. Este artículo profundiza un nivel más: qué servidores existen realmente, cómo combinarlos en skills que cierren un ciclo de triage y qué restricciones de seguridad y contexto determinan si el patrón funciona en la práctica.

La idea central: las herramientas MCP para gestionar incidentes no consisten en conectar tantos servidores como sea posible. Se trata de conectar el conjunto mínimo con el alcance mínimo y dejar que las skills orquesten la secuencia. La saturación del contexto es el modo de falla más subestimado, y ya está documentado con cifras concretas.

Esta es la Parte 4 de la serie Workspaces agénticos. Para conocer el modelo de madurez prompt → skill → MCP → plugin y cómo construir un servidor personalizado, consulta La evolución de la orquestación de agentes de IA; este artículo no repite ese tutorial de implementación.

El July 8, 2026 revisé la especificación de MCP, los repositorios y la documentación de servidores de los propios proveedores (GitHub, Atlassian, Linear, Sentry, Datadog, Grafana) y las guías de seguridad de MCP. Los datos sobre el protocolo y la procedencia de los servidores están respaldados por fuentes; los cuatro patrones de skills y los enfoques de alcance se identifican como inferencia editorial.

Audiencia: ingenieros y arquitectos que integran herramientas de triage y depuración, con una perspectiva de visibilidad de la entrega para PMs y scrum masters.

TL;DR

• MCP (anunciado por Anthropic el November 25, 2024; la especificación 2025-11-25 está finalizada y hay una revisión con cambios incompatibles prevista para 2026-07-28; verifica la versión actual) es JSON-RPC 2.0 con tres primitivas de servidor: Tools (funciones que el modelo puede invocar), Resources (contexto de solo lectura) y Prompts (plantillas activadas por el usuario).
• Los servidores de los propios proveedores ya cubren el stack de triage: GitHub (GA Sept 4, 2025), Atlassian Jira/Confluence, Linear (Streamable HTTP desde Feb 2026), Sentry, Datadog, Grafana. Las implementaciones de referencia anteriores @modelcontextprotocol/server-* para estos servicios están archivadas; usa las versiones de los proveedores.
• Las skills componen llamadas MCP (inferencia): el servidor da alcance, la skill aporta secuencia y criterio, además de la conexión con .knowledge/runbooks/.
• La saturación del contexto es real: los esquemas de herramientas de unos pocos servidores pueden consumir una parte considerable de la ventana de contexto antes de que comience cualquier trabajo. Mantén las definiciones de herramientas muy por debajo del ~30% del presupuesto; limita las herramientas activas por agente.
• Nunca des tokens de administrador de producción a un agente en la nube. Prefiere OAuth 2.1, permisos de solo lectura y servidores restringidos por ruta, y condiciona las escrituras a una invocación explícita.

Qué aprenderás aquí

• Lo suficiente de MCP para empezar a construir: primitivas, transportes y ubicaciones de archivos de configuración
• El panorama de servidores de los propios proveedores, con su procedencia y métodos de autenticación
• Cuatro patrones de composición de skills: trazado de incidentes, triage de issues, ciclo de depuración y resumen semanal
• Un .mcp.json mínimo y seguro para el workspace
• Alcance de mínimo privilegio, manejo de secretos y los riesgos de OWASP MCP que importan
• El costo de la saturación del contexto y cómo mantenerlo bajo control

Qué es realmente MCP (lo suficiente para construir)

MCP usa JSON-RPC 2.0 sobre dos transportes: stdio (proceso local) y Streamable HTTP (remoto; reemplazó al transporte SSE, que quedó obsoleto). Tres primitivas del lado del servidor (conceptos de servidor MCP):

Las ubicaciones de los archivos de configuración varían según el cliente:

Una aclaración sobre la procedencia que suele generar confusión: los servidores de referencia mantenidos por Anthropic en modelcontextprotocol/servers para proveedores como GitHub están archivados; la fuente correcta para GitHub es github/github-mcp-server. Los servidores de referencia de Anthropic que siguen activos son Filesystem, Memory, Fetch y Sequential Thinking.

El panorama de servidores

Notas: el repositorio de referencia de Sentry es getsentry/sentry-mcp (la variante -stdio fue reemplazada). El servidor de Datadog se describía como una versión preliminar a principios de 2026 y aparece como GA en comparaciones posteriores; confirma su estado actual en la documentación de Datadog. Grafana autohospedado expone las fuentes de datos con las que esté configurado. PagerDuty, Honeycomb y New Relic también ofrecen servidores MCP si tu stack es diferente.

Diseño de skills que componen llamadas MCP

El patrón (inferencia editorial): una skill es quien ordena la secuencia; MCP proporciona el alcance. La skill aporta criterio, alternativas ante fallas y el vínculo con .knowledge/. Las herramientas MCP proporcionan datos en vivo.

Patrón 1 — Consulta de trazas de incidentes

Alerta o ID de traza → obtener la traza → correlacionarla con el runbook → proponer pasos de triage.

---
name: incident-trace-lookup
description: >
  Fetch a production trace or Sentry issue, correlate with the matching
  .knowledge/runbooks/ entry, and surface triage steps. Use when given a
  trace ID, error message, or Sentry issue URL.
---

1. If given a Sentry URL or error string, call sentry:find_issues.
   If given a trace ID, call datadog:get_trace or grafana:query_traces.
2. Read .knowledge/runbooks/<service>.md via the filesystem server.
   If none exists, note the gap; do not invent runbook steps.
3. Call github:search_issues to check for an existing open issue. Do not
   file a duplicate.
4. Propose triage steps from the runbook, flagging any trace deviation.

  alert / trace id
        │
        ▼
  incident-trace-lookup skill  ◄── .knowledge/runbooks/<svc>.md  (filesystem)
        │
   ┌────┴───────────────┐
   ▼                    ▼
 sentry: find_issues   github: search_issues
 get_sentry_issue      (duplicate? stop)
 call_seer → cause
   │
   ▼
  Triage summary: trace + runbook steps + existing issues + knowledge gap?

Patrón 2 — Ciclo de triage de issues

Nuevo bug o alerta → buscar duplicados en el gestor de issues → adjuntar el contexto de los logs → proponer una rama para la corrección. El paso de creación del ticket es una escritura y debe estar condicionado a una invocación explícita (p. ej., disable-model-invocation: true): lee para hacer triage, escribe solo con la autorización de una persona.

Patrón 3 — Ciclo de depuración

Reproducir → formular una hipótesis → confirmarla. Lee logs y trazas (Sentry call_seer, consultas de logs de Datadog/Grafana), revisa el código fuente relevante y los commits recientes, formula una hipótesis y verifícala mediante una prueba o más datos de trazas. Mantenlo en modo de solo lectura por defecto (inferencia): la corrección propuesta corresponde a un paso separado de edición de código, no a la skill MCP. Una skill de depuración nunca debe modificar el estado de producción.

---
name: debug-loop
description: >
  Read-only reproduce/hypothesize/confirm loop for a failing behavior. Use
  with an error, failing test, or trace. Does NOT edit code or prod state.
---

1. Gather evidence: sentry:call_seer or datadog:get_logs / grafana:query_loki
   around the failure window.
2. Read the implicated source files and github:list_commits for recent changes
   to those paths.
3. State one hypothesis and the single observation that would confirm or refute it.
4. Confirm by reading a test result or additional trace data — do not patch here.
5. Hand off a written hypothesis + evidence to a separate code-edit step.

Patrón 4 — Resumen semanal

Programado y de solo lectura: PRs integrados desde la semana pasada (github:list_pull_requests), issues abiertos del sprint (atlassian/linear), vacíos de conocimiento señalados en .knowledge/README.md y, opcionalmente, el recuento de problemas sin resolver en Sentry. Es seguro ejecutarlo con permisos mínimos y sin aprobación previa: el resultado es un informe.

Un .mcp.json mínimo y seguro para el workspace

{
  "mcpServers": {
    "github":   { "type": "http", "url": "https://api.githubcopilot.com/mcp/",
                  "headers": { "Authorization": "Bearer ${GITHUB_TOKEN}" } },
    "sentry":   { "type": "http", "url": "https://mcp.sentry.dev/mcp" },
    "atlassian":{ "type": "http", "url": "https://mcp.atlassian.com/v1/mcp/authv2" },
    "workspace-fs": { "command": "npx",
                  "args": ["-y", "@modelcontextprotocol/server-filesystem", ".knowledge"] }
  }
}

• Sentry y Atlassian usan OAuth 2.1: no hay ningún token en el archivo; el agente se autentica al usarlos por primera vez.
• GitHub usa expansión de variables de entorno para mantener el token fuera de git; para equipos, prefiere el flujo OAuth.
• workspace-fs está limitado únicamente a .knowledge/, nunca a / ni a $HOME. (Esta es la interfaz en tiempo de ejecución de la capa de conocimiento de la Parte 1; la autenticación de submódulos para agentes en la nube está en la Parte 2.)
• El archivo .cursor/mcp.json de Cursor tiene la misma estructura, con la sintaxis ${env:VAR}.

Mantén fuera de la configuración versionada las claves de Datadog/Grafana, las cuentas de servicio de producción y los PAT con permisos de administrador. Inyéctalos mediante CI o variables de entorno del shell cuando realmente los necesites.

Seguridad: mínimo privilegio y manejo de secretos

 Workspace .mcp.json
 ┌───────────────────────────────────────────────────────┐
 │ READ-ONLY ring (safe for cloud agents):               │
 │   sentry:read   github:issues+PRs read   atlassian:read│
 │   filesystem: .knowledge/ (local, read-only)           │
 │                                                       │
 │ WRITE ring (explicit human trigger only):              │
 │   create ticket | open PR  (disable-model-invocation) │
 │                                                       │
 │ OUT OF SCOPE: prod DB admin | full k8s | deploy tokens │
 └───────────────────────────────────────────────────────┘

Recomendaciones respaldadas por fuentes:

1. Permisos a nivel de herramienta, no comodines. Las mejores prácticas de seguridad de MCP describen un modelo progresivo de mínimo privilegio: permisos iniciales mínimos que se elevan según sea necesario. Evita * / all / full-access.
2. Comienza en modo de solo lectura. Prueba el diseño con consultas e informes antes de habilitar operaciones de escritura, eliminación o ejecución.
3. Una credencial por servidor para limitar el alcance de un posible impacto.
4. No transmitas tokens sin validarlos. Según la especificación, un servidor NO DEBE aceptar tokens que no hayan sido emitidos para él; transmitirlos sin validarlos elude la validación, los límites de tasa y la auditoría.
5. No uses tokens de administrador de producción para agentes en la nube (inferencia a partir de lo anterior): por defecto, limita el acceso a lectura fuera de producción; limita cualquier escritura al recurso específico y exige una invocación explícita.
6. Secretos solo mediante expansión de variables de entorno (${VAR} / ${env:VAR}); valida el JSON antes del commit: una coma final sobrante provoca un error de análisis silencioso.
7. Restringe por ruta donde sea posible. Sentry acepta …/mcp/:org y …/mcp/:org/:project para limitar el alcance de un agente en la nube.

Conviene conocer estos riesgos de OWASP MCP: manejo incorrecto de tokens (MCP01), escalada de privilegios por expansión gradual de permisos (MCP02), envenenamiento de herramientas (MCP03), inyección de comandos (MCP05) y servidores no autorizados o fuera de control (MCP09). Fija las URL de los servidores aprobados y usa una lista de permitidos para controlar lo que los agentes pueden cargar.

Riesgos y límites

Visibilidad de la entrega para PMs y scrum masters

• Avance sin una reunión de estado. Un servidor de GitHub muestra el estado de los PRs y las comprobaciones; uno de Jira/Linear muestra el estado de los tickets. Al integrarlos en una skill de triage, el estado de la entrega se vuelve auditable bajo demanda.
• Condicionar las escrituras es una forma de gobernanza. La distinción entre solo lectura y escritura se relaciona directamente con «quién aprueba esta acción». Las skills con disable-model-invocation: true en las operaciones de escritura hacen cumplir técnicamente esa condición.
• Una señal del sprint con un solo comando. Una skill de resumen semanal convierte los PRs integrados, los issues abiertos y los vacíos de conocimiento en un solo informe.
• Lenguaje de riesgos para el backlog. La saturación del contexto, los fallos de autenticación y los runbooks desactualizados son motivos por los que los ciclos de triage fallan silenciosamente: trátalos como criterios de aceptación para el backlog de skills de la plataforma.

Lista para empezar

1. Elige el conjunto mínimo de servidores para tu stack (GitHub + un gestor de issues + una fuente de observabilidad suele ser suficiente).
2. Define el alcance de la autenticación: OAuth donde esté disponible, solo lectura por defecto y restricciones por ruta (p. ej., Sentry …/mcp/:org).
3. Escribe un SKILL.md de solo lectura (empieza con incident-trace-lookup) que lea un runbook de .knowledge/.
4. Valida el presupuesto de contexto: comprueba cuánto de la ventana consumen los esquemas de herramientas antes de cualquier tarea.
5. Prueba el Patrón 1 de extremo a extremo con un incidente real (fuera de producción).
6. Agrega una operación de escritura (ticket/PR) solo cuando sea necesaria y condicionada a una invocación explícita.

Conclusión

El workspace ya sabe cómo especificar, implementar y revisar trabajo. Las herramientas MCP extienden ese alcance a los sistemas donde ocurren los incidentes —trazas, tickets, logs— sin scripts de integración hechos a medida. La clave es la moderación: conecta el mínimo de servidores con el alcance mínimo, deja que las skills organicen las llamadas, condiciona las operaciones de escritura a una invocación explícita y vigila el presupuesto de contexto. Así, trazar, hacer triage y depurar se convierte en una capacidad confiable del workspace en lugar de un montón de herramientas conectadas a medias.

En la próxima entrega de la serie: cómo convertir cada ejecución de un agente en una mejora de la plataforma mediante retrospectivas de sesión.

Fuentes

Fuentes primarias consultadas el July 8, 2026:

• Especificación de MCP (2025-11-25) — modelcontextprotocol.io/specification/2025-11-25
• Conceptos de servidor MCP — modelcontextprotocol.io/docs/learn/server-concepts
• Mejores prácticas de seguridad de MCP — modelcontextprotocol.io/docs/tutorials/security
• Servidor MCP de GitHub y anuncio de GA (Sept 4, 2025) — github.com/github/github-mcp-server, registro de cambios del blog de GitHub
• Servidor MCP de Atlassian Rovo — github.com/atlassian/atlassian-mcp-server
• MCP de Linear (SSE quedó obsoleto el Feb 5, 2026) — linear.app/docs/mcp
• MCP de Sentry — github.com/getsentry/sentry-mcp, mcp.sentry.dev
• MCP de Datadog (verifica la ruta actual de la documentación y el estado de GA) — docs.datadoghq.com
• Configuración de MCP para Claude Code — code.claude.com/docs/en/mcp
• OWASP MCP Top 10 (guía de seguridad de Azure) — microsoft.github.io/mcp-azure-security-guide
• CSA Lab: mejores prácticas de seguridad para MCP agéntico v1 — labs.cloudsecurityalliance.org
• Análisis de sobrecarga de contexto — EclipseSource, Jan 22, 2026

Inferencia editorial (no son afirmaciones de los proveedores): los cuatro patrones de composición de skills y su redacción en SKILL.md; el enfoque de anillos de lectura y escritura; «el ciclo de depuración es de solo lectura por defecto»; el límite de ~20 herramientas; la combinación de restricciones de ruta de Sentry con la configuración del workspace. Valídalo con tu stack; varios servidores están evolucionando.

Artículos relacionados de esta serie:

• Parte 1: Workspaces agénticos: submódulos, skills, conocimiento y entrega guiada por especificaciones
• Parte 3: Ejecución de workspaces agénticos en la nube a escala
• Parte 5: Retrospectivas de sesión: cómo convertir las ejecuciones de agentes en mejoras de la plataforma
• Relacionado: La evolución de la orquestación de agentes de IA