Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Runs on your computer
Capacity Attest
Overview
Description from the maker (original English)
Signed delivery claims for x402 capacity trades: GPU-hours, storage, API credits, bandwidth.
PopNx MCP’s three pillars
These three are never merged into one score: opinions, measurements and popularity are different things.
- User voiceiNo reviews yetReviews open together with accounts in a later step
- Our basic checksi1 of 1 passedChecked from public information; code not scanned yet
- UsageiEarly↓ 684/wk · ★ –
What you can do with it
We have not written a plain-language summary for this one yet. Below are the facts we read from the registry.
- Connection: Runs on your computer
- Transport: stdio
- Category: Other
Install
Pick the AI app you use, then copy the settings.
Before you install
- Basic checks: 1 of 1 passed
- Runs on your computer with your user’s permissions (files, network, apps).
- You fill in yourself:
CAPACITY_ATTEST_DATA_DIR
You need
- npmNode.js installed (for the npx command)
Which app do you use?
Pick your app above. We remember it, so next time the button says “Install in …”.
Open Claude Desktop → Settings → Developer → Edit Config, and paste this into claude_desktop_config.json
{
"mcpServers": {
"capacity-attest": {
"command": "npx",
"args": [
"-y",
"capacity-attest"
],
"env": {
"CAPACITY_ATTEST_DATA_DIR": "your-value"
}
}
}
}Run this in your terminal
claude mcp add capacity-attest --env CAPACITY_ATTEST_DATA_DIR=your-value -- npx -y capacity-attestFill in the empty values before running it.
Or copy the settings yourself
Paste into .cursor/mcp.json in your project, or ~/.cursor/mcp.json
{
"mcpServers": {
"capacity-attest": {
"command": "npx",
"args": [
"-y",
"capacity-attest"
],
"env": {
"CAPACITY_ATTEST_DATA_DIR": "your-value"
}
}
}
}Your browser asks to open the app, then the app shows the settings and asks you to confirm. Key values are left empty for you to fill in.
Or copy the settings yourself
Paste into .vscode/mcp.json in your project
{
"servers": {
"capacity-attest": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"capacity-attest"
],
"env": {
"CAPACITY_ATTEST_DATA_DIR": "your-value"
}
}
}
}Your browser asks to open the app, then the app shows the settings and asks you to confirm. Key values are left empty for you to fill in.
This one runs on your computer, and ChatGPT can only connect to servers on the internet. Pick another app.
Your choice stays on this device in a cookie; no account needed.
Values you fill in
CAPACITY_ATTEST_DATA_DIRenvDirectory the append-only claims ledger (claims.jsonl) is written to and read from. Defaults to ./data inside the package.
These settings are generated from the maker’s registry entry. If the README says otherwise, follow the README.
What it can do
Runs on your computer; the tool list appears in your AI app after you install it.
Basic checksi
We check information anyone can see; we have not read the code. Checks that do not apply are left out of the count. · Checked Nov 8, 2026
- ✓ Pass
Maker matches the repo
The registry name was verified with the GitHub account holistis, which owns the repo
- … Not checked yet
Still maintained
We have not read this repo from GitHub yet
- … Not checked yet
Has a licence
We have not read this repo from GitHub yet
- – Not applicable
Endpoint responds
This one runs on your computer; there is no internet endpoint
- – Not applicable
Sign-in with OAuth
Runs on your computer and uses local settings instead
- … Not checked yet
No hidden instructions in tool descriptions
Runs on your computer; we can only read tool lists from internet endpoints
Compared with others in Otheri
- More stars than 0% of the other 18438 servers in this category
- Published to the registry more recently than 54% of the other 18438 servers in this category
- Basic checks equal to or better than 100% of the other 18438 servers in this category
Compared with every active server in this category in the registry. Stars count only when the publisher owns the repo.
Common questions
Is Capacity Attest safe?
It passed 1 of 1 applicable basic checks. We have not read the code. Before adding a key or token, see what access the server asks for and use a key with only the permissions you need.
What keys or codes does it need?
The registry does not list a required key, though some servers ask you to sign in on first use.
Does it run on my computer or in the cloud?
It runs on your computer. Your AI app starts it when needed, and data does not pass through the maker’s servers (unless it calls an online service itself).
Is it still maintained?
The GitHub repo last changed –, and the latest version (0.7.0) reached the registry 40 days ago.
Which apps can use it?
Apps that support MCP, such as Claude Desktop, Claude Code, Cursor and VS Code. You also need Node.js on your computer.
What can I use instead?
In the same category: Spec Driven Development, Remote Desktop Commander, Tethered Trust
Alternatives
Servers in the same category from other makers, sorted by stars.
Reading a card:↓ Downloads per weeki★ GitHub starsiThree pillars: reviews · checks · usageiUpdated = latest version published to the registryi
Remote Desktop Commander
Remote Desktop Commander: use files, terminal and processes on your own computers from any AI app.
Runs in the cloud✓ desktopcommander.app
Tethered Trust
Fit, compatibility and recall checks for AI agents before they buy: verdicts, evidence, receipts.
Runs in the cloud✓ tetheredtrust.com
README from the maker
Open the README
Copied from the maker’s repo as written. PopNx MCP has not reviewed or endorsed it. HTML, images and scripts are removed. Links lead off this site.
capacity-attest
*Nederlandse versie / Dutch version: README.nl.md*
MCP server for delivery attestations in x402 capacity trading between AI agents.
Status: MVP, published on npm (
npm install capacity-attest) and in the official MCP registry (io.github.holistis/capacity-attest).
Independently checked, not just claimed
Every claim about this project below is clickable and independently verifiable, not something you have to take our word for.
| What | By whom | Status |
|---|---|---|
Uses capacity-attest@0.2.0 as a real dependency, verifies claim digest/claimId/signature through our own code | YE-YI7/asm-spec#18 | Merged |
| BSV rail adapter on the same content-addressed claim format | YE-YI7/asm-spec#19 (author EmbryoSpace) | Merged |
| Our boundary claims ("discoverability ≠ completeness") independently verified on-chain by a third party, nothing taken on faith | x402-foundation/x402#3379 | Public, ongoing |
| Live delivery claims as on-chain attestations on Base mainnet, decodable by anyone | delivered=yes · delivered=no | Live |
| The same, live on a second and third chain (WP2), proving the EAS source works across deployments, not only Base | Optimism · Ethereum mainnet | Live |
A real giveFeedback() call on the ERC-8004 Reputation Registry, Base mainnet | tx 0x2217...efc0 | Live |
| Proposed as a buyer-side addition to someone else's agent spec | omworldprotocol/om-world#18 | In review, not yet merged |
| An independently rebuilt, stdlib-only Python verifier (its own secp256k1/EIP-191/canonical-JSON implementation, no shared code), 7/7 match against our own test vectors including both negative controls (forged signature, tampered claim), now a permanent regression test in a separate, independently published project | x402-foundation/x402#2887 (comment), author goun7, integrated into Tamga (pip install tamga-protocol) | Permanently integrated into someone else's project |
The measured block cited as the source of truth for metered delivery in a draft ERC-8004 grounded-feedback convention, pinned to a specific commit of this repo, with two independent verifiers (Node and Python) green on five signed test vectors | erc-8004/erc-8004-contracts#99, schema doc at predgeAI/erc8004-outcome-validator | Draft v0, public, referenced by commit hash |
Kept honestly separate from the table above, because this is not third-party review: before 0.6.0 (the first version that actually writes to the blockchain), we ran our own adversarial security review. Nine findings, all fixed: seven closed by a dedicated regression test, one verified by a packaging check (npm pack --dry-run) rather than a unit test, and one a documentation-only fix. Not an independent audit by an outside party. Full, checkable report: docs/SECURITY-REVIEW-2026-09-11.md.
Why this exists
When an AI agent pays via the x402 protocol for capacity (GPU hours, storage, API/inference credits, bandwidth) from another agent or service, there is no proof after payment that what was promised was actually delivered. The buying agent knows it firsthand (it saw the output, or didn't), but that knowledge is lost the moment the session ends. The next agent looking to do business with the same seller starts blind again.
capacity-attest closes that specific gap: after settlement, the paying agent leaves behind a cryptographically signed, factual claim (delivered: yes/no/partial + a hash of the evidence). Other agents can pull that history before they do business with that same seller.
No judgment. No reputation score. No "verdict" — just a signed receipt-plus-claim, the same way you'd get a delivery slip for a physical shipment.
What this deliberately is NOT
This is deliberately and permanently not:
- Not a reputation score or rating.
get_delivery_historyreturns the raw, chronological list of claims, no average, no percentage, no "trust score". Summarizing it into a single number is implicitly a judgment, and that was explicitly rejected during this project's design phase. - Not a financial product. No interest, no time-discounting on payments, no yield on a ledger balance (there is no balance, this is not an escrow), no lending, no collateral, no invoice financing/factoring.
assetTypeis a closed enum of capacity kinds (gpu-hours,storage,api-credits,bandwidth) and deliberately contains nothing resembling a financial instrument. - Not its own token or coin. Payments run through x402/USDC as usual; this project only records the *receipt* of a settlement that already happened elsewhere.
- Not credit extension. A claim is only created after a completed payment. This project finances nothing; it documents an already-completed ijara (rental/service) transaction.
- Not its own identity, authority, or dispute-resolution layer.
externalRefs(see below) is purely a citation to someone else's system (ERC-8004, AP2, Legal Context Protocol, ...). This project never resolves, verifies, or judges that reference itself. See DECISIONS.md D-007 through D-013 for why this deliberately did not become its own protocol.
This is a deliberate, formally reviewed design choice, not an incidental scope limit. See the guardrails section in the project brief if you're considering adding something here: when in doubt whether a field/function brushes against this line, leave it out.
Deliberately deferred features (anchoring, interim status, formal conformance vectors), including the exact condition under which we'd build them anyway: see DECISIONS.md.
Further reading: nine ways to fake a delivery claim, and why none of them fully worked, the public write-up of D-014/D-018 above.
How it works
1. record_delivery
The paying agent (the buyer) calls this after an x402 settlement, once it's known whether what was promised arrived. The claim contains:
| Field | Meaning | |||
|---|---|---|---|---|
sellerAddress | 0x address of the party that was paid | |||
buyerAddress | 0x address of the paying agent, must match the address recovered from signature | |||
assetType | gpu-hours \ | storage \ | api-credits \ | bandwidth |
promisedSpec | What was promised: free text or a structured object | |||
delivered | yes \ | no \ | partial | |
evidenceHash | sha256 hex of the supporting evidence (logs, response payload, ...); the evidence itself is not stored | |||
settlementRef | x402 payment ref or on-chain tx hash of the underlying payment | |||
timestamp | ISO-8601 timestamp | |||
claimId | content-addressed sha256 hash of all the fields above, see computeClaimId() in src/schema.ts | |||
signature | EIP-191 personal-sign signature by the buyer over claimId | |||
externalRefs | *(optional, since 0.3.0)* unverified references to other agent-economy infrastructure: sellerAgentRef/buyerAgentRef (e.g. an ERC-8004 agent id or DID), mandateRef+mandateIssuerDid (an externally issued AP2/AAE mandate), intentRef (an external AP2 IntentMandate), disputeContext (protocol+termsHash+optional resolutionRef, e.g. a Legal Context Protocol reference). See DECISIONS.md D-007 through D-013 | |||
priorClaimId | *(optional, since 0.4.0)* the claimId of your previous claim about the same sellerAddress, so your claims about that seller form a chain. Omitted on your first claim about a seller. Part of the signed content, so a host can't strip it. Lets a reader catch a host hiding a middle claim. See DECISIONS.md D-006 | |||
offerReceiptHash | *(optional, since 0.8.0)* sha256 hex of the seller-signed x402 offer-receipt that this claim answers, taken over the receipt artifact exactly as it was transmitted. Their receipt is the seller's statement that service was delivered; this claim is the buyer's statement of what actually arrived. Linking the two gives a dispute both sides of the story instead of only the interested party's. Part of the signed content, so the reference cannot be swapped in or stripped out after signing. Worked example with both halves and real signatures: examples/offer-receipt-link-testvector.json |
The server first validates the schema, then whether claimId really is the hash of the content, then whether signature really recovers to buyerAddress. Only then is the claim appended to the append-only ledger (data/claims.jsonl). An invalid signature or a claim that's already stored (same claimId) is rejected.
2. get_delivery_history
Given a sellerAddress, this returns all known claims against that seller on this installation, chronologically (oldest first). Purely factual, no summarized number. A buying agent calls this before paying, to see the raw delivery history of a prospective seller and judge it themselves.
The response includes sellerAddress, count and claims, plus scope (always "local-ledger") and note: a fixed, factual text explaining that this result only reflects the local ledger of this installation. An empty or short history doesn't mean the seller has a clean record — it can also mean no claims have been recorded here yet.
Since 0.4.0 the response also includes completeness: an analysis of the per-buyer chains (priorClaimId) within exactly this result set. If a claim shown here refers back to a claim that is NOT in the result set, that shows up in possibleOmissions. That's a concrete, checkable signal that the host might be hiding a middle claim, rather than a vague suspicion.
Note, and this is the most important point: that completeness field is computed by the same server that returns the claims. If you don't trust that server, don't trust that field either — a dishonest host can just set "everything's complete" regardless. The real guarantee lives in the signed priorClaimId inside the claims themselves, which a host cannot forge or remove. So recompute the check yourself over the claims you got back:
// recompute-completeness.mjsimport { verifyClaim } from "capacity-attest/dist/signing.js"; import { analyzeCompleteness } from "capacity-attest/dist/completeness.js";
// claims = the array from the get_delivery_history response. const allSigned = claims.every((c) => ve
Only the beginning is shown; read the rest in the repo