Trace, Triage, Debug: MCP Tooling for Agentic Workspaces

The flagship article introduced MCP as the layer that lets skills reach external systems. This article goes one level deeper: which servers actually exist, how to compose them into skills that close a triage loop, and what safety and context constraints make or break the pattern in practice.

The throughline: MCP tooling for incident work is not about connecting as many servers as possible. It is about connecting the minimum set at the minimum scope, then letting skills orchestrate the sequence. Context bloat is the most underappreciated failure mode — and it is already documented with hard numbers.

This is Part 4 of the Agentic Workspaces series. For the prompt → skill → MCP → plugin maturity model and how to build a custom server, see The Evolution of AI Agent Orchestration; this article does not repeat that build tutorial.

On July 8, 2026 I reviewed the MCP specification, first-party server repos and docs (GitHub, Atlassian, Linear, Sentry, Datadog, Grafana), and MCP security guidance. Protocol facts and server provenance are source-backed; the four skill patterns and scope framings are labeled editorial inference.

Audience: engineers and architects wiring triage/debug tooling, with a delivery-visibility lens for PMs and scrum masters.

TL;DR

• MCP (announced by Anthropic on November 25, 2024; spec 2025-11-25 finalized, with a breaking-change revision slated for 2026-07-28 — verify the current version) is JSON-RPC 2.0 with three server primitives: Tools (model-callable functions), Resources (read-only context), and Prompts (user-triggered templates).
• First-party servers now cover the triage stack: GitHub (GA Sept 4, 2025), Atlassian Jira/Confluence, Linear (Streamable HTTP since Feb 2026), Sentry, Datadog, Grafana. The older @modelcontextprotocol/server-* reference implementations for these are archived — use the vendor builds.
• Skills compose MCP calls (inference): the server gives reach, the skill gives sequence and judgment — and the connection to .knowledge/runbooks/.
• Context bloat is real: tool schemas from a few servers can consume a large share of the context window before any work begins. Keep tool definitions well under ~30% of budget; cap active tools per agent.
• Never give a cloud agent production admin tokens. Prefer OAuth 2.1, read-only scopes, path-constrained servers, and gate writes behind explicit invocation.

What You Will Learn Here

• Just enough MCP to build with: primitives, transports, config file locations
• The first-party server landscape with provenance and auth methods
• Four skill composition patterns: incident trace, issue triage, debug loop, weekly digest
• A minimal, safe workspace .mcp.json
• Least-privilege scoping, secret handling, and the OWASP MCP risks that matter
• The context-bloat tax and how to stay under it

What MCP Actually Is (Enough to Build With)

MCP uses JSON-RPC 2.0 over two transports: stdio (local process) and Streamable HTTP (remote; it replaced the deprecated SSE transport). Three server-side primitives (MCP server concepts):

Config file locations differ by client:

Provenance note that trips people up: the Anthropic-maintained reference servers in modelcontextprotocol/servers for vendors like GitHub are archived; the correct source for GitHub is github/github-mcp-server. The still-active Anthropic reference servers are Filesystem, Memory, Fetch, and Sequential Thinking.

The Server Landscape

Notes: Sentry’s authoritative repo is getsentry/sentry-mcp (the -stdio variant is superseded). Datadog’s server was described as preview in early 2026 and appears GA in later comparisons — confirm current status in Datadog’s docs. Self-hosted Grafana exposes whatever datasources it is configured with. PagerDuty, Honeycomb, and New Relic also ship MCP servers if your stack differs.

Designing Skills That Compose MCP Calls

The pattern (editorial inference): a skill is the sequencer; MCP is the reach. The skill provides judgment, fallback, and the tie to .knowledge/. MCP tools provide live data.

Pattern 1 — Incident trace lookup

Alert or trace ID → fetch trace → correlate with the runbook → propose triage steps.

---
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?

Pattern 2 — Issue triage loop

New bug/alert → dedupe in the tracker → attach log context → propose a fix branch. The ticket-creation step is a write and should be gated behind explicit invocation (e.g., disable-model-invocation: true) — read to triage, write only on a human’s say-so.

Pattern 3 — Debug loop

Reproduce → hypothesize → confirm. Read logs/traces (Sentry call_seer, Datadog/Grafana log queries), read the relevant source and recent commits, form a hypothesis, verify against a test or more trace data. Keep it read-only by default (inference): the proposed fix belongs in a separate code-edit step, not inside the MCP skill. A debug skill should never mutate production state.

---
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.

Pattern 4 — Weekly digest

Read-only, scheduled: merged PRs since last week (github:list_pull_requests), open sprint issues (atlassian/linear), knowledge gaps flagged in .knowledge/README.md, optionally unresolved Sentry counts. Safe to run with minimal scopes and no review gate — the output is a report.

A Minimal, Safe Workspace .mcp.json

{
  "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 and Atlassian use OAuth 2.1 — no token in the file; the agent authenticates on first use.
• GitHub uses env-var expansion so the token stays out of git; prefer the OAuth flow for teams.
• workspace-fs is scoped to .knowledge/ only — never / or $HOME. (This is the runtime face of the knowledge layer from Part 1; submodule auth for cloud agents is in Part 2.)
• Cursor’s .cursor/mcp.json is the same shape with ${env:VAR} syntax.

Keep out of the committed config: Datadog/Grafana keys, prod service accounts, and admin-scoped PATs. Inject those via CI or shell env when actually needed.

Safety: Least Privilege and Secret Handling

 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 │
 └───────────────────────────────────────────────────────┘

Source-backed guidance:

1. Tool-level scopes, not wildcards. The MCP security best practices describe a progressive least-privilege model — minimal initial scopes, elevate on demand. Avoid * / all / full-access.
2. Start read-only. Prove the design with retrieval and reporting before enabling write/delete/execute paths.
3. One credential per server to bound blast radius.
4. No token passthrough. Per the spec, a server MUST NOT accept tokens not issued for it — passthrough bypasses validation, rate limiting, and audit.
5. No prod admin tokens for cloud agents (inference from the above): scope to read on non-production by default; scope any write to the specific resource at explicit invocation.
6. Secrets via env expansion only (${VAR} / ${env:VAR}); validate JSON before commit — a stray trailing comma silently breaks parsing.
7. Path-constrain where supported. Sentry accepts …/mcp/:org and …/mcp/:org/:project to limit a cloud agent’s reach.

OWASP MCP risks worth knowing: token mismanagement (MCP01), privilege escalation via scope creep (MCP02), tool poisoning (MCP03), command injection (MCP05), and shadow/unapproved servers (MCP09). Pin approved server URLs and use an allowlist for what agents may load.

Risks and Limits

Delivery Visibility for PMs and Scrum Masters

• Progress without a status meeting. A GitHub server surfaces PR and check state; a Jira/Linear server surfaces ticket state — wired into a triage skill, delivery status becomes auditable on demand.
• Write-gating is governance. The read-only-vs-write distinction maps directly to “who approves this action.” Skills with disable-model-invocation: true on write paths enforce that gate technically.
• One-command sprint signal. A weekly-digest skill turns merged PRs vs open issues vs knowledge gaps into a single report.
• Risk language for the backlog. Context bloat, auth failures, and stale runbooks are the reasons triage loops fail silently — treat them as acceptance criteria for the platform skill backlog.

Getting Started Checklist

1. Pick the minimum server set for your stack (GitHub + one issue tracker + one observability source is usually enough).
2. Scope auth: OAuth where offered, read-only by default, path-constrain (e.g., Sentry …/mcp/:org).
3. Write one read-only SKILL.md (start with incident-trace-lookup) that reads a runbook from .knowledge/.
4. Validate the context budget — check how much of the window tool schemas consume before any task.
5. Test Pattern 1 end to end on a real (non-production) incident.
6. Add a write path (ticket/PR) only when needed, gated behind explicit invocation.

Conclusion

The workspace already knows how to specify, implement, and review work. MCP tooling extends that reach into the systems where incidents actually live — traces, tickets, logs — without bespoke glue scripts. The winning move is restraint: connect the minimum servers at the minimum scope, let skills sequence the calls, keep write paths behind explicit invocation, and watch the context budget. Do that, and trace-triage-debug becomes a reliable workspace capability instead of a pile of half-connected tools.

Next in the series: turning each agent run into a platform improvement through session retrospectives.

Sources

Primary sources consulted July 8, 2026:

• MCP specification (2025-11-25) — modelcontextprotocol.io/specification/2025-11-25
• MCP server concepts — modelcontextprotocol.io/docs/learn/server-concepts
• MCP security best practices — modelcontextprotocol.io/docs/tutorials/security
• GitHub MCP server + GA announcement (Sept 4, 2025) — github.com/github/github-mcp-server, github.blog changelog
• Atlassian Rovo MCP server — github.com/atlassian/atlassian-mcp-server
• Linear MCP (SSE deprecation Feb 5, 2026) — linear.app/docs/mcp
• Sentry MCP — github.com/getsentry/sentry-mcp, mcp.sentry.dev
• Datadog MCP (verify current docs path and GA status) — docs.datadoghq.com
• Claude Code MCP config — code.claude.com/docs/en/mcp
• OWASP MCP Top 10 (Azure security guide) — microsoft.github.io/mcp-azure-security-guide
• CSA Lab: Agentic MCP Security Best Practices v1 — labs.cloudsecurityalliance.org
• Context-overload analysis — EclipseSource, Jan 22, 2026

Editorial inference (not vendor claims): the four skill composition patterns and their SKILL.md wording; the read-ring/write-ring framing; “debug loop is read-only by default”; the ~20-tool cap; combining Sentry path constraints with workspace config. Validate against your stack; several servers are evolving.

Related in this series:

• Part 1: Agentic Workspaces: Submodules, Skills, Knowledge, and Spec-Driven Delivery
• Part 3: Running Agentic Workspaces in the Cloud at Scale
• Part 5: Session Retrospectives: Turning Agent Runs into Platform Improvements
• Related: The Evolution of AI Agent Orchestration