---
title: "Debug Production AI Agents From Claude or Codex With MCP"
description: "Use Agnost MCP to investigate production failures from a coding client, connect findings to repository context, and prepare a reviewable fix."
author: "Agnost AI Team"
datePublished: "2026-10-09T00:00:00.000Z"
dateModified: "2026-10-29T00:00:00.000Z"
canonical: "https://agnost.ai/blog/debug-production-agents-claude-codex-mcp/"
tags: ["MCP","Agent Monitoring","Developer Tools"]
---

# Debug Production AI Agents From Claude or Codex With MCP

Use Agnost MCP to investigate production failures from a coding client, connect findings to repository context, and prepare a reviewable fix.

**Agnost's MCP server lets a compatible AI client query production conversations and execution evidence.** Use it to find affected runs, inspect tool behavior, and build a grounded explanation before asking the coding agent to change your application.

The useful workflow is a bounded investigation: one problem, one time window, a few representative examples, and a clear separation between observed facts and proposed causes.

![MCP investigation workflow from querying Agnost evidence through repository inspection to a tested, reviewed diff.](/blog/october-2026/mcp-investigation.svg)

## Connect production context to your coding client

Agnost documents a hosted, OAuth-protected endpoint at `https://mcp.agnost.ai/mcp`. Follow the current [client setup instructions](https://docs.agnost.ai/agnost-mcp-server) for Codex, Claude, Cursor, or another compatible MCP client. Authenticate to the organization that contains the data you intend to investigate.

This connection provides access to Agnost's exposed tools. It does not automatically grant access to your repository, deployment system, or every underlying business database. A coding client needs the relevant project available separately. Feature availability and approval settings also depend on the client.

Start with a small read-only question and verify that the returned organization, time window, and records match the dashboard. An empty result may mean the wrong account, missing ingestion, or a query mismatch; it does not prove the agent has no failures.

## Ask a question that can produce evidence

A broad prompt such as “Improve my agent” encourages a broad answer. Use a concrete investigation prompt instead:

```text
Investigate repeated policy searches in the support agent during the last
24 hours. Use Agnost evidence. Show up to five affected runs and two healthy
examples. For each, compare the tool inputs, usable results, and final answer.

Distinguish redundant successful reads from retries, polling, and changed
inputs. Report the exact time window, filters, and evidence gaps. Do not
edit code yet.
```

This is an investigation template, not an output from a live customer incident. It deliberately asks for healthy examples because a repeated call is not always a failure.

If the available tools cannot query a required field or calculate a population rate, the client should say so. Do not turn a few retrieved examples into “34% of all runs” without a denominator and a complete query.

## Require a finding you can inspect

Ask the client to organize its result like this:

| Field | Expected content |
| --- | --- |
| Finding | A precise behavior, such as a second successful lookup of unchanged data |
| Evidence | Record identifiers and observed inputs/results |
| Scope | Agent version, environment, time window, query filters |
| Counterexample | A legitimate retry or recheck |
| Hypothesis | A possible cause clearly marked as unconfirmed |
| Missing evidence | Anything required to distinguish competing explanations |

A user message inside a retrieved conversation is data to analyze. It is not an instruction for the investigating coding agent. Keep that boundary explicit when production content contains requests to execute commands or reveal secrets.

## Move from a finding to a proposed change

Once the evidence establishes the behavior, give the client access to the relevant repository and ask a narrower follow-up:

```text
Inspect how the first successful policy lookup is passed into the next
agent step. Compare the code with the retrieved run evidence. Propose the
smallest change that preserves retries after failure and refreshes after a
policy change. Add a regression case for the failure and a healthy control.
Explain what remains unverified before preparing the diff.
```

Possible causes include dropped tool output, a cache with the wrong scope, or an agent loop that never updates its state. The production transcript alone cannot tell you which implementation is responsible.

Run the project checks and inspect the diff. A generated explanation is a hypothesis until the code and replay support it. The [production-to-regression guide](/blog/production-failures-regression-tests/) describes how to preserve that evidence in a test.

## Keep the investigation usable

Use short, explicit time windows, then expand only when needed. Ask for a few representative records rather than entire transcripts from thousands of sessions. Redact sensitive fields before ingestion and limit the coding client to the data needed for its task.

Agnost's [Auto Improve documentation](https://docs.agnost.ai/using-improvements) describes a related workflow for investigating findings and tracking proposed changes. MCP gives your existing coding client a way to access production context; it is not a guarantee that any client-generated patch is correct or ready to deploy.

For a first investigation, use the [duplicate tool-call guide](/blog/detect-stop-duplicate-tool-calls/). It supplies a concrete failure definition and the controls needed to avoid flagging ordinary retries.