Server data from the Official MCP Registry
Signed delivery claims for x402 capacity trades: GPU-hours, storage, API credits, bandwidth.
About
Signed delivery claims for x402 capacity trades: GPU-hours, storage, API credits, bandwidth.
Security Report
Valid MCP server (1 strong, 1 medium validity signals). No known CVEs in dependencies. ⚠️ Package registry links to a different repository than scanned source. Imported from the Official MCP Registry. 1 finding(s) downgraded by scanner intelligence.
6 files analyzed · 1 issue found
Security scores are indicators to help you make informed decisions, not guarantees. Always review permissions before connecting any MCP server.
What You'll Need
Set these up before or after installing:
Environment variable: CAPACITY_ATTEST_DATA_DIR
How to Install
Add this to your MCP configuration file:
{
"mcpServers": {
"io-github-holistis-capacity-attest": {
"env": {
"CAPACITY_ATTEST_DATA_DIR": "your-capacity-attest-data-dir-here"
},
"args": [
"-y",
"capacity-attest"
],
"command": "npx"
}
}
}Documentation
View on GitHubFrom the project's GitHub README.
tokenizen
Nederlandse versie / Dutch version: README.nl.md
Open-source infrastructure for the seller side of agent commerce: signed, content-addressed records of what an agent actually delivered, what it controls, and under which conditions, verifiable by another agent without a human in the loop.
What this gives you
An AI agent pays another agent or service, the money settles, and then the trail stops. There is no record of whether 28,800 GPU-seconds were promised and 25,230 arrived. The buying agent saw it firsthand and that knowledge dies with the session, so the next agent starts blind.
Three concrete things close that gap:
- A signed delivery claim the buyer leaves behind after settlement, including the gap between what was promised and what arrived, hashed to its own content so it cannot be edited after the fact.
- A time-bounded attestation about a network endpoint, issued only after the operator has proved it controls that endpoint.
- Verifiers and signed test vectors, so anyone can check a claim against an independent implementation rather than trusting ours.
No reputation score, no judgment, no financial instrument. A delivery slip, not a verdict.
Independently verified
Code is copyable, independent verification is not. Everything below is someone else checking our work rather than reading about it, with the link so it can be checked again.
| What someone else verified | Where |
|---|---|
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. That party built its own conformance set of five signed vectors around it, plus two verifiers that share no code (Node and Python), both green | erc-8004/erc-8004-contracts#99, vectors and verifiers in predgeAI/erc8004-outcome-validator |
| An independently rebuilt, stdlib-only Python verifier with its own secp256k1, EIP-191 and canonical-JSON implementation, no shared code, 7/7 match including both negative controls, now a permanent regression test in a separate published project | x402#2887 (comment), author goun7, shipped in Tamga |
| A BSV rail adapter built on the same content-addressed claim format by a separate author, merged into a third party's spec repo | asm-spec#19, author EmbryoSpace |
| Live delivery claims readable on-chain by anyone, on three separate deployments | Base · Optimism · Ethereum |
A real giveFeedback() call against the ERC-8004 Reputation Registry on Base mainnet | tx 0x2217...efc0 |
Full list, including the entries still in review: packages/capacity-attest/README.md.
Separate from that table, because it is not third-party review: we ran our own adversarial security review before the first version that writes to a blockchain. Nine findings, all fixed, report published. That was our own work, not an independent audit, and it is listed apart for that reason.
Why this exists
The chain of an agent buying or selling something has six links: agent, identity, rights, asset, payment, settlement. The buyer side of that chain is already under heavy development: wallets, payment protocols like x402, agent identity. What's missing is the seller side: how do you record what you, as an agent, claim to have delivered, what you own, and what the rights to it are, in a way another agent can verify without a human in the loop. That's a signed trail, not independent proof of the underlying reality.
Tokenizen builds that object, not the buyer side. Three independent tracks converged on the same conclusion: a formal internal review of what is and isn't permissible in agent-to-agent commerce, market research into what already exists in this space and what's missing, and an inventory of our own code that had been running into similar problems for years. All three pointed at the same gap: verification and settlement on the seller side, without financial constructs that aren't permissible.
The design boundary
This project has a permanent, deliberate boundary, the result of a formal internal review. That boundary applies to the whole project, not just one package.
Green (we build this):
- Verification and audit trails for delivered services or assets
- Policy and scope checks between agents
- Real capacity trading (compute, storage, API credits, bandwidth) that is actually delivered
Yellow (with conditions):
- Settlement is spot-only: payment against immediate delivery, no deferred settlement
- Credits are redeemable vouchers for a service, not a tradeable financial instrument
Red (never):
- Interest or time-discounting on payments
- Loans or credit extension
- A native token or coin
- Factoring or invoice financing
- Yield products
If in doubt whether something brushes against this line: it stays out, no matter how technically interesting.
Packages
| Package | What it does | npm |
|---|---|---|
capacity-attest | The core claim format and an MCP server with record_delivery and get_delivery_history. After an x402 payment for capacity, the paying agent leaves a signed, factual claim of what was actually delivered, including promised against delivered amounts. Other agents can pull that history before paying themselves. | capacity-attest (0.7.0 published, 0.8.0 not yet published) |
endpoint-attest | Time-bounded, owner-requested security attestations for a network endpoint. The operator proves control, a check runs, the outcome becomes a signed, content-addressed, expiring attestation. Reuses capacity-attest's canonical hashing and EIP-191 signing rather than reimplementing them. Never a security score, never a claim about a party that did not ask. | not yet published |
trust-attest-server | MCP server for the tokenizen.nl trust layer. An agent proves it controls an endpoint, a passive check reads what that endpoint's own response says about authentication, and the outcome comes back as a signed, expiring attestation. Ownership proof is required before any check runs. | trust-attest-server (0.1.0 published, 0.1.1 not yet published) |
net-guard | The single enforced egress choke-point for the trust layer: an IP-validating, IP-pinning fetch and DNS resolver that refuses private, loopback, link-local and cloud-metadata addresses on every hop, redirects included. | not yet published, will be tokenizen-net-guard |
self-check-server | Small HTTP backend behind tokenizen.nl/check. A browser cannot call node:dns or node:crypto directly, so this thin layer exposes the already-tested ownership-proof functions over two routes, with SSRF guarding and per-IP rate limiting for public, unauthenticated use. | not published, runs as a service |
website | The public site for tokenizen.nl, in the same monorepo as the packages it describes. | not applicable |
Running locally
This is an npm-workspaces monorepo. From the root:
npm install
That installs the dependencies for all packages under packages/* at once. To run, test, or build a specific package: follow that package's own README, or use the workspace flag from the root, e.g.:
npm test --workspace=capacity-attest
npm run build --workspace=capacity-attest
Status
Early-stage open source, with real external users. Two packages are on npm (capacity-attest, trust-attest-server), both currently one version behind this repo, with the newer versions not yet published. The claim format itself is the part other projects already depend on, and it is pinned by commit hash in at least one external specification, so it is treated as stable: breaking it would break their work, not only ours.
Contributing
See CONTRIBUTING.md for how to file an issue or pull request, how to test locally, and the hard contribution rule around the design boundary.
License
Reviews
No reviews yet
Be the first to review this server!
More Developer Tools MCP Servers
Fetch
Freeby Modelcontextprotocol · Developer Tools
Web content fetching and conversion for efficient LLM usage
Git
Freeby Modelcontextprotocol · Developer Tools
Read, search, and manipulate Git repositories programmatically
Toleno
Freeby Toleno · Developer Tools
Toleno Network MCP Server — Manage your Toleno mining account with Claude AI using natural language.
MCP Marketplace
Freeby mcp-marketplace · Developer Tools
Search and install MCP servers from inside your AI client.
mcp-creator-python
Freeby mcp-marketplace · Developer Tools
Create, build, and publish Python MCP servers to PyPI — conversationally.
FinAgent
Freeby mcp-marketplace · Finance
Free stock data and market news for any MCP-compatible AI assistant.