claude mcp add stillos-notary-mcp -- npx -y stillos-notary-mcp
A pasteable skeleton generated from the repository name. Check the project README for the exact package and arguments.
Star count
1 ★ · stillmarcus24/stillos-notary-mcp · read from the GitHub search API · (checked 2026-10-16 20:00:20)
Source
collected from the punkpeye/awesome-mcp-servers list · type: MCP server
Harvest history
first seen 2026-10-09 · last seen 2026-10-16 · seen 32× · listed by 7 sources
Score
score 703 · 1 ★ · 7 sources · mcp
FAQ (answers come from our records)
How do I install it?
We did not find an install command for this repository (our install coverage is only about 4%). Check its README or releases page.
Who is it for?
We filed it under these tags: MCP 服务. The tags come from the entry itself, not a taxonomy we imposed.
Who maintains it?
repository stillmarcus24/stillos-notary-mcp;first catalogued 2026-10-09;last seen 2026-10-16。There is no official certification or quality rating here — we record sources and dates only.
Verification infrastructure for the agentic economy. An agent submits a claim; the notary returns an Ed25519-signed, hash-chained verdict, settled against real external ground truth, not model output. Free tier, no account, no card. Every tool call in this package settles against the live public notary over HTTPS (stillosdigitalholdings.com/notary). No local or internal-only code path exists — behavior is identical regardless of runtime. Install Or add to an MCP client config: Tools claim_verdict Submits a claim and a resolver specification. Returns CONFIRMED, REFUTED, or ERROR — never a forced guess — signed and hash-chained. Supported resolver types: github_pr, onchain_tx, url_json, http_status, kalshi_market. verify_receipt Independently verifies any receipt by hash: confirms the hash chain is intact and the signature is valid. file_dispute Files a bonded dispute against a verdict receipt. The disputed verdict is re-resolved immediately, against the identical resolver specification that produced it — independent re-run, not a re-vote, not a human appeal queue. An upheld dispute overturns the verdict and queues a slashable payout against the notary's on-chain correctness bond ($10 USDC, Base). Dispute window: 48 hours from the original receipt's timestamp. Paying for a paid tool (1.3.0) Through 1.2.2 this package could only *report* the paywall: every paid tool returned { payment_required: true } and the call ended there. There was no way, anywhere in the package, to attach a payment and retry — the CLI told you to "attach payment and retry" using a mechanism that did not exist. 1.3.0 implements it. Supply a credential and the 402 is crossed automatically — one 402, one payment, one retry, then the paid result: With no credential you get an actionable requirement rather than a dead end: **What it refuses to pay.** A 402 is untrusted input. The client will not sign for a network or scheme it does not expect (base / exact only), will not pay a malformed requirement missing payTo or an amount, and will not exceed a per-call ceiling ($1.50 default, STILLOS_NOTARY_MAX_USD or opts.maxUsd to change). It never retries more than once — a second 402 is a hard stop, not a backoff loop, so a rejected payment can never be re-signed into a double spend. Supplying no credential never spends anything. No key is received, logged, persisted, or placed in an error message. Covered by test/payment-continuation.test.cjs (17 cases, local mocks, no real settlement). **Paid: $1.00 USDC (Base) via x402 — no free tier.** A call without an attached x402 payment returns the payment requirement (price, payTo, asset), not a verdict. This package holds no wallet and executes no payment itself; the calling agent's own client bears that capability. screen_entity OFAC SDN sanctions name screen, with a source_as_of freshness timestamp,