Watchtower MCP

Cost tracking + deep security scanning for AI builders. An MCP server for Claude Code.

Watchtower runs alongside your AI coding agent and answers two questions: what am I spending? and is the app I just vibe-coded actually safe to ship? Unlike existence-only scanners, Watchtower proves its security findings — it runs a live cross-tenant probe against your database and verifies whether leaked keys actually work.

Everything runs locally. No data leaves your machine except (a) the optional, opt-in live-key check, which contacts only each key's own vendor, and (b) the database connection you point the RLS audit at.

Install

npm install -g watchtower-mcp

Add to your Claude Code MCP config (~/.claude/settings.json):

{
  "mcpServers": {
    "watchtower": {
      "command": "watchtower-mcp"
    }
  }
}

Restart Claude Code. You now have 9 tools available.

Tools

Cost Tracking

| Tool | What it does | |------|-------------| | watchtower_sync_usage | Import real token usage automatically from Claude Code's own session logs (~/.claude/projects). Accurate, no manual logging. Run it anytime — already-imported events are skipped. | | watchtower_spend | View spending (today / week / month, calendar-aligned) with per-model breakdown and how much is estimated | | watchtower_budget | Set daily/weekly/monthly budget alerts (warns at 80% and 100%) | | watchtower_log_usage | Manual fallback for non-Claude-Code clients. Prefer sync_usage. |

Security Scanning

| Tool | What it does | |------|-------------| | watchtower_scan_secrets | Scan source for hardcoded keys/tokens (pure-Node, no shell). Pass verify: true to confirm which keys are actually live via a read-only call to each vendor. | | watchtower_scan_supabase | Audit Postgres/Supabase RLS correctness — runs a live, read-only cross-tenant probe to prove whether a random user or the anonymous role can read other users' data. Not just "does RLS exist." | | watchtower_scan_headers | Scan a deployed URL for missing security headers (CSP, HSTS, X-Frame-Options, etc.) |

Dashboard

| Tool | What it does | |------|-------------| | watchtower_status | Quick overview of spending + recent security findings | | watchtower_scan_history | History of past security findings (de-duplicated) |

Usage

Once installed, just ask Claude:

"Sync my Claude Code usage and show this month's spend"
"Scan my project for hardcoded secrets and check if any are live"
"Audit my Supabase database — can other users read my data?"
"Check the security headers on https://myapp.vercel.app"
"Set a $5 daily budget alert"

How It Works

• Cost tracking — watchtower_sync_usage parses Claude Code's transcript logs (the actual billed token counts) and stores them in a local SQLite database at ~/.watchtower/watchtower.db. Costs are computed from a current pricing table; unknown models are clearly labelled estimated rather than silently mispriced. Spend windows are calendar-aligned (UTC) to reconcile with your Anthropic bill.
• Secret scanning — runs entirely in-process (no shell), with overlap de-duplication, placeholder/entropy filtering to cut false positives, and secret redaction in all output. With verify: true, each detected key gets a single read-only verification request to its own vendor (Anthropic/OpenAI/Stripe/GitHub) or a local JWT decode (Supabase) — so you learn which leaks are real.
• RLS correctness — connects with the pg driver (credential stays in-process), then inside read-only, rolled-back transactions it drops to the authenticated and anon roles and attempts to read each table. A row visible to a random non-owner or to the anon role is a proven cross-tenant leak — the CVE-2025-48757 class of breach. Findings backed by a live read are marked [PROVEN].

Security

Watchtower holds itself to the standard it scans for:

• No shell is invoked anywhere. The secret scanner reads files directly; the RLS audit uses the pg driver, never psql. Caller-supplied paths and connection strings cannot inject commands, and your database password is never placed on a command line.
• Detected secrets are redacted in all output and are never written to the database.
• Live-key verification is opt-in (verify: true) and contacts only each key's own vendor over read-only endpoints.

Supported Models

Claude Opus 4.6, Sonnet 4.6, Haiku 4.5, and Sonnet 3.5. Unknown models are priced as an explicit estimate (Sonnet rates) and flagged as such.

Requirements

• Node.js 18+
• Claude Code (or any MCP-compatible client)
• For the RLS audit: a Postgres/Supabase connection string with permission to read schema and (ideally) the authenticated/anon roles. No psql install required.

Development

npm install
npm run build
npm test

License

MIT