Skip to main content
Glama

Nidhipati

Proof of Spend for AI agents. A signed receipt that proves what an agent was authorized to pay, what it actually paid, what it used and what was refunded. Not a token, not custody, not another payment rail.

Rails move money. Nidhipati proves the movement was authorized and correct.

tests MCP Registry Glama license

Status: v0.6 — five CLIs, an MCP server, 94 tests, official MCP Registry and Glama listing.

Site: https://mrpkk.github.io/nidhipati/
Free browser audit (no signup): https://mrpkk.github.io/nidhipati/free-spend-audit.html
BusinessMCP directory: https://businessmcp.com/mcp-servers/nidhipati
Private scan request: https://github.com/mrpkk/nidhipati/issues/new?template=free-spend-audit.yml

Free browser audit

Reserve and NAV report

For tokenised assets: the issuer's own numbers turned into a NAV with explicit formulas and an evidence hash per line. The verdict is backed, underbacked, or incomplete — and the ratio is refused when any line has no price, because a number computed over half a reserve is not a number.

nidhipati-reserve report examples/reserve.example.json --key keys/private.pem --markdown report.md
NAV = Σ quantity × price × (1 − haircut) − liabilities
ratio = NAV / supply

The statement hash is compared with the file if you provide it. The disclaimer travels inside the signed document. Details and the partner/legal checklist: docs/RESERVE-REPORT.md.

Related MCP server: mesa-mcp

Resolution evidence

When a market resolves and someone disagrees, the question is whether the resolver's sources say what the resolver claims and whether they agree with each other. The report answers with four verdicts — supported, disputed, single_source, insufficient — and never picks a winner.

nidhipati-resolve report examples/resolve.example.json --key keys/private.pem --markdown report.md

Details: docs/RESOLUTION-EVIDENCE.md.

Reconciliation

Invoices on one side, transfers on the other. The report names what is closed, what nobody paid, and what arrived without an invoice — a transfer that duplicates a payment is counted once, never twice.

nidhipati-reconcile run examples/invoices.example.csv examples/transactions.example.csv --csv matches.csv

Details: docs/RECONCILIATION.md.

MCP server (for agents, not shells)

The same five checks over the Model Context Protocol: verify_receipt, audit_spend, reserve_report, resolve_report, reconcile_books. Input is data, never a file path and never a network call; the answers are the same reports the CLIs produce, including the refusal to print a backing ratio when a line has no price.

{"jsonrpc":"2.0","id":1,"method":"tools/call",
 "params":{"name":"reserve_report","arguments":{"reserve":{...}}}}
python3 -m nidhipati_proof.mcp_stdio      # stdio transport
docker build -t nidhipati-mcp . && docker run -i --rm nidhipati-mcp

Five tools, all read-only: no custody, no keys, no chain read.

Official MCP Registry: https://registry.modelcontextprotocol.io/v0/servers?search=nidhipati (io.github.mrpkk/nidhipati, OCI ghcr.io/mrpkk/nidhipati:0.6.0).
Glama listing: https://glama.ai/mcp/servers/mrpkk/nidhipati.

Free scan, and what it costs after

Send records of what your agents spent and get the audit back — no card. The browser audit needs no account; a human review can go by email or Telegram, no GitHub needed: email maxim.pkk@gmail.com or Telegram with the downloaded report (not raw rows). GitHub is optional: open a private scan request; the issue is public, so ask the question only and never paste records or keys. Paid: first 3 audits $1,250; then $2,500 fixed, $1,500/mo retainer, or 20% of verified savings. $5,000 finding guarantee (identified overcharges, not recovery). Full terms, including what is not included: docs/OFFER.md.

In CI, on every run:

- uses: mrpkk/nidhipati@v0.2.0
  with:
    records: billing/agent-spend.csv
    policy: billing/policy.json

Quick start

python3 -m pip install -e .[dev]
python3 -m pytest -q
python3 -m nidhipati_proof.cli verify examples/proof-of-spend.example.json --pubkey <base64url>

What it checks

  • schema and canonical JSON;

  • Ed25519 signature;

  • mandate expiry vs settlement time;

  • amount, asset, network, payee;

  • usage.quantity × usage.unit_price vs payment;

  • refund ≤ payment;

  • verdict allow for a settled payment;

  • receipt ID/replay (v0.2 store).

Agent spend audit

A signed receipt proves one charge. A bill proves a month. The audit reads the records you already have (CSV or JSON) and names the rows where money left without a reason:

Finding

What it means

duplicate_charge

the same receipt twice, or an equal charge within 120s with no receipt at all

price_escalation

settled above the authorised quote by more than 1%

failed_but_billed

status failed/error and still charged

missing_refund

authorised 10, used 4, nothing returned

runaway_loop

more than 30 calls a minute from one agent

model_overpay

far above this agent's own median for the same tool and model (an estimate)

unknown_asset / unknown_network / missing_payee

the record does not say where the money went

budget_bypass / budget_exceeded

no policy file: the limit lives in a prompt; with a policy, the agent is over it

python3 -m pip install -e .
nidhipati-spend audit examples/spend-sample.csv --policy examples/spend-policy.example.json
nidhipati-spend audit records.csv --json > report.json

Exit code 1 when there is an error — a pipeline can fail on it. The report keeps three amounts apart on purpose: spent without a reason (duplicates, escalation, failed calls, refunds not returned), above the usual price (an estimate, not proof), and over the limit (the money may have been spent on real work).

The sample is synthetic and labelled: it contains every finding once, so you can see what a report looks like before trusting it with real invoices.

Honest limits

  • v0.1 does not verify the on-chain transaction; onchain_verified=false is explicit.

  • It is not a statutory audit, legal, tax, or investment advice.

  • It does not guarantee the service was good; it proves the payment was within mandate.

  • No custody, no money transmission, no token.

Docs

  • SPEC.md — product, architecture, modules, SEO, monetization, 30/60/90.

  • PROGRESS.md — slices, acceptance, metrics.

  • docs/PROMPT-AND-IDEAS.md — prompt and decisions for RAG.

  • docs/SEO-MONETIZATION.md — keywords, pages, funnel, pricing.

  • docs/LAUNCH-KIT.md — Show HN, Reddit, Product Hunt, X/LinkedIn copy.

  • docs/DEMO.md — real commands and sample output.

  • docs/AGENT-SPEND-AUDIT.md, docs/RESERVE-REPORT.md, docs/RESOLUTION-EVIDENCE.md, docs/RECONCILIATION.md — module rules.

  • schemas/proof-of-spend.schema.json — v0.1 schema.

  • examples/proof-of-spend.example.json — example.

License

Apache-2.0.

Available Tools

5 tools
audit_spendAudit an agent's spending recordsA
Read-only
Inspect

Find duplicates, price escalation, failed-but-billed calls, runaway loops, missing refunds, model overpay, unknown asset/network and budget breaches in a list of settled agent calls. Returns three separate amounts (money without a basis, estimate above the agent's own median, budget overrun) instead of one sum, because adding them together would overstate what can be recovered. Do NOT use as a statement of money actually returned.

Inputs: records (required), policy.

reconcile_booksReconcile invoices against transfersA
Read-only
Inspect

Match invoices to stablecoin transfers by memo first, then exact amount and asset inside the invoice window. Names what is left over in both directions: invoices nobody paid, money nobody invoiced, invoices paid twice. A duplicate is counted once, never twice. Do NOT use as proof of who the payer was.

Inputs: invoices (required), transactions (required).

reserve_reportReserve and NAV report for a tokenised assetA
Read-only
Inspect

Turn an issuer's reserve lines into a NAV with explicit formulas and a sha256 evidence hash per line. Verdict is backed, underbacked, or incomplete - and the backing ratio is refused (null) when any line has no price, because a ratio over half a reserve is not a number. Do NOT treat the result as a statutory audit.

Inputs: reserve (required).

resolve_reportResolution evidence for a prediction marketA
Read-only
Inspect

Weigh the sources a resolver says it read against the declared outcome. Verdicts: supported, disputed, single_source, insufficient. A conflict is reported as a conflict, never averaged. Do NOT use to trade or to place a position.

Inputs: market (required).

verify_receiptVerify an agent payment receiptA
Read-only
Inspect

Check a signed proof-of-spend receipt offline: schema, Ed25519 signature, mandate expiry, positive amount, quantity*unit_price == amount, refund not above payment. Use when an agent or provider returns a receipt and you need to know whether it actually proves the charge was allowed. Do NOT use to move funds or to confirm a transaction on-chain - nothing here reads a chain.

Inputs: receipt (required), public_key (required).

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    A4.1/5.0

    Scored across 5 tools

    Disambiguation4/5

    Most tools target clearly distinct financial verification tasks: reserve NAV, resolver-source validation, receipt checking, invoice reconciliation, and spend auditing. The main possible confusion is between reserve_report and resolve_report because both share the _report suffix and sound like generic reporting tools, though their descriptions clarify the domains.

    Naming Consistency4/5

    The set mostly follows a snake_case verb_noun or action_object pattern: resolve_report, verify_receipt, reconcile_books, audit_spend. reserve_report is slightly less action-oriented, but the overall convention remains readable and predictable.

    Tool Count5/5

    Five tools is well-scoped for a focused financial verification and audit server. Each tool covers a distinct check rather than padding the surface with redundant operations.

    Completeness4/5

    The surface covers reserve backing, source resolution, receipt proof, invoice reconciliation, and spend auditing, forming a coherent verification lifecycle. Minor gaps may exist around ancillary lookup or evidence-retrieval operations, but the core domain is well covered.

    Maintenance

    ActivityMaintained
    ResponsivenessNo recent community issues

    Related MCP Connectors

    Related MCP Servers

    • A
      license
      Not graded
      quality
      D
      maintenance
      Enables MCP hosts to verify agent spending mandates and receipts, providing stateless tools for authorization, chain verification, credential verification, and DID resolution.
      Apache 2.0
    • A
      license
      A
      quality
      B
      maintenance
      Enables agents to query a read-only ledger of machine payments, exposing tools for spending totals, purchases with event chains, verdicts, payer passports, and fiscal reporting data.
      7
      MIT
    • A
      license
      A
      quality
      B
      maintenance
      Policy-gated agent spend with signed receipts and rail-extract audit: a fail-closed gate issues a COSE receipt for every allowed payment, and the audit reconciles those receipts against a rail extract so a settlement with no receipt is named rather than assumed. It settles on a mock rail, holding no wallet and signing no transaction.
      5
      1
      Apache 2.0
    • A
      license
      Not graded
      quality
      C
      maintenance
      Enables AI agents to inspect, check, and audit signed offline spending authorizations, and to issue hash-chained receipts for each action taken against them. Enforces per-transaction, total, expiry, merchant, and human-approval constraints, returning allow, needs_human, or deny with the specific failing constraint.
      Apache 2.0