Agent Observatory 如何在本機檢查編碼智能體工作階段及失敗的 MCP 呼叫

When several coding-agent sessions are open, the first debugging question is simple: which session is waiting, and what did it last do? Answering it from raw session logs means matching a session ID to a project, then following the relevant tool records.

Agent Observatory is a local terminal and browser dashboard for inspecting supported Codex and Claude Code session records. It also receives OpenTelemetry from agents you instrument. The views are organized around sessions, activity, recorded MCP calls, traces, and host processes.

Try it

You need Python 3.11+ and uv. On a machine with recent Codex or Claude Code sessions, run:

uvx --from agent-observatory-cli agent-observatory

The terminal opens first. Press b to open the local browser dashboard. The receiver listens on 127.0.0.1:14318 and stores captured data in a local SQLite file.

Open Agents and choose a session. The row shows the runtime, session ID, project, observed status, last update, and current or last task where the source reported them. The detail view adds the model, usage, and recent work. A session can only be marked waiting when the source actually reports a wait; the dashboard does not infer an unrecorded reason.

Next, open MCP Calls. This shows servers with recorded calls in the selected scope. Inspect a call to read its recorded arguments, result, duration, and linked trace. Follow the trace to see the surrounding operations and error evidence. The MCP view does not inventory every server configured on your machine.

If your agent is not a supported local runtime, send OTLP/HTTP telemetry or use the project's Python and JavaScript clients. The visible detail depends on what that agent emits.

What to check on your first run

If the dashboard is empty, start a Codex or Claude Code task and check that the tool can read its local session records. For another runtime, configure telemetry export first. The first-minute guide documents the views and key bindings.

The GIF above uses synthetic records. Actual captured content may include prompts, tool arguments, and project details, so review the project's privacy and capture boundaries before recording or sharing a real session.

This workflow is useful whenever a task appears stalled or a tool result looks wrong: identify the session, inspect the last recorded action, then follow the call into its trace. It also shows where the evidence ends. If the source did not record a wait reason or an MCP call, the dashboard cannot reconstruct it.

I would like to hear which missing source fields make this investigation difficult in your own setup. You can report a reproducible case in the project's issue tracker.

Disclosure: This article was prepared with AI assistance. The installation command and linked project pages were checked before publication.