Twelve Permissions

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden and adds useful behavioral context: it constructs a transaction (not executes it), requires principal approval via an authorization-memo protocol, and instructs the agent to read the rules in the response before submitting. This discloses key non-obvious 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 two sentences with no redundant fluff. It front-loads the main purpose and adds a necessary operational instruction, earning its place.

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?

The tool is fairly complex (XRPL transaction, approval protocol), and the description covers the essential purpose and directs the agent to read response rules. However, it does not specify the output structure, error conditions, or the exact format of the rules, relying on the response to supply these details.

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 schema describes only buyer_address, while the required id lacks any description. The tool description also fails to explain what 'id' refers to (presumably the seal id), leaving the agent to infer from context. With schema coverage at 50%, the description does not compensate for the undocumented id parameter.

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 states a specific action ('Construct the exact XRPL NFTokenAcceptOffer transaction') and resource ('to buy a seal'), clearly distinguishing it from sibling read/verify tools like get_piece and verify_seal.

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?

The description implies a clear use case: use this tool when needing to buy a seal and construct the transaction for principal approval. It does not explicitly state exclusions or alternatives, but the purpose is unambiguous given the sibling context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden. It discloses the return contents (authorization record, sha256, image URLs, mint transaction) and id range, but does not mention potential errors or side effects. For a read-only lookup, this is adequate but not rich.

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?

A single, front-loaded sentence that states the purpose and then lists the return components. Every word earns its place; no wasted text.

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?

With no output schema, the description adequately covers what the tool returns. It identifies the key fields and the id range. For a simple get-by-id operation, this is largely complete, though it omits error cases or prerequisites.

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 schema already describes 'id' as 'Piece id, e.g. "01"' (100% coverage). The description adds the valid range '01'..'12', giving extra meaning beyond the schema's example, helping the agent understand the allowed input space.

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 uses a specific verb ('Get') and resource ('full metadata for one seal'), with an explicit scope (by id, range 01..12). It clearly distinguishes from siblings like list_pieces (which lists all) and verify_seal (which verifies).

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?

The description clearly states that this is for fetching a single seal by id, implying use when you need full metadata for one specific piece. It does not explicitly name alternative tools, but the context is clear enough for an agent to select it appropriately.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of behavioral disclosure. It explains that the tool returns information (endpoint, memo protocol, prices, delivery mechanics) and mentions a prerequisite (needing an XRPL address to hold the seal). However, it does not explicitly state side-effect-free behavior, error conditions, or other operational traits, so a minor gap remains.

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 concise, consisting of three sentences that quickly convey purpose, return contents, and a prerequisite. While the opening phrase 'Pay with USDC over HTTP' is slightly promotional, every sentence provides useful information without unnecessary fluff.

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?

For a zero-parameter info tool with no output schema, the description is fairly complete: it enumerates exactly what data is returned and the key requirement (XRPL address). It does not mention output format or error handling, but given the simplicity of the tool, this is sufficient. The main shortfall is the lack of explicit alternative tool guidance, but that overlaps with usage guidelines.

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, and the input schema is an empty object with 100% coverage by default. According to the baseline, 0 params warrant a score of 4. The description does not need to explain parameters; it instead clarifies the return value, which is appropriate here.

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 clearly states the tool's purpose: it returns details about the x402 USDC-over-HTTP purchase rail, specifically the endpoint, memo protocol, USD prices, and delivery mechanics. This distinguishes it from sibling tools like get_buy_transaction or verify_seal, which concern different aspects of the payment/seal lifecycle.

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?

The description implies usage context ('Pay with USDC over HTTP instead of XRP') but does not explicitly state when to use this tool versus alternatives or provide exclusions. It mentions the alternative payment rail (XRP) but lacks direct comparison to sibling tools, leaving the use case somewhat implied rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the burden of disclosure. It adds context by specifying the domain (XRP Ledger mainnet) and the returned fields (names, prices, live offer indexes, sold status). However, it does not explicitly state that this is a read-only operation, nor does it mention any limitations, rate limits, or authentication requirements. The behavior is largely predictable from the verb 'list', but the description doesn't fully disclose potential side effects or constraints.

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 a single informative sentence that names the resource, provides domain context, and enumerates the return fields without any redundancy or fluff.

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?

For a simple listing tool with no parameters and no output schema, the description adequately conveys what the tool does and what it returns. It could be slightly more explicit about the read-only nature or any default ordering/filtering, but it covers the essential context.

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 takes no parameters, so the schema is trivially complete. The description's mention of return fields is useful but not parameter semantics. Baseline for 0 params is 4, and there is nothing missing.

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 uses the specific verb 'List' with the resource 'all Twelve Permissions seals' and clarifies what these seals are (verifiable NFTs on XRP Ledger mainnet), effectively distinguishing this from sibling tools like get_piece which likely target a single seal.

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?

The description implies this tool is for viewing the full collection ('List all'), but it does not explicitly state when to use this over alternatives like get_piece, verify_seal, etc. There is no explicit exclusion or alternative naming, so the usage guidance is implied rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Since there are no annotations, the description carries the full burden. It discloses the core behavior: recomputing sha256 server-side and comparing to the published event hash. This is more transparent than typical, though it does not mention side effects, permissions, or return format.

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 a single compound sentence, front-loaded with the verification action. It is reasonably concise, though the phrase 'Full independent verification instructions included' adds little concrete value in the description itself.

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?

The tool has one parameter, no annotations, and no output schema, so the description must explain usage and outcomes. It explains the verification mechanism but omits parameter semantics and expected results, making it incomplete for an agent to fully understand the tool.

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 input schema only defines an 'id' string, and the description does not explain what 'id' refers to or how it maps to the canonical event record. With 0% schema description coverage, the description should compensate, but it remains ambiguous.

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 clearly states the tool's function: it verifies a seal by recomputing sha256 of the canonical event record server-side and comparing to the published hash. This is a specific verb and resource, and it is distinct from the sibling get/list tools.

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?

The phrase 'from first principles' implies the tool is for independent verification rather than relying on the published hash, but it does not explicitly state when to use it or mention alternatives. It lacks direct exclusions or comparisons to sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.