Skip to main content
Glama
Mohith535

NitroWatch Billing Demo

by Mohith535
README.md
# NitroWatch Billing Demo

> An intentionally **ungoverned** MCP server. This is the thing that needs governing.

This is the companion demo target for **[NitroWatch](https://github.com/Mohith535/nitrowatch)** — a governance layer for MCP.

**This server has no safety of its own.** Every tool below does exactly what it is told, immediately, for anyone who asks. `delete_account` will permanently destroy an account and all of its invoices without a single confirmation.

That is the point. It is indistinguishable from thousands of real MCP servers — and that is exactly why NitroWatch exists.

---

## The tools

Five tools, chosen so one lands on each of NitroWatch's risk tiers:

| Tool | Effect | NitroWatch classifies it as |
| --- | --- | --- |
| `get_invoice` | Fetch one invoice | `read` — runs freely |
| `list_invoices` | List invoices, optionally by account | `read` — runs freely |
| `send_invoice` | Emails an invoice, marks it sent | `reversible` — gated, **can earn autonomy** |
| `archive_customer` | Archives an account | *unmatched* → defaults to `reversible` |
| `delete_account` | **Permanently** deletes an account and purges its invoices | `irreversible` — gated **forever** |

### Why `archive_customer` is the interesting one

Nothing in its name or description reveals that archived accounts here are **purged after 30 days and cannot be restored.** It reads as recoverable. No classifier — heuristic or LLM — could know otherwise.

That is precisely the case NitroWatch's `set_tier` exists for: a human who knows the domain corrects the classification, and the override is recorded in the audit trail.

---

## Running it

```bash
npm install
npm run build
npx nitrostack-cli start --port 3100
```

> ⚠️ **Use the `--port` flag.** The `PORT` environment variable is silently ignored — the server binds 3000 regardless, which collides with NitroWatch. This is tested behaviour, not a guess.

When it's up you'll see:

```
Legacy SDK SSE   http://localhost:3100/sse
Streamable HTTP  http://localhost:3100/mcp
```

## Putting it under governance

From NitroWatch:

```js
register_server({ name: "Billing API", endpoint: "http://localhost:3100/sse" })
discover_capabilities({ serverId: "billing-api" })
classify_tools({ serverId: "billing-api" })
```

Then try to delete something, and watch it get stopped:

```js
request_action({
  serverId: "billing-api",
  toolName: "delete_account",
  args: { accountId: "acc_991", purgeInvoices: true }
})
// → { decision: "blocked", tier: "irreversible", ... }
```

> **Note on deployment:** if you run NitroWatch from NitroCloud rather than locally, it cannot reach `localhost` on your machine — the cloud instance resolves its own localhost. Either run both locally, or deploy this server too and register its public URL.

## Seed data

Two accounts and three invoices, held in memory. A restart resets everything — convenient when you have just deleted an account to prove a point.

| Account | Invoices |
| --- | --- |
| `acc_991` Acme Manufacturing | `inv_2214` ₹48,200 draft · `inv_2215` ₹12,750 draft |
| `acc_882` Vertex Logistics | `inv_2216` ₹96,000 paid |

## Built with

[NitroStack](https://nitrostack.ai) TypeScript SDK — NitroStack × SRM Hackathon 2026.

TDQS

A4/5.0

Scored across 5 tools

Disambiguation5/5

Each tool targets a distinct resource and action: get_invoice retrieves a single invoice, list_invoices retrieves multiple, send_invoice emails an invoice, and archive_customer vs delete_account clearly separate soft from permanent customer removal. No two tools overlap in purpose.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (get/list/send/archive/delete + resource). The use of 'get' for singular and 'list' for plural is conventional, and there is no mixing of styles.

Tool Count5/5

With 5 tools, the server is well-scoped for a billing demo. It covers the essential operations without unnecessary bloat, and the count feels appropriate for its purpose.

Completeness4/5

The set covers invoice retrieval, emailing, and customer lifecycle (archive/delete), but lacks invoice creation, updating, or voiding. This is a minor gap for a billing system, but core workflows are still represented.

Maintenance

ActivitySlowing
ResponsivenessNo issues