Agent Watch — Monitoring for the Agent Economy

Continuous liveness, latency, schema-drift, auth-posture, and price-integrity monitoring for MCP endpoints and paid agent services (x402/MPP).

We ran a full liveness census of the official MCP registry: 7,454 endpoints probed, 65.6% dead. Live census data →

Try it in 30 seconds — no signup

Probe any MCP endpoint from your browser: status page → probe widget

Or curl:

curl -X POST https://agent-watch-api-production.up.railway.app/v1/probe \
  -H "Content-Type: application/json" \
  -d '{"url":"https://any-mcp-endpoint.com/mcp/"}'

Install (MCP clients)

Add to your MCP client config (Claude Desktop, Cursor, any streamable-http client):

{
  "mcpServers": {
    "agent-watch": {
      "url": "https://agent-watch-api-production.up.railway.app/mcp/"
    }
  }
}

Tools: aw_health, aw_check_endpoint, aw_census, aw_list_monitored, aw_alerts, aw_watch (watchlists with plan quotas).

Agent-facing API reference: llms.txt

Pricing

Pay → onboarding email → POST /v1/watch with your endpoints → 6-hourly probe cron → alerts when one goes down or its tool schema drifts.

Architecture

• Probe engine (probes/probe_engine.py): real MCP initialize handshake → tools/list, p50/p95 latency, tool-schema hash (drift detection), RFC 9728 auth-metadata check. Fallback HTTP-402 probe for paid non-MCP services.
• REST API (api_server.py, FastAPI): /health, /v1/probe, /v1/census, /v1/endpoints, /v1/alerts, /v1/watch, /v1/cron/probe, /stripe/webhook, hosted streamable-http MCP at /mcp/.
• Boot seeding (census_seed.py): the full registry census ships as code — fresh containers boot with 7,454 endpoints of liveness data, no network needed.
• Grantwatch (grantwatch/): OAuth scope-drift monitoring for Google Workspace tenants (findings only, never graded; authority-gated).

Trust scoring

compute_trust_score() turns probe history into a 0–100 / A–F score: uptime (40), schema stability (15), auth posture (10), price stability (10). Honest states: alive / dead / unknown (auth-gated — server answered, liveness unprovable without credentials). No fake GREEN states.

Project internals (internal doc below — public summary above)

Status: Two capabilities, two different maturity levels (see below). Frame card: frame-card.md (original MCP-monitoring scope). Grantwatch's own design/plan live in the parent AI-Workbench repo: docs/superpowers/specs/2026-09-05-grantwatch-oauth-scope-monitoring-design.md and docs/superpowers/plans/2026-09-05-grantwatch-oauth-scope-monitoring.md. Sibling project: ~/AI-Workbench/projects/perimeter-watch/ — Agent Watch reuses Perimeter Watch's live Stripe account (GASPERMIT acct) rather than standing up new billing.

What this is

Agent Watch monitors the agent economy from two directions:

1. Supply side (original, live in production): liveness, latency, schema-drift, price-integrity, and auth-posture monitoring for MCP registry endpoints and x402/paid agent services. "Is this endpoint alive and honest about what it does?"
2. Demand side (Grantwatch, new, not yet customer-facing): for an SMB's own Google Workspace tenant, which third-party AI agents/apps hold OAuth grants, whether granted scope matches actual usage, and whether any grant looks abandoned or still-active-when-it-shouldn't-be. "Which AI agents did your employees let in, and are they behaving?"

Both are sold to the same buyer profile (SMB/MSP), reuse the same infrastructure pattern (probe/ingest → baseline → drift diff → alert), and are packaged under one product, not two.

Capability 1: MCP/agent-endpoint monitoring (supply side)

Status: deployed and registry-listed. No paid tier wired yet.

Resolved: the original frame card's metered billing went live 2026-09-07 (Builder/Team tiers, webhook fulfillment, onboarding email). Capability 1 is a shipped, monetized, registry-listed product.

Capability 2: Grantwatch — OAuth scope drift monitoring (demand side)

Status: engine complete on feature/grantwatch, Turing-approved (27/27 tests passing), not yet merged, not yet customer-facing.

Hard rules (same discipline as Perimeter Watch)

1. No customer tenant is ever scanned without written authority confirmation. The scan gate (tenants_authorized.txt) is the enforcement point.
2. Read-only, always. Grantwatch never writes to a customer's tenant.
3. No graded verdict, ever. No score, no percentage, no Red/Amber/Green badge — findings only, plus explicit coverage disclosure of what wasn't checked. This was a deliberate architecture decision after an adversarial review found that "cryptographic proof of correct agent behavior" overclaims what's actually observable (you can prove a log wasn't tampered with, not that it's complete).
4. Kill criteria (K1/K2 above) are binding, matching Perimeter Watch's pattern.

Blocking conditions before scanning any real customer tenant (Morgan gate, 2026-09-05)

Logged to ~/.claude/team/gate-log.csv as decision=hold (approved-with-conditions). None of these block further engineering — they block Task 11 (first real tenant scan):

• Google OAuth restricted-scope verification + CASA Tier 2 security assessment — admin.reports.audit.readonly is a Google Restricted Scope; using it against any tenant beyond an internal dev/test account requires this. Weeks-long, real cost. This is the longest-lead item and the most likely to affect launch timing — start it independent of any code work.
• Microsoft Publisher Verification — recommended before selling the M365 tier (not yet built into the flow anyway).
• Pre-consent clickwrap on the connect flow (Morgan drafted starter language; not yet built as a UI/flow).
• "Limited Use" clause in a public Grantwatch privacy policy (doesn't exist yet).
• Retention purge jobs implemented in code — 90-day rolling window on raw audit events, 15-day purge for the free one-time audit, 30-day post-cancellation purge for the app list. Turing-reviewed, not just documented policy.
• Signed DPA with the first paying customer (lightweight template OK for MVP; real counsel required once any tenant has EU/UK employees or at Growth/MSP tier).
• PII handling controls in the connector layer — actor_email encrypted at rest/in transit, excluded from logs/observability tools, excluded from any public "anonymized findings" marketing content.

Known gaps (honest, both capabilities)

• Capability 1 has no billing wired despite being live — see above.
• Grantwatch's Microsoft connector is fully built and tested but not reachable from any user-facing flow — deliberate v1 scoping, not an oversight.
• Neither capability has been used against a real, paying customer yet.