Debug LLM Traces from Claude Code or Cursor

▣AUGUST 24, 2026

MCP lets Claude Code or Cursor query production observability data from the editor. Connect the remote server through OAuth, start with read-only tools, and narrow from an aggregate symptom to representative sessions, spans, metadata, and a testable diagnosis. Require trace evidence before the coding agent changes the repository.

In practice, that means six evidence artifacts: a bounded metric, representative trace IDs, the failing span, a context comparison, competing hypotheses, and a regression assertion. The sequence protects you from a plausible diagnosis built from one unusual trace.

What are the two meanings of MCP observability?

The phrase covers two separate jobs.

Job	What it observes	Typical question	Required instrumentation
Query observability data through MCP	Stored sessions, traces, spans, scores, costs, tools, and users	“Which sessions started failing after release 2026.08.24?”	An observability backend that exposes read tools through an MCP server
Trace MCP protocol traffic	MCP client/server interactions and individual tool calls	“Why did `tools/call` fail, or where did context propagation break?”	Spans around MCP requests, tool execution, and linked application work

The first gives the coding agent access to evidence. The second makes the MCP integration itself observable. Many investigations need both, but their setup and data are distinct.

How do you connect Claude Code or Cursor safely?

For a remote server, prefer Streamable HTTP with OAuth. The MCP authorization specification binds access tokens to the intended resource, requires PKCE, and forbids tokens in query strings (MCP authorization specification).

Claude Code recommends remote HTTP for cloud services. A generic setup is:

claude mcp add --transport http latitude https://api.latitude.so/v1/mcp
claude mcp get latitude

Then open /mcp inside Claude Code to complete authentication or inspect server status. The Claude Code documentation also supports project scope, but project configuration files require workspace trust and approval.

Cursor documents three transport methods: stdio, SSE, and Streamable HTTP. Remote SSE and Streamable HTTP servers support OAuth. A project-level configuration uses .cursor/mcp.json:

{
  "mcpServers": {
    "latitude": {
      "url": "https://api.latitude.so/v1/mcp"
    }
  }
}

Cursor’s MCP documentation says tool calls require approval by default. Enterprise teams can also allowlist server URLs and individual tools.

Use this least-privilege checklist:

Authenticate through the client’s OAuth flow.
Scope access to the required project and environment.
Enable read-only trace and analytics tools first.
Review whether prompts, responses, retrieved documents, and tool payloads contain sensitive data.
Check payload retention before assuming old content is still available.
Put every mutation behind an explicit approval gate.

Which tools should be read-only first?

A read-only investigation needs search, retrieval, and analytics. It does not need to create scores, change Signals, import datasets, or resolve incidents.

Tool class	Examples from Latitude’s MCP surface	Initial policy
Trace discovery	`listTraces`, `querySpans`, `getTraceAnalytics`	Allow read-only
Trace inspection	`getTrace`, `listTraceSpans`, `getTraceSpan`	Allow read-only with content access reviewed
Tool diagnostics	`getToolErrors`, `getToolParameters`, `getToolCoOccurrence`	Allow read-only
Pattern analytics	`listSignals`, `getSignalAnalytics`, `getSignalTrend`, `listSignalTraces`	Allow read-only
Dataset inspection	`listDatasets`, `listDatasetRows`	Allow read-only
Workspace mutation	`createAnnotation`, `createScore`, `updateSignal`, `createMonitor`	Require explicit gate
Test-set mutation	`importDatasetRowsFromTraces`	Require explicit gate and trace review

Tool names are server-specific. Ask the client to list the connected server’s tools before using a prompt written for another provider.

What five-step query sequence finds a root cause?

A reliable investigation narrows the search. PostHog’s first-party MCP guide uses the same basic progression: list relevant traces, inspect one end to end, and then run focused aggregation or comparison (PostHog).

1. Measure the symptom

Ask for a time-bounded rate, count, or distribution. Include environment and release.

Expected artifact: metric definition, numerator, denominator, time window, filters, and comparison baseline.

2. Find representative failures

Retrieve several failures plus several nearby successes. A single dramatic trace can mislead.

Expected artifact: session or trace IDs, timestamps, score or failure reason, and selection method.

3. Inspect the full tree and content

Read the parent-child span order, relevant messages, retrieval results, tool arguments, tool outputs, and final answer. Anthropic calls this complete record a transcript or trace and recommends checking it because final outcomes can hide a broken trajectory (Anthropic).

Expected artifact: failing span, upstream inputs, downstream effect, and environment outcome.

4. Compare execution context

Slice successes and failures by prompt version, request and response model, release, tool, cohort, and retrieval source. OpenTelemetry defines fields for conversation IDs, models, retrieval documents, tool arguments/results, token usage, and evaluator scores (OpenTelemetry GenAI registry).

Expected artifact: a compact comparison table with sample sizes.

5. Form and test a diagnosis

State competing hypotheses and identify the smallest check that separates them. Reproduce the failure from a trace or add it to a regression dataset before changing code.

Expected artifact: evidence-backed diagnosis, confidence, disconfirming evidence, and a proposed regression assertion.

Which prompts are useful in Claude Code or Cursor?

Objective	Copyable prompt	Minimum filters	Expected output
Cost regression	“Compare LLM cost per successful session before and after release 2026.08.24. Break down the delta by model and prompt version.”	Release, environment, success definition	Cost distribution, sample sizes, changed model/prompt
Tool failure	“Find production sessions where `send_refund` failed or returned an error in the last 24 hours. Group exact error signatures and show three representative traces.”	Environment, time, tool	Error groups, counts, trace IDs, payload evidence
Hallucinated success	“Find sessions where the assistant claimed completion but the tool result or final environment state did not confirm it.”	Outcome definition, time	Candidate sessions, contradictory span/result, confidence
Loop	“Find sessions with repeated calls to the same tool and no changed result. Report call count, arguments, duration, and final outcome.”	Tool sequence, minimum repeats	Loop candidates and span trees
Prompt or model regression	“Compare failure rate by prompt and response model across the latest two releases. Then show matched failing and successful traces.”	Releases, evaluator, model	Rate table and paired examples
One user investigation	“Retrieve this user’s session, show the full span tree, identify the first failing step, and cite every trace field used in the diagnosis.”	User/session ID, authorized project	Ordered evidence and bounded hypothesis

These prompts deliberately ask for evidence artifacts. Avoid prompts such as “find the root cause and fix it” before the agent has established the time window, denominator, representative examples, and competing explanations.

What evidence must the coding agent return?

Require this schema before accepting a diagnosis:

investigation:
  time_range: "..."
  filters: [environment, release, cohort]
  metric:
    name: "..."
    numerator: "..."
    denominator: "..."
  representative_cases:
    failing_trace_ids: ["..."]
    successful_trace_ids: ["..."]
  failing_step:
    span_id: "..."
    operation: "..."
    tool_input: "redacted or referenced"
    tool_output: "redacted or referenced"
  context:
    prompt_version: "..."
    request_model: "..."
    response_model: "..."
    release: "..."
  recurrence:
    occurrences: 0
    affected_sessions: 0
  hypotheses:
    leading: "..."
    alternatives: ["..."]
    confidence: "low | medium | high"
  regression_assertion: "..."

OpenTelemetry warns that messages and tool payloads may contain PII. The report can reference protected fields or provide redacted excerpts while keeping trace IDs for authorized reviewers.

How does a trace become an opened PR?

Use a gated handoff:

Verify the failing trace and recurrence pattern.
Import reviewed examples into a regression dataset or encode a deterministic test.
Give the repository-aware coding agent the trace IDs, failure definition, expected outcome, and test.
Ask for the smallest code or prompt change that makes the test pass.
Run the relevant suite and inspect unrelated regressions.
Let the coding agent open a PR with evidence and test results.
Keep merge control with a human.
Query the same production failure rate after deployment.

The test is essential. An MCP connection gives the agent access to evidence, but access alone does not make the diagnosis correct.

What does this workflow look like with Latitude MCP?

Latitude’s MCP server exposes aggregate analytics, trace and span retrieval, tool diagnostics, Signal analytics, and dataset reads. The portable workflow maps to the product’s Observe, Understand, Fix, Verify loop:

Observe: query aggregate trace or tool analytics.
Understand: retrieve representative sessions, inspect spans, and attach the occurrence to a confirmed Signal.
Fix: Agent Dispatch sends Signal context and sample traces to the team’s Claude Code or Cursor agent. That agent changes the repository and opens a PR.
Verify: query the Signal trend and regression score after deployment.

A real Signal is useful here because it preserves examples, occurrence history, and lifecycle. Gerard from Latitude’s engineering team describes it as “the only one that can track that signal over a large data corpus and long time horizon.”

Frequently asked questions

Can I paste an API key into the prompt?

Do not do that. Use OAuth for remote HTTP servers or environment-backed credentials for local stdio servers. The MCP authorization specification requires bearer tokens in the Authorization header and forbids them in query strings.

Does MCP execute observability queries automatically?

The client selects and calls tools exposed by the server. Claude Code and Cursor show connection and tool status, and both provide approval controls. Server-specific tools determine which searches and mutations are possible.

How is this different from tracing MCP tool calls?

Querying through MCP reads telemetry already stored in an observability backend. Tracing MCP traffic instruments the protocol requests and tool execution themselves. One is an access path; the other produces telemetry.

Should the coding agent have write access immediately?

Begin with read-only trace and analytics tools. Gate annotations, scores, Signal changes, dataset imports, monitors, incident resolution, and repository writes separately.

What if trace content has expired?

Metadata and payload retention can differ. PostHog, for example, documents a 30-day default for large AI content fields in its posthog.ai_events table. Check the connected backend’s current retention before promising a historical investigation.

Who merges the PR?

A human. Latitude hands evidence to the team’s coding agent, and that agent can open the PR. Latitude does not edit or merge repository code.