Optional fiscal-safety metadata for paid MCP servers

[egoriklok]

MCP server discovery is moving toward an app-store-like registry. As paid MCP servers and agent-accessible commercial tools appear, clients may need a small non-secret fiscal-safety layer before an agent is allowed to call a paid tool.

Possible optional metadata/checklist fields:

1. paid_action_surface — what action can create cost or settlement?
2. approval_source — human approval, policy engine, allowance, budget rule, or none.
3. spend_cap — per-call, per-session, daily, or monthly cap.
4. charge_evidence — what non-secret receipt/event proves a charge happened?
5. audit_trail — where a client/operator can verify calls and charges.
6. revocation_path — how access is disabled or reduced.
7. next_safe_threshold — what evidence would justify raising the cap.

The goal is not to collect secrets or payment credentials in the registry. It is to help agent clients distinguish a free/tooling MCP server from one that can trigger bounded paid actions, and to make revocation/audit expectations explicit.

Question for maintainers/builders: would this fit better as optional registry metadata, a convention in server docs, or a separate checklist linked from paid-server entries?

[YE-YI7]

This fiscal-safety proposal matches a producer-side experiment we have been running in ASM. Two boundaries from that work may help here:

1. Discovery should not freeze a single scalar price. Static metadata can carry coarse access/approval/spend-cap signals and provenance, while caller-specific or mutable terms live behind a resolver/source URL.
2. Discovery evidence and runtime settlement receipts are different layers. A manifest can say which receipt mechanism is supported, but the concrete amount and proof still belong to the invocation/payment flow.

Rather than asking the Registry to standardize these fields immediately, would a smaller producer-coverage experiment be useful: willing producers publish an optional namespaced ASM block under existing publisher-provided _meta, and a downstream consumer verifies that it can preserve and read the fields? The experiment would use the existing _meta extension surface rather than require a core Registry schema change. I can provide two candidate fixtures and validation commands if that is a useful next step.

[holistis]

Thanks for actually verifying it instead of just saying nice work, that is worth more to me than any star count. Agreed on keeping this as post-call attestation, separate from pre-call discovery, that is the right line to draw. I am in for the narrow fixture PR, I can prep a couple of real capacity-attest claims on my end if you want to sketch the ASM _meta linkage. Want to take the actual work to email so we are not designing a spec in a comment thread, or keep it here?

[EmbryoSpace]

Agreed: two rails hitting the same wall is the strongest signal the gap is real rather than rail-specific.

On the EVM caveat, it's smaller than it looks. BSV and Ethereum are both secp256k1 ECDSA, so the primitive is identical: EIP-191's recoverable personal_sign has a direct analog in Bitcoin Signed Message / BRC-77 (a recoverable ECDSA signature over a prefixed message). The chain-agnostic core, a content-addressed claim plus a signature that recovers to the payer, doesn't need new cryptography to cover BSV; what differs is an envelope adapter (the message prefix, and recovering to a base58 P2PKH address instead of a 20-byte hex one). And it binds the same way: in an x402 flow the buyer pays from their own key, so that key can sign the claim and recover to the BSV address that appears as the payer in the settlement tx, the same three checks @YE-YI7 ran on Base (recover to buyer, recompute the claimId, confirm the on-chain transfer).

Worth flagging for the spec's sake: if the attestation layer ends up EVM-only in practice, BSV-settled servers get locked out of the reputation half of this even when their payments are perfectly verifiable, so a non-EVM recovery path seems worth keeping in scope from the start. On our end it isn't hypothetical: we have a real mainnet x402 settlement (a $0.001 pay-per-call) that a BSV verifier would check exactly as above, and we're happy to point at it as a concrete reference if it's useful for scoping.

Glad to compare notes on where the claim format is genuinely shared vs rail-specific. The layer boundary @YE-YI7 drew, pre-call discovery vs post-call attestation, holds regardless of rail, so this is about keeping a second rail inside the same line, not forking it.

[holistis]

I built something for exactly this question, a small MCP server called capacity-attest. It doesn't answer where this belongs (registry metadata vs doc convention), but it does give a concrete shape for what the evidence itself could look like: after a paid call settles, the paying agent signs a small record (delivered: yes/no/partial, what was promised, evidence hash, the settlement reference) and it goes into a public append-only history keyed by the seller. Anyone can verify the signature offline, no registry involvement needed.

Whether that belongs inline in registry metadata or as a separate, queryable thing (which is what I went with) is a real open question, I don't have a strong opinion on which is better for the registry itself. But if a concrete worked example helps: I ran this against a real live paid endpoint today, a real $0.001 USDC payment on Base, real signed claim recorded and read back. Happy to share the actual transaction and claim if useful.

https://www.npmjs.com/package/capacity-attest

[YE-YI7]

Thanks — I found the public claim fixture in the repository and independently checked the parts that can be verified without trusting the author:

• the Base receipt succeeded and the USDC contract emitted a transfer of 1,000 base units (0.001 USDC) from the claim's buyer to its seller;
• recomputing the canonical claim content reproduces claimId 0xc008b7b38e8a80061d525ac1cfe08c4f48244612dcf7f2a1b61b82c16fccac29;
• the EIP-191 signature recovers to the stated buyer address.

That verifies payment and claim authorship. It does not independently prove delivered=yes or reveal the evidenceHash preimage, so I would keep this as raw post-call payer attestation rather than turn it into a trust score.

This fits the layer boundary I was describing: discovery selects under pre-call constraints; capacity-attest can remain the source and verifier for post-call evidence. Would you be open to reviewing one narrow fixture PR that adds an ASM Selection Receipt pointing to this existing capacity-attest claim URI/claimId, plus one test that follows the link, recomputes the claimId, and verifies EIP-191 recovery? The raw claim would remain with capacity-attest; nothing would be copied into registry metadata, and neither protocol would change.

[EmbryoSpace]

This is exactly the gap we hit shipping a paid MCP server, so a concrete data point in case it's useful.

We built @bsvkey/inference-mcp, which sells pay-per-token Claude/Grok inference. It has an x402_infer tool that charges per call via x402 (the HTTP-402 standard), settled in BSV micropayments, the agent signs locally with its own key, no account or prepaid channel, and gets an on-chain settlement txid back. Working end-to-end, proven with a real mainnet tx.

Two places payment info lives today, which is relevant to the metadata question here:

1. Runtime (per request): an unpaid call returns a standard x402 402 whose accepts[] carries the exact terms, scheme, network, asset, maxAmountRequired, payTo, maxTimeoutSeconds. Plus a /.well-known/x402 discovery manifest.
2. Static (server.json): right now the only signal is env-var descriptions (e.g. a funding key). There's no structured way to say "this server is paid, here's the pricing model / asset / whether it's pay-per-call vs prepaid."

That #2 is the gap this proposal would fill. What we'd have loved as a server author: an optional pricing/payment block in server.json, something like { model: "per-call" | "prepaid" | "subscription", asset, scheme, priceHint, facilitator, discovery }, so a host or agent can know a server costs money, and how, before invoking it and eating a 402. That maps cleanly onto both x402 (agents) and traditional billing.

Happy to share how the x402 side works if it helps ground the schema, refs: @bsvkey/inference-mcp, gateway/discovery at inference.bsvkey.com, and a drop-in paywall (@bsvkey/x402-paywall) for the non-MCP case.

[holistis]

We are solving the same problem from two different payment rails, which is a good sign the gap is real. One honest caveat: capacity-attest'''s proof model today is EVM-specific, EIP-191 signatures recovered to an address, so it does not verify BSV settlement out of the box. The underlying idea (content-addressed claim plus a verifiable signature) is not tied to one chain in principle, but making it actually work for BSV would need real work on the signature side, not just a config flag. Curious if that is worth comparing notes on regardless.

[holistis]

Coming back to this since it maps directly onto charge_evidence and audit_trail. I built capacity-attest for exactly that gap: after a paid MCP call settles, it produces a signed, content-addressed claim in a public append-only history that anyone can verify offline, no registry lookup needed. YE-YI7 independently verified one against a real Base USDC payment (see below in this thread). Happy to sketch how the claim format could map onto your proposed fields, or contribute a small worked example if that is useful for the spec.

[YE-YI7]

Thanks — let’s keep the design here so the boundary stays public and reviewable. I’m in for one narrow fixture.

One correction to my earlier sketch: because the capacity claim exists only after execution, it should not be referenced directly by the pre-call DecisionReceipt. The chain should be:

DecisionReceipt -> OutcomeReceipt -> external attestation reference

For the fixture, ASM would retain only the stable claim URI, claimId, verifier profile/version, settlement reference, and verification result. The raw claim remains with capacity-attest. The test should establish content addressing, payer-signature recovery, and settlement linkage; it must not treat delivered=yes or the unrevealed evidenceHash preimage as independently proven.

Could you provide one stable raw-claim URL plus the exact capacity-attest package/version or command that should verify it? Once that is available, I’ll draft the linkage fixture and tests without changing either protocol core.

[holistis]

Here is everything for the fixture.

Stable raw-claim URL, pinned to the commit that recorded it (the only commit that has ever touched this file), so the bytes cannot change:

https://raw.githubusercontent.com/holistis/tokenizen/85c8fc1feef099c17bf178b75f4a476e5b867976/packages/capacity-attest/data-selftest/claims.jsonl

It contains exactly one JSONL line, the claim you already checked.

claimId: 0xc008b7b38e8a80061d525ac1cfe08c4f48244612dcf7f2a1b61b82c16fccac29
settlementRef: 0xc00a638491986962ca125c01da4e3df8a07d715216694bb0a59ff257c88e6880 (the Base USDC transfer you verified on-chain)
expected signer (buyerAddress): 0xf11ce7141daecec9624ec3ccf49b437d40a0ad20

Verifier: capacity-attest@0.2.0 from npm, function verifyClaim. Full reproduction from an empty directory:

npm install capacity-attest@0.2.0

// verify.mjs (run as an ES module, for the top-level await)
import { verifyClaim } from "capacity-attest/dist/signing.js";

const url = "https://raw.githubusercontent.com/holistis/tokenizen/85c8fc1feef099c17bf178b75f4a476e5b867976/packages/capacity-attest/data-selftest/claims.jsonl";
const claim = JSON.parse((await (await fetch(url)).text()).trim());
console.log(verifyClaim(claim));
// { ok: true }

One note that saves a debugging round: import the signing module directly, as above. The package main starts the MCP stdio server at import time.

verifyClaim covers the first two of your three checks: it recomputes the content-addressed claimId from the claim's content fields, and it recovers the EIP-191 signature, which must equal buyerAddress. The third, settlement linkage, stays with the Base tx above. Agreed on the boundary: delivered=yes and the evidenceHash preimage are the buyer's attestation, not independently proven, and the fixture should say so.

Two things worth capturing in the fixture. First, this claim was recorded under 0.1.x and still verifies unchanged on the published 0.2.0 (it has no measured block; the 0.2.0 additions do not touch claims without one). Second, the negative path: I mutated delivered to no, and buyerAddress to the seller address, and both came back {ok:false, reason:"claimId_mismatch"}. Since claimId is the sha256 of the content fields, editing any of them breaks the match, so the integrity check cannot silently pass on a tampered claim.

One thing in return: when the fixture lands, please name capacity-attest and link https://github.com/holistis/tokenizen in its docs rather than a generic reference. I will credit ASM the same way on our side.

@EmbryoSpace once a non-EVM recovery path exists along the lines of your envelope-adapter sketch, your mainnet x402 settlement would make a natural second fixture, exactly the shared-core versus rail-specific test you described.

Happy to review the fixture PR when it is up.

[holistis]

Reviewed the PR, left comments there: YE-YI7/asm-spec#18 (comment)

Cloned your branch and ran the test suite myself rather than just reading it, all three pass. Field mapping and the verifier invocation both check out against the actual capacity-attest source. Good to merge from my side.

[EmbryoSpace]

Happy to take the BSV side of this. To @holistis's point that it needs real work on the signature side, not a config flag: agreed, and it's worth being precise about where that work actually is.

The content layer is already shared. claimId is sha256 over the canonical content fields, so a BSV claim is content-addressed and tamper-evident exactly as the Base one is, with no change. What needs a rail adapter is only the recovery step: capacity-attest today recovers an EIP-191 signature to a 20-byte hex address, and BSV needs a recoverable ECDSA signature over a prefixed message (Bitcoin Signed Message / BRC-77) recovered to a base58 P2PKH address. Same secp256k1 primitive, different envelope and address encoding.

The settlement-linkage check maps cleanly too. In an x402 flow the buyer pays from their own key, so that key signs the claim and recovers to the same address that appears as payer in the settlement tx. The three checks @YE-YI7 ran on Base (recover to buyer, recompute claimId, confirm the on-chain transfer) hold on BSV, with the transfer check reading a P2PKH output paying payTo instead of a USDC Transfer log.

On our end this isn't hypothetical: we have a real mainnet x402 settlement, a BSV pay-per-call landing at the seller's own address, that a verifier would check exactly this way. Glad to produce a second fixture in the same shape as #18: a raw claim pinned by commit, a claimId recompute, a BSV signature recovery, and the settlement-tx linkage, with delivered and the evidenceHash preimage explicitly left as buyer attestation, not independently proven. If a small BSV envelope adapter for verifyClaim is the cleanest home for the recovery step, we're glad to draft it against the existing content-addressing so nothing in the claim format forks.

The layer boundary holds regardless of rail: this stays post-call attestation, and the pre-call DecisionReceipt continues to reference only the OutcomeReceipt and then the external claim, per @YE-YI7's chain.

[holistis]

This is exactly right, and more precise than my own sketch. The content layer not needing to change and the recovery step being the only rail-specific piece is the correct split, and I like keeping it as an adapter rather than forking the claim format.

Go ahead and draft it. A second fixture in the same shape as #18, plus a small BSV envelope adapter for verifyClaim that plugs into the existing content-addressing, sounds like the right shape. Happy to review both when you have something, same way I went through #18: I'll clone it and run it myself before saying anything.

Genuinely glad this is coming from a real live case on your end rather than a hypothetical. Let me know when there's something to look at.

[YE-YI7]

Thanks, this was enough to make the fixture concrete. I opened YE-YI7/asm-spec#18.

It names and links capacity-attest, keeps the raw claim in tokenizen, pins verifyClaim to 0.2.0, and checks the Base USDC Transfer log. I also kept historical_asm_use=false: this demonstrates the downstream linkage shape, not that ASM was used for the original call.

The fixture explicitly leaves delivered=yes, the evidenceHash preimage, and task correctness unproven. I would especially value your review of the field mapping and verifier invocation.

[holistis]

Reviewed the PR, left comments there: YE-YI7/asm-spec#18 (comment)

Cloned your branch and ran the test suite myself rather than just reading it, all three pass. Field mapping and the verifier invocation both check out against the actual capacity-attest source. Good to merge from my side.

[YE-YI7]

Merged #18: YE-YI7/asm-spec#18

@holistis, thank you for cloning and running it independently — that is much stronger evidence than a self-authored fixture alone.

@EmbryoSpace, a separate BSV fixture/adapter PR against main is welcome. The boundary you described is the one to preserve: reuse the content-addressed claim shape, isolate BSV-specific signature recovery/address encoding behind the rail adapter, link to a pinned real settlement, and keep delivery, the evidenceHash preimage, task correctness, and historical ASM use as explicit non-claims unless independently proven.

The Base fixture remains live by design for now; if endpoint reliability becomes a CI problem, we can add an RPC override without replacing the live-verification path.

[EmbryoSpace]

Opened per the invitation above, this is the BSV-settled sibling of #18, same shape. The raw claim is pinned by commit in EmbryoSpace/bsv-capacity-attest, and the test reproduces three things: content addressing, BSM payer-signature recovery (signature to pubkey to base58 buyerAddress), and the on-chain settlement (a confirmed BSV tx with a P2PKH output to the payee and an input spent by the payer, the BSV analog of the USDC Transfer log).

This follows the boundary you laid out point for point: reused content-addressed claim shape, BSV signature recovery and base58 encoding isolated in the rail adapter (nothing in the claim format forks), a real mainnet settlement pinned by commit, and delivery, the evidenceHash preimage, task correctness, and historical ASM use all kept as explicit non-claims. capacity-attest is named and linked.

On the reliability note: the settlement check is a live WhatsOnChain read by default, but FIXTURE_OFFLINE=1 (skip the network read) and CLAIM_FILE= (check the pinned bytes offline) are already there as overrides.

Repro: npm ci && npm test. Happy to adjust the field mapping or verifier profile to whatever you prefer.

[holistis]

Reviewed this the same way as #18: cloned the repo and ran the test suite myself rather than reading it.

18/20 pass offline (FIXTURE_OFFLINE=1). The 2 remaining are the live WhatsOnChain settlement checks, which hit a 429 rate limit in my run, not a real failure. I queried the tx directly to confirm: 07d0114a4d142942bc2f7ac85d35ae95e2dd71f130c71b5b2f89a2d508942938, 78 confirmations, block 965541, with an output paying 19Kjq5uDoNGzKo84Ui6R4qtH2WVJeu7Dyi (the claim's sellerAddress) and the remainder back to the buyer, exactly the P2PKH shape the test asserts.

Checked the adapter against capacity-attest's actual source, not just the README's claim: canonicalize()/sortKeysDeep() in bsv-claim.mjs is byte-for-byte the same route (sorted keys, JSON.stringify, sha256), and the strict-shape rejection of unsigned fields matches the same posture. The only rail-specific part, exactly as scoped, is the BSM signature recovery to a base58 P2PKH address in place of EIP-191 to a 0x address. Good boundary: content layer untouched, signature envelope isolated in the adapter.

Good to merge from my side.

[EmbryoSpace]

@holistis Thanks for cloning and running it rather than reading it. That independent run is the signal that matters, and it's the same bar @YE-YI7 valued on #18.

Confirming your read: the 2 non-passes are the live WhatsOnChain settlement checks hitting a 429 rate limit, not a logic failure. Your direct query lines up with what the test asserts: tx 07d0114a4d142942bc2f7ac85d35ae95e2dd71f130c71b5b2f89a2d508942938, confirmed, with a P2PKH output to the claim's sellerAddress 19Kjq5uDoNGzKo84Ui6R4qtH2WVJeu7Dyi and change back to the buyer, the BSV analog of the USDC Transfer log.

On reliability: the live read is best-effort by design and does not need to gate CI. FIXTURE_OFFLINE=1 skips the network read, and CLAIM_FILE= verifies the pinned claim bytes offline, so the 18 deterministic checks (content addressing and BSM recovery) run with no endpoint dependency. If you'd prefer, I can point the settlement read at a configurable WhatsOnChain base/API key the same way #18 left room for an RPC override, without touching the live-verification path.

Appreciate the source-level check too: confirming canonicalize()/sortKeysDeep() is byte-for-byte the same route and that BSM recovery is the only rail-specific piece is exactly the boundary we wanted to hold. Delivery, the evidenceHash preimage, task correctness, and historical ASM use stay explicit non-claims. Glad to adjust field mapping or the verifier profile to whatever reads cleanest for merge.