# The developer console and MCP

The same evidence is also there as a web page, and as tools for an agent
that can't run commands. An agent that can run commands, such as Claude
Code, Codex or Cursor, uses `jadpo` with `--json`, and `jadpo help --json`
for the command reference. That is enough for building an app.

## The developer console

`jadpo dev` serves a local page on its own port. It shows recent requests
and their timelines, errors grouped by place, slow routes and queries,
schedule runs and deliveries with their attempts and states
([How a delivery runs](delivery-at-least-once-safe-to-repeat.md#how-a-delivery-runs)), and
the reports in `build/report/`: permissions, personal data, schema and
queries.

The console only reads. To retry or dismiss a delivery, you run
`jadpo deliveries`
([Commands for background work](commands-for-background-work.md)),
and the console shows you how.

## The application graph

The application graph is the compiler's call graph: route → action → query
→ entity, and event → subscriber. It is drawn per domain and opened one
level at a time, with each node linked to its source and its `///`
description. In `jadpo dev`, nodes are coloured by recent traffic, failures
and time spent, and a request you select lights up its path.

## The MCP server

`jadpo mcp` gives an agent the same evidence as read-only tools: `trace`,
`why`, `incident`, `impact`, `sql`, `routes`, the reports and the graph.
It is for agents with no shell, mostly investigating production from a
chat or a hosted tool.

It can't write data, retry deliveries or edit code; a person or an agent
runs commands for those, deliberately. It is generated from the same
command reference as `jadpo`, so the two always match. It is protected by
your app's own OAuth ([Identity](identity.md)).

## Production monitoring

For production, use your OpenTelemetry tools. The console is for your
machine.