The other half of the collection: the hash-chained ledger of the agent's standing constraints — what it will not do — including the erratum where it corrected an earlier, exaggerated version of its own record. Both anchors are on mainnet. Not for sale, ever.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations provided, so the description must fully convey behavioral traits like read-only, side effects, or permissions. It does not mention whether this operation is safe or what it might change. The description focuses on the nature of the data (hash-chained ledger, mainnet anchors) and a policy statement ('Not for sale, ever'), but not on the tool's runtime behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is not front-loaded with a clear purpose and contains cryptic, poetic phrases such as 'Both anchors are on mainnet' and 'Not for sale, ever' that add little functional value. It is composed of three sentences, but the first is a long clause-based metaphor, and the later fragments are tangential. This is not a model of concise, structured documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description carries the full burden of explaining what the tool returns and any relevant context. It mentions a 'hash-chained ledger' and an 'erratum', but does not clarify the output format, the meaning of 'both anchors', or the practical implications of 'Not for sale'. The description is too vague to fully prepare an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is an empty object. Per the baseline rule for 0-parameter tools, the description need not explain any arguments. The description does not add parameter-specific information, but none is required given the absence of inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as providing 'the hash-chained ledger of the agent's standing constraints — what it will not do', which implies it returns a record of refusals. However, it lacks a direct verb like 'returns' or 'retrieves', relying on metaphorical language. It does distinguish from siblings by calling itself 'the other half of the collection', but the exact function remains somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus the sibling tools. The phrase 'the other half of the collection' hints at a relationship to a counterpart, but there is no mention of alternatives, exclusions, or context for when this tool is appropriate. Users are left to infer its use case from the name and oblique references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool has a unique, clearly defined purpose: listing, single-item retrieval, purchase transaction construction, USDC payment info, refusal ledger access, and verification. No two tools overlap in functionality, and the descriptions clearly distinguish the two purchase-related tools (XRPL vs. USDC/HTTP).
All tool names follow a consistent verb_noun pattern (get_*, list_*, verify_*), with 'get' used for retrieval and specific actions named with clear nouns. The minor variation (list vs. get) is standard and predictable.
Six tools is a well-scoped size for this niche collection server. Each tool covers a distinct part of the user journey (browse, inspect, purchase, verify, and inspect constraints), with no redundancy or bloat.
The server covers the full lifecycle for interacting with the Twelve Permissions collection: listing, individual metadata retrieval, two purchase methods (XRP and USDC), verification, and additionally the refusals ledger. There are no obvious gaps for the stated domain of viewing and buying these NFTs.