Skip to main content
Glama
README.md
# AgentHub Monitor

An MCP **App** server: it renders an interactive pipeline dashboard *inside* the host window
(Claude Desktop, Claude Code, and other MCP App–capable clients) instead of returning a wall of text.

The dashboard shows two things side by side:

- **DAG state** — nodes of a pipeline run, grouped into waves, each with its own status.
- **Harness metrics** — scenario pass rate, critical failures, accumulated cost and latency.

Point it at your own pipeline's JSON export and it becomes a live view of your runs. With no
configuration it serves a built-in sample, so the UI is useful the moment you install it.

## Tools

| Tool | What it does | Read-only |
|---|---|---|
| `show_agenthub_monitor` | Renders the dashboard inline in the host | yes |
| `get_status` | Returns the current pipeline state as structured JSON | yes |
| `trigger_action` | Records an action request in the server's own state | no |

**`trigger_action` does not execute anything.** It annotates the server's in-memory state so the
dashboard can show that an action was requested. This server runs no commands, spawns no
processes, and makes no network calls.

## Install

Requires Python 3.10+. No third-party dependencies.

```bash
git clone https://github.com/NEVELSK65/mcp-agenthub-monitor.git
cd mcp-agenthub-monitor
python3 -m unittest discover -s tests    # optional: verify
```

## Configure

Add to your MCP client configuration:

```json
{
  "mcpServers": {
    "agenthub-monitor": {
      "command": "python3",
      "args": ["/absolute/path/to/mcp-agenthub-monitor/server.py"],
      "env": {
        "AGENTHUB_STATE_FILE": "/absolute/path/to/your/pipeline-state.json"
      }
    }
  }
}
```

`AGENTHUB_STATE_FILE` is optional. Without it the server returns sample data, flagged with
`is_sample_data: true` so it is never mistaken for a real run.

## State file format

Write this JSON from your own CI, orchestrator, or test harness:

```json
{
  "dag": {
    "title": "Nightly build",
    "total_nodes": 6,
    "completed_nodes": 4,
    "waves": 3,
    "node_states": {
      "node_01_checkout": "COMPLETED",
      "node_02_unit_tests": "COMPLETED",
      "node_03_integration": "RUNNING",
      "node_04_security_scan": "PENDING"
    }
  },
  "harness": {
    "pass_rate_pct": 93.75,
    "total_scenarios": 16,
    "passed_scenarios": 15,
    "critical_failures": 0,
    "total_cost_usd": 0.112,
    "total_latency_ms": 41700
  },
  "log": "Integration stage in progress."
}
```

The file is re-read on every tool call, so the dashboard reflects whatever your pipeline last wrote.
Node status strings are passed through to the UI as-is; `COMPLETED`, `RUNNING`, `PENDING` and
`FAILED` get distinct colours.

## Resource

The UI is exposed as an MCP resource at `ui://agenthub/mcp-app.html` with MIME type
`text/html;profile=mcp-app`. Hosts that support MCP Apps render it inline; hosts that do not can
still read it as an HTML document.

## Privacy

The server reads one local file (the one you name in `AGENTHUB_STATE_FILE`) and sends nothing
anywhere. See [PRIVACY.md](PRIVACY.md).

## License

MIT — see [LICENSE](LICENSE).

TDQS

A3.8/5.0

Scored across 3 tools

Disambiguation4/5

get_status and show_agenthub_monitor both surface the same pipeline state and could be confused at a glance, but they differ clearly in output form (structured JSON vs. rendered inline dashboard). trigger_action is distinct in that it only annotates state rather than reading it. The descriptions explicitly clarify these boundaries.

Naming Consistency4/5

get_status and trigger_action follow a clean verb_noun pattern, while show_agenthub_monitor bakes the server name into the noun (show_<server>_monitor). This is a minor deviation but still readable and predictable in intent.

Tool Count4/5

Three tools is on the thin side, but for a narrow monitor-and-annotate purpose each tool earns its place: read state, render dashboard, record an action request. No padding or redundant tools.

Completeness3/5

The surface covers reading and rendering state plus recording an action, but there is no way to clear or acknowledge a recorded action, and no per-node querying or filtering. These gaps leave agents at a dead end after triggering an action, though the core monitoring loop works.

Maintenance

ActivityMaintained
ResponsivenessNo issues