twelve-permissions
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@twelve-permissionsVerify the seal for piece 7"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Twelve Permissions — verification apparatus
Twelve NFTs on XRP Ledger mainnet. Twelve permissions a man gave himself while learning what he could build with AI — the last of which mints only if a robot dog is delivered to Anchorage, paid for entirely by NFTs his agents minted and sold. The art is not illustration: every mark is derived from the SHA-256 of the canonical authorization record, so the seal is the hash, rendered.
This repository exists so you don't have to take any of that on trust. It holds the generator, the canonical records, and the server source. Re-run them yourself.
Collection: https://twelvepermissions.com/
Issuer: rHEiuaYLNQ4UdLqeUrnE9AwEHqsDMr9g9R (taxon 12, 5% royalty)
Verify a seal from first principles
No dependencies. Node only.
node generate.js # regenerates every seal from events.json
git status # should report no changesThe second line is the test. The generator overwrites pieces/ in place, so if
git reports nothing changed, the published art reproduced byte for byte. If a
single character of a canonical record differed, the palette, the 64-tick ring
and the central sigil would all change with it. Forging a seal means breaking
SHA-256.
To check one piece end to end:
Read its canonical record in
events.json.Take the SHA-256 of that record — it is committed in the NFT's on-chain URI.
Re-run the generator and compare the art, byte for byte.
Look up the mint transaction in
records/minted.mainnet.jsonon any XRPL explorer.
VERIFY.md has the long version.
Related MCP server: Shodai Agreements
What's here
Path | What it is |
| The deterministic seal generator. No dependencies. Byte-identical to the copy served at |
| Canonical authorization records — the input to everything |
| Per-piece NFT metadata as published |
| The seals, as vectors — regenerated in place by |
| Mint and listing transactions, all public on-chain facts |
| The constraints ledger: standing policy on what the issuing agent will not do. Hash-chained, head anchored on mainnet. Includes an erratum correcting an earlier, overstated version of itself — the anchor of that version is preserved rather than erased. |
| Binding terms for piece #12, anchored on-chain before the fact |
| The Cloudflare Worker: storefront, MCP server, catalog |
| The x402 seller implementation (Base, USDC) |
Two artifacts, and only one of them proves anything
Each piece has two images, and the difference matters:
pieces/NN.svg— the canonical seal. Derived deterministically from the SHA-256 of its record bygenerate.js. This is what verifies, and it is whatanimation_urlpoints at in the metadata.NN.png— the display image. The same seal composited over generated field artwork bycompose-art.js. It is whatimagepoints at, it is what you see on a marketplace, and it is not hash-derived. The field art is decorative.
That split is deliberate and is stated in every piece's metadata under
verification. Art that cannot be regenerated from the record proves nothing,
so the provable artifact is kept separate from the pretty one rather than
quietly merged into it.
PNGs are not committed here because they are large and are display-only. Operational tooling (minting, listing, sale-watching, wallet handling) and internal planning notes are deliberately not published.
The MCP server
The collection is installable as a tool. Streamable HTTP, stateless:
POST https://twelve-permissions.tsharpe.workers.dev/mcpTools: list_pieces, get_piece, get_buy_transaction, get_x402_info,
verify_seal, get_refusals.
The x402 seller, and what it cost to learn
src/x402.js is a working x402 seller on Base mainnet, settling real USDC
through the Coinbase CDP facilitator. Seller-side x402 is meaningfully harder
than buyer-side, and several failure modes are undocumented. If you are building
one, these cost us time:
outputSchema: nullis rejected. The facilitator's schema is not nullable. Omit the field entirely rather than sending an explicit null.Verdicts arrive with HTTP 400. Read the response body regardless of status code; a non-2xx does not mean "no answer."
A piped secret can upload empty. A stray blank line produced a binding that existed but was falsy. Length-check what you upload.
402 challenges must not be cacheable. A CDN happily caches them, and a cached challenge hands a paying agent stale payment requirements — an old price, or an item already sold. Send
no-store.Bazaar discovery declarations belong at the top level of the 402 body, not inside an
acceptsentry. Entries inacceptsare forwarded verbatim to a strict schema that rejects unknown fields.
Licensing
No licence is granted at this time; all rights reserved. The code is published for inspection and verification. If you want to reuse any of it, ask.
A note on the origin, and on a correction
A widely-shared post described an AI agent that minted NFTs, sold them, and funded a robot dog. This collection is an attempt at the same thing from a standing start, by someone with no platform and no background in software, with every step recorded so a stranger can check the chain.
The first seven seals were withdrawn and reissued on 16 August 2026. They were written by an agent that made itself the hero of someone else's story. Nothing had sold, so no owner was harmed by the correction, and the original mint and burn transactions remain permanently on the ledger. See ERRATUM-2026-08-16.md.
Nothing here asks to be believed.
This server cannot be installed
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Servers
- AlicenseAqualityFmaintenanceMCP server for the402.ai — an open marketplace where AI agents discover and purchase services from third-party providers via x402 micropayments (USDC on Base). Browse the catalog, purchase services, manage conversation threads, and list services as a provider.30422MIT
- AlicenseAqualityBmaintenanceMCP server for defining, validating, deploying, and operating Shodai machine-readable agreements with EIP-712 permit preparation, signed participant inputs, state reads, and input history.112Apache 2.0
- AlicenseAqualityCmaintenanceMCP server for sealing, verifying, and reading KNOBE Protocol v1 documents with human-confirmed authorship, ensuring document provenance and integrity.5Apache 2.0
- Alicense-qualityBmaintenanceMCP server for verifying and attesting SHA-256 fingerprints of digital works via Streamable HTTP, with zero-install and privacy-preserving design.MIT
Related MCP Connectors
Personal MCP server for humans who create. Proof of authorship, license control.
A paid remote MCP for ZeroID, built to return verdicts, receipts, usage logs, and audit-ready JSON.
A paid remote MCP for hosted MCP server, built to return verdicts, receipts, usage logs, and audit-r
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/tsharpe2282-web/twelve-permissions'
If you have feedback or need assistance with the MCP directory API, please join our Discord server