xahau-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v2.0.1
Disambiguation4/5
Most tools have distinct purposes, but some overlap exists (e.g., explain_account provides a combined report vs individual getters, and multiple hook analysis tools could be confused). Overall, descriptions make differences clear.
Naming Consistency4/5
Tool names mostly follow a verb_noun pattern with underscores (e.g., get_account_info, decode_hook_on). A few utility functions (xah_amount, ripple_time) break the pattern but are still self-explanatory. Consistency is good but not perfect.
Tool Count3/5
87 tools is very high but justified by the complexity of Xahau development. However, the surface is dense and could be intimidating. Some tools could be merged (e.g., many build_* unsigned tools).
Completeness5/5
The toolset covers the entire Xahau development lifecycle: account queries, transaction building and simulation, hook static and dynamic analysis, network status, governance, quantum readiness, and more. No obvious gaps.
Average 3.9/5 across 83 of 87 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 101 commits in the last 12 weeks
- Last stable release on June 11, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It says 'Heuristically classify' and 'Offline', but fails to explain what the heuristic entails, whether it is read-only, or any side effects. No mention of error conditions or assumptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single sentence, concise but too brief. It front-loads purpose but lacks any structuring or additional details. Could be expanded moderately without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a complex nested object parameter, no output schema, and no annotations, the description is severely insufficient. Agent has no guidance on input format, output expectations, or heuristic behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'tx' is a black-box object with no schema details. The description does not clarify what 'tx' should contain (e.g., transaction object, hex blob, JSON). With 0% schema description coverage, the parameter is entirely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states the tool classifies a Burn2Mint-related transaction, specifying the verb 'classify' and resource 'Burn2Mint transaction'. It adds bridge direction context (XRPL↔Xahau) and offline nature. However, 'Heuristically' introduces ambiguity, and it doesn't distinguish from other decode tools like decode_tx_blob.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. The only hint is 'Offline', implying no network calls, but no explicit when-to-use or when-not-to-use. Sibling tools include many decode functions, but no comparative advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It mentions 'Read-only,' indicating no state modification, but does not disclose potential behaviors like pagination, error handling, or limits on the response size.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. However, it is very brief and could benefit from slight expansion to cover more details without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool with 2 parameters and no output schema, the description should at least mention the return format or common error cases. It only states the purpose and read-only nature, which is insufficient for full comprehension.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not add any meaning beyond the schema structure. It fails to explain the parameters (address, network) or their expected formats, leaving the agent with no extra guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves trustlines (issued-currency balances) for an account and notes it is read-only. This distinguishes it from sibling tools like get_account_info or get_account_objects, though it does not explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use or not use this tool versus alternatives. The description only implicitly suggests it is for retrieving trustlines, but lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must convey behavioral traits. It mentions read-only and URI decoding, but fails to disclose pagination, rate limits, authentication requirements, or any side effects beyond the read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two sentences, front-loading the main purpose. No extraneous text, but it could be slightly expanded to include necessary details without losing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters and no output schema, the description is insufficient. It does not mention return format, pagination, or edge cases, leaving the agent with gaps in understanding the full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for parameters, and the description does not explain the meaning of 'address' or 'network' beyond their schema definitions. This leaves the agent without guidance on parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves URITokens owned by an account and decodes URIs from hex to text. The verb 'get' and resource description are specific, but no differentiation from sibling tools like decode_uritoken_id is provided.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide when to use this tool versus alternatives. It only states 'Read-only', implying non-destructive use, but no explicit context or exclusion criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Read-only', which indicates no mutation but does not cover other behavioral aspects (e.g., authentication, error handling, data freshness, or rate limits). This is minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no superfluous information. It front-loads the key resource and fields, followed by the read-only trait. Every word contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description should describe the return format. It lists fields (balance, sequence, flags, regular key) but does not specify the structure or data types. The description is insufficient for an agent to fully understand the output, though the tool is simple.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no information about the parameters 'address' or 'network'. The schema covers 50% with a description for 'address', but the description fails to compensate for the undocumented 'network' parameter or add any semantic context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates the tool retrieves account root information including balance, sequence, flags, and regular key. It explicitly states 'Read-only', distinguishing it from mutation tools. The verb 'get' is implied, and the resource 'account root' is specific, differentiating from sibling tools like get_account_objects or get_account_lines.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description does not mention when-not-to-use or provide context for selecting this over other account-related tools. The 'Read-only' hint is the only implicit usage guide, but it lacks explicit comparisons to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only states 'read-only', lacking details on error behavior, rate limits, or what happens for missing accounts. Minimal beyond basic safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one sentence that covers the core action and safety. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Does not explain output format or error conditions. No output schema, so description should at least hint at what is returned. Incomplete for a tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description provides no additional meaning for parameters. Schema coverage is 0%, yet no parameter info is given. This is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'open DEX offers' and specifies 'read-only', which indicates the tool's purpose. However, it does not explicitly differentiate from sibling tools like get_account_lines, which also deal with account data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: 'placed by an account'. But no guidance on when not to use it or alternatives among many siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions 'Read-only', which indicates no destructive side effects, but with no annotations provided, this is minimal transparency. It also notes the decoding of the HookOn bitmap, adding some behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, relatively clear sentence with no extraneous information. It is efficient but could be improved by front-loading the verb.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With two parameters and no output schema or annotations, the description provides a basic idea of the output but lacks details on required fields, defaults, or the return format. It is adequate but has gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not elaborate on the parameters 'address' or 'network'. It only implies the address via 'account', adding little value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves hooks installed on an account with decoded HookOn bitmaps, which distinguishes it from sibling tools like get_hook_definition or get_hook_state. However, the phrasing is somewhat passive and could be more active (e.g., 'Retrieve').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_hook_definition or get_hook_state. The description lacks explicit usage context or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavioral traits. It states 'Read-only network + offline analysis', which clarifies safety. However, it omits details like performance implications for many hooks, error handling, or network dependency details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but lacks structure. It does not include parameter details or a clear breakdown of steps. While efficient, it is incomplete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex multi-step tool (fetch all hooks, retrieve each WASM, run analyzer), the description is too brief. It does not mention output format, analyzer behavior, or limitations. With no output schema, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about the parameters (address, network) beyond what the schema already gives. The description adds no value for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (Fetch, pull, run), the resource (every hook on an account, each HookDefinition's WASM), and the outcome (run analyzer over all). It distinguishes from siblings like get_account_hooks (list only) and analyze_hook (single analysis).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is for comprehensive auditing but does not explicitly state when to use vs alternatives. No mentions of when not to use or alternative tools for simpler tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only mentions 'Read-only' but omits details like error behavior, pagination, rate limits, or what happens if namespace doesn't exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no wasted words. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks output schema, return format, error examples, or performance hints. For a blockchain state read, more context on response shape and edge cases would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 33% (only namespace described). Description adds that it's a key→value map and namespace is 32-byte hex, but address and network remain unexplained. Adds some value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Read Hook State entries for an account namespace (32-byte key→value map). Read-only.' Distinct verb and resource, distinguishes from siblings like get_hook_definition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use vs alternatives. Only implies read-only for reading state, but no explicit when/when-not or comparisons to similar tools among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 heuristic, offline nature and that it does not execute bytecode, but does not detail input requirements or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a clarifying appendix, concise and front-loaded with the action. Minor redundancy could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, the description covers the tool's purpose and approach adequately, but fails to explain input parameters or when to choose this tool over siblings, leaving gaps for a functional understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not explain the three parameters (hookOn, wasmHex, wasmBase64) at all, leaving the agent without guidance on how to provide input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool infers the function of a Hook from its structure, listing example categories and specifying it is heuristic and offline, which distinguishes it from execution-based siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for static analysis without execution, but does not explicitly state when to use this tool versus alternatives like analyze_hook or hook_dry_run.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must convey behavior. It states 'Offline' (no network) and that output is hex. However, it does not disclose error handling, validation of input types, case sensitivity, or expected output format beyond 'hex'. This leaves significant gaps for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. It front-loads the core purpose and adds a key behavioral detail (omit to allow all) succinctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description could better explain how the hex is used (e.g., in SetHook transactions) and provide an example. It mentions 'SetHook' and 'offline', but lacks integration context or post-encoding steps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a minimal description ('e.g. ["Payment","Remit"]'). The description adds context: 'list of transaction types a hook should be allowed to emit' and mentions encoding similarity to HookOn. This is helpful but could specify valid values or format more precisely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds a canonical hex for the HookCanEmit field from a list of transaction types. It mentions the amendment and similarity to HookOn. However, it does not explicitly differentiate from sibling tools like encode_hook_on or decode_hook_can_emit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a single conditional: 'Omit the field entirely... to allow emitting anything.' This provides a when-not-to-use case. But it lacks comparison to related encoding tools or guidance on when to use this vs encode_hook_on.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It mentions 'Offline' and that it returns SARIF-lite findings, but does not state whether it is read-only, requires authentication, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first clearly defines the action and output, the second adds context. Minimal waste, though 'THE MOAT' may be jargon. Efficient but could be slightly clearer.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite an output schema existing (unseen), the description only mentions SARIF-lite findings. It lacks details on parameter usage, prerequisites, or error cases, leaving gaps for a tool with 7 parameters and no schema documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% with 7 parameters. The description mentions 'CreateCode WASM (+ optional SetHook params)' implying wasmHex/wasmBase64 are inputs, but does not explain flags, grants, hookOn, namespace, or parameters. Partial compensation, but insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs static analysis on hooks using a security rule engine and returns SARIF-lite findings. It distinguishes itself as 'The first Hooks-specific analyzer' among many hook-related siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided. The term 'Offline' implies no network dependency, but there is no comparison with alternatives like inspect_hook_wasm or hook_dry_run.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Offline', implying no network calls, but does not disclose whether the tool is read-only, has authentication needs, rate limits, or side effects. The description lists what the report includes but not behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with purpose and components. It is efficient but could be slightly more concise by removing redundant phrasing like 'One-call comprehensive report on a Hook' followed by a colon list.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 unannotated parameters, no required fields, 0% schema coverage), the description fails to explain what inputs are necessary or how to use them. The presence of an output schema excuses return value details, but input side is severely incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema has no parameter descriptions. The description does not mention any of the 5 parameters (grants, hookOn, wasmHex, namespace, wasmBase64), leaving the agent with no guidance on which to provide or their formats. This is a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool produces a comprehensive report on a Hook, listing its components (structure, classification, security analysis, HookOn decode, fee estimate). It distinguishes itself from sibling tools like inspect_hook_wasm or classify_hook by being a one-call aggregate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It says 'One-call comprehensive report' and 'Combines inspect + classify + analyze + estimate', implying this is the go-to tool for a full overview rather than calling individual tools. It lacks explicit when-not-to-use or alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only mentions 'Offline' for network independence. Lacks details on idempotency, authentication, or side effects. For a decode tool, read-only nature is assumed but not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence packs core information (what, input, output, offline). No redundancy or superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, description is thin. It does not explain the structure of hook definitions or behavior on invalid input. Sufficient only for basic understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description adds value by naming 'JSON or tx blob' which maps to 'tx' and 'txBlobHex' parameters. However, it does not explain the difference, constraints, or which to prefer.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'decode', resource 'SetHook transaction', and output 'hook definitions, each with HookOn decoded'. Distinguishes from sibling decode tools like decode_hook_on and decode_tx_blob by specifying the transaction type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies offline usage, but no explicit when-to-use, when-not-to-use, or alternatives. Could benefit from stating it is for decoding submitted or constructed SetHook transactions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It labels the tool as read-only, which signals safety, but does not cover error behavior (e.g., hash not found) or performance. Listing fields adds some transparency, but more detail would improve.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with a parenthetical, efficient and front-loaded. Every phrase adds value, though parameter info is missing. Could be improved without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description partial covers return values by listing fields. Missing error conditions, required auth, or pagination (if any). Adequate but not thorough for a fetch tool with this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description adds no parameter-level details. It does not explain the format of hookHash (e.g., hex) or the effect of the network parameter (default mainnet mentioned in schema but not in description). The purpose mentions 'by hash', but that is about the tool, not the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it fetches a HookDefinition ledger object by hash, listing key fields (CreateCode WASM, HookOn, fee, reference count) and labels it read-only. This differentiates it from sibling tools like get_account_hooks (list all) or get_hook_state (state data).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you have a hook hash and want the definition, but lacks explicit when-to-use, when-not-to-use, or comparisons to alternatives like get_account_hooks or get_hook_state. No context on prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses 'Never signs' and rejects unreachable quorum, but lacks details on what happens with invalid accounts or whether it returns a transaction blob. More behavioral context is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with purpose, and uses clear language. However, the informal 'ROTATION WIZARD alt' phrasing slightly reduces clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, and no annotations, the description fails to explain the return value (e.g., unsigned transaction blob) or usage workflow. Leaves significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description only explains quorum=0 removal. The signers array, account, and network parameters are not described. Minimal compensation for lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: assembling an unsigned SignerListSet (multisig) transaction. It contrasts with disable-master and mentions safety for high-value accounts, distinguishing it from sibling tools like build_sethook_unsigned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides when to use (safer than disable-master for high-value accounts) and when quorum=0 removes the list. It warns against unreachable quorum. However, it does not explicitly list alternatives among the many build_*_unsigned siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It discloses the tool is offline (no network call) and uses a specific codec, which is helpful. However, it does not mention any limitations, side effects, or that the operation is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence that conveys the essential purpose and key behavior (offline). Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description provides minimal context. It omits the return format and any constraints on the hex blob, leaving gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet the description only implies the parameter is a hex string without detailing format, length, or validation rules beyond the schema's minLength. It fails to compensate for the lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (decode), resource (Xahau transaction blob in hex), output (JSON), and mechanism (Xahau-aware binary codec). It also distinguishes the tool from siblings like encode_tx_blob by specifying decoding.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for decoding transaction blobs offline but does not explicitly state when to use this tool versus alternatives like decode_result or encode_tx_blob. No when-not guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the tool is 'not reversible offline,' which discloses a key behavioral trait. It also implies no side effects (offline, read-only). However, it does not describe error handling or return format, which would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence with a parenthetical) and front-loaded with the core action. Every word adds value; no redundant language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple decode tool with one input and no output schema, the description covers purpose and structure but omits what the output looks like (e.g., fields of the explained structure). It is minimally adequate but leaves ambiguity about the return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter uriTokenId has 0% schema description coverage. The description adds only that it is a 'URIToken ID' to be validated, but offers no guidance on format, length, or examples. The parameter meaning relies entirely on the tool name and generic type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Validate a URIToken ID and explain its structure') and provides specific details about the resource (SHA512-Half of issuer||URI). This distinguishes it from sibling decode tools like decode_hook_can_emit or decode_tx_blob, which target different data types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes 'Offline' but does not specify when to use this tool versus alternatives like get_account_uritokens (which might list URITokens) or other decode tools. No explicit context about when to validate vs fetch or prerequisites is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description declares 'Read-only,' which is a key behavioral trait in the absence of annotations. However, it omits other details like pagination, error handling, or response structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no extraneous words. Every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 3 parameters, the description lacks information about return format and does not fully compensate for undocumented parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the 'type' parameter by listing examples, compensating for the schema's 0% coverage. However, it does not explain the 'address' or 'network' parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves ledger objects owned by an account, with optional filtering by type. It distinguishes from sibling tools like get_account_info (basic info) and get_account_hooks (hooks-specific).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for general queries with type filtering but does not explicitly mention when to use alternatives or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It clearly states the tool is a read operation, specifies the data source (on-ledger singleton), notes it requires no admin node, and quantifies the call as 1 RPC call. This is good transparency for a read-only operation, though rate limits or potential errors are not mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences that efficiently convey the tool's purpose, output, and nature. Every sentence adds value without redundancy, meeting the highest standard for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter and an output schema (present but not shown), the description provides sufficient context: what data is returned, the data source, and the cost (1 RPC). It lacks details on error cases or edge conditions, but given the tool's simplicity and the presence of an output schema, it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate. The single parameter 'network' (with enum and default) is not described in the text, leaving the agent to infer its purpose from the enum values. While the parameter is simple, the description misses an opportunity to clarify its role, resulting in lower effectiveness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly identifies the tool as retrieving live amendment status for the network, detailing what is included (enabled amendments with human names, voting set with >80%). However, it does not differentiate from sibling tools like 'predict_amendment_activation' or 'check_amendment_blocked', leaving some ambiguity about when to use this specific tool over alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Indicates that it reads the on-ledger Amendments singleton without requiring an admin node, which implies it's a simple read operation. No explicit guidance on when to use this tool versus siblings like 'predict_amendment_activation' or 'diff_node_amendments', limiting its decisiveness for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It declares read-only behavior, but lacks details on error handling, rate limits, or consequences of invalid inputs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, communicating the core purpose in a single sentence without any fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 is adequate for a simple tool but lacks details on return format or constraints. It is minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds minimal parameter information. It mentions the default 'validated' for ledgerIndex but does not explain the network enum or the ledgerIndex parameter types. This fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves the header/summary of a ledger, defaulting to the latest validated. It uses specific verbs and resources, and distinguishes from siblings as this is the only ledger header tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the tool is read-only, implying safe use, but does not explicitly state when to use it versus alternatives, nor provide any when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses read-only behavior and inclusion of HookExecutions metadata. However, no annotations are provided, and the description does not mention error handling, authentication needs, or rate limits, which would increase transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that conveys essential information without unnecessary words. It is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, so the description should clarify the return format. It mentions validated transaction and HookExecutions metadata, but lacks details about response structure or field explanations. Adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only mentions 'by hash' for txHash but gives no detail on network or format. This adds minimal meaning beyond the schema structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a validated transaction by hash, including specific HookExecutions metadata, and notes it is read-only. This distinguishes it from sibling tools like trace_transaction_stakeholders or simulate_transaction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for fetching a transaction by hash with hook metadata, but does not explicitly state when to use this tool over alternatives or provide exclusion criteria. Sibling context helps, but the description itself lacks usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions 'Offline' but does not explain what this means (e.g., no network required, cached data). The tool is likely read-only, but this is not explicitly stated, leaving the agent uncertain about side effects or dependencies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action. Every word earns its place; there is no fluff. It is the epitome of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are no parameters and no output schema, the description provides a reasonable amount of information: it names the resource and lists the output fields. However, it could elaborate on what the 'Hook analyzer rule registry' is and how 'Offline' affects behavior. The presence of many sibling tools is mitigated by the clear uniqueness of this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so schema coverage is effectively 100%. According to the guidelines, the baseline is 3. The description adds value by listing output fields, but this is not parameter semantics. No additional parameter information is needed, so a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Enumerate' and the resource 'Hook analyzer rule registry'. It also lists the specific fields returned (id, severity, title, category), making the purpose highly specific and distinguishable from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly suggests use when needing a list of rules, but it does not explicitly state when to use this tool over alternatives or provide any exclusion criteria. For a simple enumeration tool, this is adequate but not exemplary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. Only states 'Offline' and conversion types. No mention of error handling, multi-input behavior, or whether it returns one or all conversions. Lacks behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences, no extraneous information. Front-loaded with the verb and resources. Excellent conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple conversion tool with 3 optional params and no output schema. Description covers purpose and offline nature. Could briefly mention output behavior (returns all conversions), but overall reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%. Description names the three time types but does not clarify how to use the parameters: e.g., provide one to get the others, or any combination. Ambiguity about input-output relationship reduces value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool converts between three specific time formats (Ripple, Unix, ISO 8601), including the definition of Ripple time. Differentiates itself from sibling tools which are primarily account/transaction retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions 'Offline' indicating no network dependency, and context that Xahau uses Ripple time. Does not explicitly state when to use vs alternatives, but the conversion purpose is clear and distinct from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. States 'Offline' but lacks detail on error handling, return format, or edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words, front-loaded with action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema; description omits return value details. Adequate for simple tool but could specify what the function returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 33% (only address described). Description adds context about classic and X-address but does not explain tag or test parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it encodes/decode between classic address+tag and X-address. Specific verb+resource, distinct from siblings like validate_address.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions 'Offline' indicating no network needed, but no explicit guidance on when to use vs alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Read-only', disclosing the tool does not modify state, but does not mention authentication, rate limits, or error handling. Minimal transparency for a simple tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of one sentence that front-loads key information. Every word contributes to the purpose. It could be structured more, but it earns its place with no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (one parameter, no output schema, no nested objects), the description adequately covers purpose, scope, and read-only nature. It does not detail exact return format or examples, but it is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter 'network' with enum and default. Schema description coverage is 0%, but the description reiterates 'mainnet or testnet', matching the schema. No additional semantic detail is added beyond what the enum values provide. Baseline 3 is appropriate given low coverage but adequate compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns health, version, amendments, and ledger range of a Xahua node. It specifies the network parameter (mainnet/testnet) and explicitly labels it 'Read-only', distinguishing it from sibling tools that manipulate state or target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining node-level information but does not explicitly specify when to use this tool over alternatives or provide exclusions. Among many sibling tools, context suggests it is for server diagnostics, but guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It states 'Offline,' suggesting no side effects or network calls. However, it does not explicitly confirm the tool is read-only or purely computational, missing a chance to disclose behavioral traits beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. It efficiently conveys the tool's purpose and an important behavioral hint ('Offline').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (likely describing the returned hex), the description adequately covers input and core functionality. It explains input (list of tx types), purpose, and offline nature. A small improvement would be noting the hex format, but the output schema fills that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already provides an example for txTypes ('e.g. ["Payment","Invoke"]'). The description adds minimal semantic value beyond restating 'list of transaction types.' Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds a canonical HookOn hex from a list of transaction types. The verb 'Build' and resource 'canonical HookOn hex' are specific, and the purpose distinguishes it from sibling decode_hook_on and other encoding tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes 'Offline,' implying no network is needed, which guides when to use. However, it lacks explicit alternatives or when-not-to-use guidance. The purpose is clear enough for basic usage but could be more directive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It correctly notes the tool does not sign and is offline, but does not mention other traits like being read-only, safe, or side-effect-free. The information is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is both concise and front-loaded with the core action. Every word serves a purpose, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and minimal annotations, the description covers the basic purpose and usage context. However, it lacks details on the output format, constraints, or potential errors. It is adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% coverage for parameter descriptions. The description only states the parameter is a 'transaction JSON', which adds minimal meaning. It does not specify required fields, structure, or examples. More detail is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'encode', the input 'transaction JSON', the output 'UNSIGNED Xahau binary blob', and the usage context 'for inspection/round-trip; never signed. Offline.' This distinguishes it from sibling tools like decode_tx_blob and build_*_unsigned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states 'for inspection/round-trip; never signed. Offline.' which implies when to use (inspection, round-trip, offline) but does not explicitly mention when not to use or name alternatives. The context is clear but lacks explicit exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It discloses that results are estimates (not exact on-ledger fees), that the static instruction count is an upper-bound proxy, and that the tool operates offline. It does not mention destructive effects (none assumed) or auth requirements, but overall is transparent about its behavioral limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences covering purpose, what it outputs, and a key caveat. No wasted words, front-loaded with the verb 'Estimate'. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately describes output (byte size and static instruction count) and notes it is an estimate and offline. It covers the main purpose and limitations. Could be improved by mentioning that it returns numeric values or typical error cases, but overall is complete for a simple estimation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It mentions 'from its WASM' but does not explain the two parameters (wasmHex, wasmBase64) beyond their names. It fails to clarify that only one should be provided, or describe acceptable formats/constraints. Adds minimal value over parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it estimates cost signals (byte size and static instruction count) from a Hook's WASM. It distinguishes itself as an ESTIMATE and offline, differentiating from on-ledger fee tools. However, it does not explicitly name sibling tools like 'estimate_hook_state_cost' or 'simulate_hook_trigger' as alternatives, which would strengthen clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: it is an estimate and offline, and notes that the on-ledger execution fee depends on the actual executed path. This implies it should not be used for exact fees. However, it does not explicitly list when to use this tool versus specific sibling tools or state when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits: it runs real bytecode (not faked), records unsupported API calls with fidelity LOCAL_VM, and does not require a xahaud node. Given no annotations, this provides sufficient transparency for safe invocation, though it could mention the simulation's accuracy limits or performance characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph with a marketing introductory word 'GROUNDBREAKING', which adds minimal informational value. It conveys necessary information but could be more structured (e.g., bullet points) and remove hyperbolic language to improve conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 14 parameters, an output schema, and no annotations, the description covers the tool's purpose, inputs (simulated transaction and ledger state), and outputs (decision, return code, state writes, emitted txns, execution trace). It lacks explicit mention of parameter defaults or required fields but is sufficient for an informed agent to understand the tool's scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 57%, with some parameters like state and txType described in the schema. The tool description adds overall context (simulating transaction and ledger state) but does not explain individual parameters beyond what the schema provides. For parameters without schema descriptions (e.g., feeBase, ledgerSeq), the description offers no additional guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs real Hook WebAssembly bytecode in a local VM, simulating a transaction and ledger state, and reports the true accept/rollback decision, return code, state writes, emitted transactions, and execution trace. It distinguishes itself as the first dev-accessible Hook simulator without needing a node, setting it apart from siblings like simulate_hook_trigger.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when simulating a Hook locally without a node, but does not explicitly state when to use or avoid this tool compared to alternatives like hook_dry_run or simulate_hook_trigger. No exclusions or prerequisites are mentioned, leaving the agent to infer usage context from the tool's capabilities.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the read-only nature, history traversal (oldest-first), classification logic, and the 'honest truncation caveat'. No annotations exist, so the description carries full burden. It does not mention potential performance impact of maxPages, but overall is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with front-loaded purpose and clear sentences. It avoids redundancy but could be slightly more compact. Each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description need not detail return values. It adequately covers the tool's behavior, classification outcomes, and caveats, making it complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, with descriptions on address (r-address), network (enum), and maxPages (history pages). The description adds no new parameter-specific details beyond the schema, only explaining the tool's output logic.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Measure') and resource ('account's HNDL exposure'), with detailed explanation of classification types (master, regular, multisig, none). It distinguishes itself from sibling tools by focusing on post-quantum threat assessment rather than general account info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives (e.g., get_account_info for general data). The description implies usage for security assessment but lacks direct 'when to use' or 'when not to use' context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description labels the tool as 'Read-only,' indicating no state changes. It also describes the condition (found=false) for unresolved keys. Missing detail on what the successful response contains beyond the key itself, but the read-only safety is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four focused sentences, front-loaded with the core action. It uses precise terminology without extraneous words. Every sentence adds value: derivation logic, use case, edge case, and safety.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two parameters and no output schema, the description covers the core purpose and a key condition (found=false). However, it does not describe the return format or the effect of the network parameter. For the complexity level, it lacks full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet the description adds no details about the parameters. The account parameter is implied but not named, and the network parameter is completely omitted. The description fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool derives the master public key from the ledger using a specific method (self-originated tx pubkey matching AccountID). It distinguishes from sibling tools like get_account_info by focusing on a specific cryptographic key derivation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states a use case: 'Needed to configure a qkey_guard hook (its MPK param).' It also mentions when it returns found=false, indirectly guiding against use when the key hasn't signed. However, it lacks explicit alternative tool comparisons or when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses that the tool is read-only and explains the scoring logic in detail (e.g., Hook credited only when exact bytecode matches registered hooks). It clarifies the tool is not a safety alarm. This provides good transparency beyond the absence of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences and front-loads the core purpose. It is concise but includes necessary specifics about the scoring conditions. Slight redundancy could be trimmed (e.g., repeat of 'quantum-policy'), but overall well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description does not need to explain return values. It covers the evaluation factors and the hook condition adequately. The context is sufficient for an agent to understand when to invoke the tool and what it checks.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 50% of parameters with descriptions (address has 'r-address', network has none). The description adds no parameter-specific semantics beyond what the schema provides, failing to compensate for the low schema coverage. For example, it does not clarify the format of the address or the possible network values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool grades a Xahau account for quantum hardening readiness, listing specific factors (master-key, regular key, multi-sign, quantum-policy Hook) and output a 0-100 score with tier and recommendations. It distinguishes from generic account info tools by focusing on quantum readiness and hardening framing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for assessing quantum hardening without explicitly comparing to alternatives like 'quantum_scorecard' or 'get_account_hooks'. The note about 'framed as hardening, not a safety alarm' provides some context but no when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states the tool operates offline (non-destructive) and lists output fields. However, it does not describe behavior on invalid addresses (e.g., error handling, return format). With no annotations provided, the description carries the full burden, and this gap reduces transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that immediately states the action and output using an arrow notation. It is front-loaded and contains no redundant words, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple validation tool, the description covers the main functionality, output types, and offline nature. The presence of an output schema helps, but missing details on invalid input behavior and exact formatting rules prevent a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'address' has no schema description (0% coverage), but the tool description clarifies it accepts classic r-addresses or X-addresses, adding meaningful context beyond the schema. However, exact format constraints (length, prefix) are missing, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (validate), the resource (Xahau/XRPL address), and the expected outputs (type, account-id, embedded destination tag, network). It also specifies the offline nature and accepted address formats (classic r-address or X-address), distinguishing it from other tools in the list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, scenarios, or when not to use it. While 'offline' hints at usage without network, it lacks direct recommendations or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides useful behavioral context: it is a read-only metadata check that performs one RPC read, lists ledger object IDs and flags duplicate symptoms. It does not disclose error conditions or permissions, but given no annotations, it sufficiently conveys the tool's non-destructive nature and scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at three sentences, front-loaded with the core purpose, and avoids redundancy. Every sentence adds value: what it does, what it checks, and its limitation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and the presence of an output schema, the description is partially complete. It explains the purpose and behavior but omits parameter details and does not describe the output structure. The missing parameter descriptions leave a gap, though the schema provides some structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two parameters (txHash, network), but the description does not mention or explain them. With 0% schema coverage, the description adds no meaning beyond the schema. The txHash parameter is somewhat self-explanatory from context, but the lack of explicit description reduces clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function as a structural audit of a transaction's metadata threading, listing specific ledger object fields and flagging a specific symptom. It distinguishes itself by explicitly noting it is a metadata-only check and does not walk the full cross-ledger thread, making the purpose specific and well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for verifying double threading issues in transaction metadata but does not explicitly state when to use this tool versus alternatives like trace_transaction_stakeholders or inspect_emitted_tx. It mentions that it does not walk the full thread, giving some context but lacking clear when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: pagination via marker, 20-page cap with truncated flag, and RPC reads. It implies read-only nature but does not explicitly state safety. Overall good transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences, front-loading the action and key features. Technical details are present but not excessive. Could be slightly more structured, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of reading remarks from multiple objects and the existence of an output schema, the description covers main behaviors like pagination and decoding. However, it misses error conditions and network selection context, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description has 0% schema coverage and fails to explain the network parameter or the account parameter beyond implicit context. It references a marker concept that is not a parameter, causing potential confusion. Compensation is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads Remarks attached to an account's owned ledger objects, with hex-to-text decoding and immutable flag surfacing. It distinguishes itself from sibling tools like audit_account_hooks by focusing on Remarks and object annotations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a use case (dynamic-NFT patterns and object annotations) but does not specify when not to use or offer alternatives. The context is clear enough for an agent to infer appropriate usage given the unique purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that it does not sign, returns unsigned JSON and instructions, and defaults to testnet. No destructive or state-modifying behavior is mentioned, which is appropriate as it only assembles a transaction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that includes all critical information: what it does, output format, that it never signs, and default network. There is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers purpose and output, it lacks context on what a ClaimReward transaction is and how it relates to sibling tools like compute_reward and reward_status. No mention of prerequisites or error conditions, which is adequate but could be improved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should explain parameters. It only mentions 'testnet by default' for the network parameter, but does not explain 'issuer' or 'account'. This is insufficient given the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it assembles an unsigned ClaimReward transaction and returns unsigned JSON with offline signing instructions. It distinguishes itself from sibling 'build_*_unsigned' tools by naming the specific transaction type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives like compute_reward or reward_status. It only implies usage for building a ClaimReward transaction and notes it never signs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clearly states the tool never signs, defaults to testnet, and returns unsigned JSON and offline instructions. This provides adequate behavioral disclosure for a non-destructive assembly tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise at 2-3 sentences with front-loaded action verb. Every sentence adds value: purpose, output format, and safety caveat. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a simple assembler with no output schema, the description covers key aspects: purpose, output type, network default, and safety. However, it misses explaining the account parameter's meaning and lacks mention of required fields beyond the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (33%), and the description only adds minimal meaning for xpopBlobHex ('HEX-encoded XPOP'). The 'account' and 'network' parameters are not explained beyond default values, leaving ambiguity about their roles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool assembles an UNSIGNED Import (Burn2Mint) transaction using a HEX-encoded XPOP, returns unsigned JSON and offline instructions, and never signs. It distinguishes from sibling build tools by focusing on import transactions and unsigned nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for creating unsigned import transactions but lacks explicit when/why to use vs. alternatives. It mentions 'Never signs; testnet by default' but provides no comparison with other build_*_unsigned tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool does not sign ('Never signs'), returns unsigned JSON plus instructions and preflight, and defaults to testnet. This reveals key behavioral traits (no mutation, preflight validation, network default). It could be improved by explicitly stating it does not modify state or require special authorization, but it is still informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences containing all essential information. Front-loaded with purpose and key behavior. No extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 5 parameters, the description adequately outlines the output (unsigned JSON + offline signing instructions + payload preflight) and the default network. It could be more specific about the structure of the returned JSON or what 'preflight' entails, but it is reasonably complete for a tool among many build_*_unsigned siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (only amountDrops has a description). The description adds minimal parameter context: it states amounts are in drops (which schema already indicates) and mentions offline signing instructions, but does not explain account, destination, or destinationTag beyond schema basics. Baseline for low coverage is that description should compensate; it does not sufficiently elaborate parameter meanings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Assemble an UNSIGNED XAH Payment'), the resource (XAH Payment), and key attributes (amount in drops, returns unsigned JSON + offline signing instructions + payload preflight, never signs, testnet default). This distinguishes it from sibling tools like build_sethook_unsigned or build_claimreward_unsigned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Never signs; testnet by default,' which implies when to use (for preparing unsigned payments) but lacks explicit when-not-to-use or comparisons with alternatives. Sibling tools are not referenced, so guidance is limited to implied context from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that it reads server_info, uses a fixed endpoint (no arbitrary URLs), and performs 1 RPC read. This is sufficient transparency for a simple read operation, though it could explicitly state it is safe and non-destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. It front-loads the core purpose and adds necessary context about fixed endpoint and RPC count. Every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, return value explanation is not needed. The description covers the main output (amendment blocked, build version, ledger) and parameter. It is complete for a simple read tool with no annotations, though it could list the exact output fields for extra clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description mentions 'this network' and 'network's fixed endpoint', implying the parameter selects the network, but does not explicitly describe the 'network' parameter or its enum values. While the parameter is simple, the description adds little beyond the schema's own definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it reports whether the configured RPC node is amendment blocked, along with build version and validated ledger. It specifies the verb 'report', the resource 'RPC node', and distinct condition 'amendment blocked'. This distinguishes it from sibling tools like xahau_server_info or get_amendment_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used to check if the node is too old to process transactions, but does not explicitly state when to use it versus alternatives like xahau_server_info or get_amendment_status. It mentions it reads server_info and uses a fixed endpoint, which gives context but lacks explicit usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions '2 RPC reads,' indicating the tool performs two network calls and is likely read-only. It also notes that amendments are compared 'by name where known,' acknowledging potential gaps. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences: purpose, use case, and efficiency. No unnecessary words or redundancy. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown but indicated), the description need not detail return values. It covers purpose, use case, and number of RPC calls. Missing details like output format or edge cases are minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not elaborate on the parameters beyond the example 'mainnet vs testnet.' It does not explain the default values or behavior when both networks are the same. The schema's enum values provide the main meanings, but the description adds little.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it diffs enabled-amendment sets between two networks, listing what is enabled on one but not the other. It references specific networks (mainnet vs testnet) and explains why a transaction or Hook feature works on one network but not the other, distinguishing it from siblings like get_amendment_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a use case (explaining why a transaction/Hook feature works on one network but not the other), but does not explicitly state when to use this tool versus alternatives, nor does it mention when not to use it. The usage context is implied but not fully articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the tool performs two RPC reads and is a live decode, indicating no side effects. It does not detail authentication or rate limits, but the operational scope is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single informative paragraph, front-loaded with key purpose and includes many details without unnecessary words. It could be slightly more structured, but is efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description exhaustively lists all returned components, explains thresholds, and mentions the canonical source. It is complete for an agent to understand the tool's output and complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description does not explain the 'network' parameter beyond its enum values. It fails to add context like which network each option corresponds to or that it selects the query target.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool decodes the governance state from the genesis hook, listing specific components (seats, members, votes, tally, constants). It distinguishes itself from sibling tools like get_hook_state by specifying it is a 'FULL live decode' specifically for governance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for obtaining governance state but lacks explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives like get_hook_state for raw state.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly implies a read-only operation with 'Offline', suggesting no state modification or network dependency. Since there are no annotations, this disclosure is essential and adequately conveys the non-destructive behavior, though it doesn't detail permissions or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence (16 words) that is front-loaded with the action and key details. Every word adds value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description specifies the type of metadata returned, it lacks details on output structure or examples for the 'category', 'role', and 'hazard' fields. Given the absence of an output schema, more explanatory context would improve completeness, though the tool is simple.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with the 'name' parameter having an example list. The description adds no additional meaning beyond the schema, aligning with the baseline score of 3 when schema is already complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool looks up a Hook API function and specifies the kind of metadata returned (category, exit/guard role, security hazard metadata). It uses a specific verb-resource pair and distinguishes itself from sibling tools that deal with account hooks, transactions, or state, as this focuses on API function definitions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Offline', indicating no network call is needed, which implies usage context but doesn't explicitly state when to use this tool versus alternatives like get_hook_definition or inspect_hook_wasm. No when-not or alternative tools are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full transparency burden. It declares the tool read-only, details that it uses ledger_data (AccountRoot Flags/RegularKey/Balance) without per-account transaction scanning, clarifies that figures are network statistics, and states it is heavy, rate-limited, and paced. This fully discloses behavior and constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but slightly dense, using capitalization and phrases like 'via ledger_data (AccountRoot Flags/RegularKey/Balance)' that could be trimmed. It front-loads the main purpose effectively. Minor verbosity prevents a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the tool's output conceptually (percentages of accounts and supply) and its data source, but it fails to describe any of the four input parameters or how to use them. Given the presence of an output schema, return values are covered, but the lack of parameter guidance leaves the description incomplete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (no parameter descriptions), and the tool description does not mention any of the four parameters (delayMs, network, maxPages, pageLimit). The agent must rely solely on parameter names for meaning, which is insufficient. The description adds no value for parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a 'WHOLE-LEDGER key-rotation posture census' using ledger data, reporting percentages of accounts and XAH supply for three key-rotation categories. It distinguishes itself from hndl_exposure by specifying it measures config, not exposure, making its purpose distinct among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly contrasts with hndl_exposure ('not exposure (hndl_exposure does that)') and notes that figures are network statistics, not per-account scans. It also warns that the tool is 'HEAVY + rate-limited; paced,' guiding usage. However, it does not list alternative tools for per-account queries or provide explicit when-to-use instructions beyond the contrast.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and fully discloses safe behavior ('Never signs, never submits'), performance limitations (~1.1s per read), approximate nature of predictions (only Payment/TrustSet supported), and scam score. This exceeds expectations for transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph with excessive technical detail (e.g., hook execution order, agreement percentages). It is not concise and could be better structured with bullet points or sections. Every sentence does not earn its place; some details are too granular for a tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested objects, output schema exists), the description covers main output areas (per-hook results, simulated state writes, predictions) and complements the output schema. However, missing usage guidelines and concise structure reduce completeness slightly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (one parameter has description). The description adds that tx must be 'unsigned' and lists typical fields (TransactionType, Account), but does not elaborate on structure beyond what the schema provides. It clarifies that other transaction types are unsupported for approximate predictions, adding moderate value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a pre-sign flight simulator that predicts Xahau's behavior with an unsigned transaction, explicitly distinguishing from signing/submitting and listing specific outputs. It differentiates from siblings like simulate_hook_trigger by its scope and approximation details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage before signing to predict outcome but does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives (e.g., simulate_hook_trigger). No exclusions or tradeoffs are discussed beyond mentioning slowness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses it is unsigned, irreversible, runs an internal readiness check, fails closed, and never signs. No annotations provided, so description carries full burden and handles it well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence adds value: step context, action, irreversibility, internal check, failure condition, signing behavior. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose and preconditions well but lacks parameter explanations and expected return format (e.g., unsigned transaction blob). Adequate but has gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description does not explain the two parameters (account, network) despite 0% schema description coverage. Account is implied but not explicitly linked to the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it builds an unsigned AccountSet to disable the master key, and identifies itself as step 3 of the rotation wizard, distinguishing it from sibling build_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states irreversibility and precondition that an alternative signer must exist; implies when not to use without naming alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the preflight analysis (analyze_hook with critical flagging), the return format (unsigned JSON + offline signing instructions), and the fact it never signs. This provides adequate transparency for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly written sentences with zero waste. The first sentence captures the core action, preflight, and output; the second adds key constraints. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters (2 required, nested objects) and no output schema, the description outlines the purpose and preflight but does not explain the relationship between CreateCode and parameters, nor the exact content of the output. It is functional but leaves gaps for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 10% (only namespace is documented). The description mentions 'from CreateCode + params' but does not explain what CreateCode refers to or detail the role of parameters like wasmHex, createCodeHex, grants, etc. The agent would lack understanding of how these parameters interact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool assembles an unsigned SetHook transaction, runs analyze_hook preflight, and flags critical findings. The verb 'build' combined with 'sethook_unsigned' precisely identifies the resource and action, distinguishing it from sibling build tools for other transaction types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the tool never signs and defaults to testnet, guiding safe usage. However, it does not explicitly contrast when to use this versus other build_*_unsigned tools, though the name makes the use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must bear full burden. It notes the tool is a legacy approximation but does not elaborate on constraints, side effects, or authentication needs. For a read-only computational tool, this is acceptable but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences plus legacy and alternative notes. Every sentence adds value with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters and no output schema, the description covers the main function, input modes, and legacy status. However, it omits the output format (expected reward) and does not clarify mutual exclusivity of inputs or essential parameter combinations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description only groups parameters as 'reward fields' without explaining individual semantics. The meaning of balanceXAH, currentLedger, etc., is left to the user's assumed knowledge of the model.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool computes a reward using a documented time-weighted model, distinguishes from sibling reward_status by labeling itself as legacy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (for legacy approximation) and when to prefer reward_status instead. Also describes two input modes: direct fields or address.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds behavioral details: non-standard 160-bit codes pass through, and it works offline. However, it does not specify return format, input validation rules, or error handling, which would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. The first sentence immediately states the core function, and the second adds important edge-case behavior. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description covers conversion direction, formats, and pass-through behavior. It is missing explicit mention of the return value, but the overall context is sufficient for a simple conversion tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter 'input' is described in the schema as 'a 3-char code or a 40-hex currency', which is clear. The description adds nuance about non-standard codes passing through, enhancing understanding beyond the schema. Schema coverage is 100%, so the baseline is 3, but the extra context justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool converts between 3-char ISO codes and 160-bit/40-hex currency formats, using specific verbs ('Convert') and resources ('currency'). It also distinguishes from siblings, as no other sibling tool performs currency conversion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for currency code conversion but does not explicitly state when to use it or mention alternatives. Since no sibling tool overlaps, the lack of explicit guidance is acceptable but not ideal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'Offline' and lists input formats, but does not disclose error behavior, performance characteristics, or limitations. This is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, front-loading the verb 'Decode' and then specifying input formats. Every sentence contributes meaning without repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple input formats), single required parameter, and existence of an output schema, the description covers the essential input-output mapping. It could mention typical use cases or error handling, but is largely complete for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds significant value by specifying byte sizes (8-byte native, 48-byte issued) and the structure of the issued amount object {currency,issuer,value}, which goes beyond the schema's generic 'drops string, STAmount hex, or amount object'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: decoding amounts from native drops, serialized hex, or issued amount objects into normalized values. It specifies the resource (amount) and action (decode), and differentiates itself from sibling tools by its specific input types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for offline decoding of amounts but does not explicitly state when to use this tool over alternatives or when not to use it. No comparisons to sibling decode tools are provided, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must fully disclose behavior. It mentions 'Offline' indicating no network calls, and lists what differences are detected. However, it does not specify any destructive effects, authentication requirements, or return format beyond implied output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with core purpose, every word adds value. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Provides a comprehensive overview of what the tool compares. With an output schema present (not shown but stated), it is not required to detail return values. The description covers the essential aspects for an offline comparison tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 6 parameters with 0% description coverage. The description names aspects (imports/exports, HookOn, etc.) but does not explicitly map them to parameters. It partially compensates for missing schema descriptions but still leaves ambiguity about which parameter corresponds to which aspect.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it compares two Hook versions and lists specific differences (imports/exports, HookOn changes, size/instruction deltas, security-sensitive capabilities). This verb+resource combination distinguishes it from sibling tools like simulate_hook_trigger or execute_hook.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for comparing hook versions before/after an upgrade. It does not explicitly state when not to use or name alternatives, but the purpose is clear and unique among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that the tool is a read operation (no side effects), accesses the Amendments singleton, requires no admin privileges, and costs 1 RPC call. This is transparent about resource usage and access requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, starting with the core purpose, then details, then cost/resource info. It is efficient and front-loaded. One minor issue: the first sentence is a bit cryptic ('Project when amendments now holding majority will enable') but still understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (not shown but context indicates), the description doesn't need to cover return values. It adequately explains the purpose, input (though parameter not described), methodology, and constraints. It is complete for a small, focused prediction tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'network' has an enum of 'mainnet' and 'testnet' but the description adds no explanation of its meaning or impact. With 0% schema description coverage, the description should have explained that the parameter selects the network to query. The schema alone shows the enum, but the description does not add value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Project when amendments now holding majority will enable.' It specifies key details like >80% support, 5-day Xahau window, and seconds/days remaining. This differentiates it from sibling tools like get_amendment_status or check_amendment_blocked, which focus on current status rather than future prediction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context: 'Reads the Amendments singleton — no admin node needed. 1 RPC read.' This implies it's a lightweight, non-admin read operation. However, it does not explicitly state when to use this tool versus alternatives like get_amendment_status, so usage boundaries are implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that it performs a single RPC read, explains the effect of the Touch amendment, and describes the return structure. This is informative, though rate limits or errors are not mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no waste. It is front-loaded with the core purpose and immediately provides additional important context. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists (from context signals), the description does not need to detail return values, but it does summarize them. The tool is sufficiently explained for an agent to understand its purpose, behavior, and output without ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to the parameters (txHash, network). It does not explain what txHash represents or the network options, so the description fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool lists every account a transaction touched, derived from metadata (AffectedNodes), and positions it as the authoritative participant list. This is distinct from sibling tools like get_transaction or simulate_transaction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly advises using this over guesses from tx fields, but does not explicitly state when not to use it or compare to alternatives. It provides good context but could be more direct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and discloses key traits: returns unsigned JSON + preflight, never signs, defaults to testnet, and mentions DeepFreeze amendment requirement. This adds value beyond the schema, though could mention the tool only assembles and does not submit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences that front-load the main purpose and efficiently cover key behaviors (unsigned, never signs, testnet default). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters, no annotations, and no output schema, the description is adequate but leaves gaps. It does not explain what 'preflight' means, nor does it mention prerequisites like needing an existing trustline. Return format details are minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the schema by explaining the 'action' parameter's four possible values and their effects, and noting the 'network' default. However, other parameters (account, counterparty, currency, limitValue) are already adequately described in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool assembles an unsigned TrustSet to toggle a freeze on a trustline, using a specific verb 'assemble' and resource. It distinguishes itself from sibling build_*_unsigned tools by specifying the freeze action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for assembling freeze transactions, listing action types. However, it does not explicitly state when to use this tool versus alternatives or when not to use it. No sibling comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully responsible. Declares 'Read-only', signaling no mutation. Explains what it checks and returns. However, does not explicitly state it does not modify state beyond 'Read-only', which is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and context. Minor jargon ('ROTATION WIZARD gate') but not excessive. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so return values are described (safeToDisable, proven, reasons). Tool purpose, prerequisite, and read-only nature covered. Missing parameter documentation for network and lack of return structure details limit completeness. Adequate for a pre-check tool but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. Description mentions 'this account's master key' implying the 'account' parameter, but never explicitly describes it or 'network'. The network parameter with enum (mainnet/testnet) is completely unaddressed. Agent may infer account but not network.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: checking safety of disabling master key by verifying alternative signer existence. It specifies the checks (regular key signed, signer list exists) and return values (safeToDisable, proven, reasons). Distinguishes from sibling build_disable_master_unsigned by saying 'Run this BEFORE'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Run this BEFORE build_disable_master_unsigned', providing clear ordering relative to a sibling tool. Also labels it a 'ROTATION WIZARD gate', implying it's a prerequisite check.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses the tool's behavior: it is read-only and returns the current fee including base and load/queue state. No contradictions exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, including all essential information: what the fee is, its composition, use case, and read-only flag.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the purpose, content, and read-only nature. However, it does not specify the return value format (e.g., number of drops as string or number). Given the tool's simplicity, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the tool description does not mention the 'network' parameter at all. The agent must rely solely on the schema, which is clear but the description adds no value for parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the current network transaction fee, specifying it includes base fee in drops plus load/queue state. It explicitly states the intended use ('for building a tx with the right Fee') and marks it as read-only. This distinguishes it from sibling tools like estimate_hook_fee.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context ('for building a tx with the right Fee'), indicating when to use the tool. However, it does not explicitly mention when not to use it or mention alternatives, so it lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses that this is a read operation ('1 RPC read') and describes the output structure (decoded fields, raw object). No side effects or auth requirements are mentioned, but for a read tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the action, and includes all essential information without fluff. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains what is returned (decoded fields, raw object) and mentions cost ('1 RPC read'). It lacks details on pagination or result ordering, but for a list tool this is reasonably complete given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 2 parameters (account, network) with 0% description coverage. The description only implicitly refers to 'account' but does not explain the network parameter or its default. Given low coverage, the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists an account's Cron ledger objects (scheduled Hook self-invocations) and specifies the decoded fields provided. It distinguishes from siblings like build_cronset_unsigned and monitor_cron_health by focusing on listing rather than building or monitoring.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates this is a read operation ('1 RPC read') and states it lists cron job objects for an account. It does not explicitly exclude alternatives, but the purpose is clear enough that an agent should know when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses that it returns unsigned JSON and signing instructions, and never touches secrets. It doesn't detail side effects, but the non-destructive nature is implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a short post-instruction, front-loaded with the key purpose. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, it sufficiently describes the return value and provides follow-up guidance. It covers the essential aspects for a build tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description clarifies the 'regularKey' parameter (omit to remove), compensating for the schema's 33% coverage. However, 'account' and 'network' lack explanatory context beyond schema defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'assemble an UNSIGNED SetRegularKey' to assign or remove a regular key, and the context of 'ROTATION WIZARD step 1' distinguishes it from sibling build_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context as the first step in key rotation, advises to never touch secrets, and recommends a test transaction after. It does not explicitly list when not to use, but the purpose is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses it is offline and verified against canonical implementation, implying safety and determinism. No annotations exist, so description carries the burden well. Could mention error handling but reasonable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences cover purpose, inputs, and verification. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Describes inputs and outputs adequately given single parameter and no output schema. Could specify return structure (object vs list) but fields are listed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already describes parameter fully (100% coverage). Description adds no new parameter-level meaning beyond restating acceptable formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool decodes an Evernode lease URIToken URI and lists the exact output fields (lease index, amount, etc.), distinguishing it from siblings like decode_uritoken_id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions acceptable input formats (hex, base64, raw buffer) and that it operates offline. No explicit contrast with alternatives, but the specificity makes usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses static-only behavior ('Labelled STATIC_ONLY', 'Offline', 'Quick STATIC check'). It does not detail side effects (likely none) but could clarify what 'exit calls' means.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no waste. Key information (static, offline, purpose, sibling reference) is front-loaded. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema; description omits return format (e.g., what the exit call list looks like). With many sibling inspection tools (inspect_hook_wasm, analyze_hook), broader usage guidance is missing. Output clarity and tool differentiation are insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 25% (only candidateTxType described). The description adds minimal parameter meaning ('HookOn match' implies hookOn relates to hook trigger conditions, but no details on wasmHex/wasmBase64 or hookOn format). Fails to compensate for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('check') and resource ('hook firing and exit calls in WASM'). It explicitly distinguishes from execute_hook, making the static vs. dynamic contrast obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use ('Quick STATIC check') and when-not-to-use ('For REAL bytecode execution use execute_hook'), naming the alternative tool directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It discloses the cost ('1 RPC read') and return type ('alerts + healthy flag'), but does not cover error cases or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words: first states purpose, second describes output and cost. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple health check with low parameter complexity and no output schema, the description covers the essential return information and threshold. Could be more detailed on alert format or error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description explains the lowThreshold parameter (default 8) and implies the account parameter. The network parameter is not described, but its enum values are clear from schema. Adds value beyond the 33% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool checks Crons for exhaustion with a specific threshold, distinguishing it from siblings like list_cron_jobs. Mentions the purpose to prevent silent stoppage of recurring hooks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes when to use (check for nearing exhaustion) and the context (recurring hooks), but does not explicitly mention when not to use or provide alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the tool is 'Offline' and generates a 'structurally valid' hook with build instructions, indicating no ledger modifications. It does not disclose return format or error handling, but these are reasonable for a scaffold generator.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the core purpose and usage flow. Every word adds value ('structurally valid', 'A STARTING POINT', 'Offline'). No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers purpose, usage sequence, and offline nature. For a simple scaffold tool with no output schema, it provides most needed context. Missing is explicit mention of output format (e.g., returns C code as string), but it's implied by 'generate ... with build instructions'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists the archetype enum values but does not explain each intent beyond naming. Schema descriptions cover maxDrops and blockTxType, but archetype lacks a schema description. The description adds minimal extra meaning, leaving interpretation of archetypes to the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a starter Xahau Hook in C for a specific intent, listing all valid archetypes. It explicitly distinguishes itself from analysis/execution tools by calling itself a 'STARTING POINT'. The verb 'Generate' and resource 'starter Hook' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using the scaffold as a starting point, then verifying with analyze_hook/execute_hook before deploying. It implies when to use (first step in hook creation) and mentions the offline nature, but does not explicitly exclude other scenarios or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the tool is 'Offline' (no network calls) and accepts both number and string inputs. It does not mention potential errors or limits, but for a simple mapping, this is sufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and examples. Every word adds value with no redundancy or extraneous information. It is optimally concise for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should clarify the return format. The '⇄ its name' hint suggests bidirectionality but does not explicitly state what the tool returns (e.g., the corresponding name or number). For a tool with minimal parameters and no output schema, this omission leaves some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter 'result' is described in the schema as 'a result code number or name'. The description adds concrete examples (e.g., '0/tesSUCCESS'), which clarify the expected format beyond the schema's minimal description. This provides practical guidance for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool decodes transaction engine result codes between numbers and names, with specific examples like '0/tesSUCCESS'. This distinguishes it from sibling decode tools such as decode_hook_can_emit and decode_tx_blob, which handle different domains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description marks the tool as 'Offline', implying it is a safe, instantaneous lookup with no network cost. It does not explicitly state when to use it versus alternatives, but the tool's specific domain (transaction result codes) makes the distinction implicit among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It clearly states the tool decodes (a read-only, offline operation), specifies inputs and outputs in detail (source ledger header, decoded BURN transaction, UNL validator set), and indicates it is offline. It does not cover error scenarios but is transparent about the core behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each carrying essential information: purpose, accepted input formats, and output components. It is front-loaded with the core action and resource, with no extraneous or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (single parameter, straightforward decode) and the existence of an output schema, the description adequately covers what the tool does, what it accepts, and what it returns. The mention of 'Offline' is a helpful contextual signal. No additional information is needed for an agent to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides a description for the single parameter 'xpop' (string or object), but the tool description adds context: it explains the relationship between the hex and JSON formats and identifies the XPOP as the proof blob. This additional semantic information helps the agent understand the parameter's nature beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose: decoding an XPOP (Xahau Proof of Payment) blob from Import/Burn2Mint transactions. It specifies the unique resource ('XPOP') and action ('decode'), distinguishing it from sibling tools like decode_tx_blob or decode_b2m.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have an XPOP blob ('Accepts the Import Blob hex... or the XPOP JSON'), but it does not provide explicit when-not to use or contrast with similar decode tools among siblings. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden of behavioral disclosure. It explicitly states the tool is read-only ('never signs/submits'), describes rate-limiting behavior (serial RPC calls with >=1100ms intervals, tolerant of 'Rate limited' responses), and explains the semantics of 'agree' being null in degraded scenarios. This is comprehensive and leaves no ambiguity about 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively long but each sentence serves a purpose: explaining the core workflow, the comparison logic, the meaning of null, read-only nature, and rate limits. It is front-loaded with the main action ('POST-MORTEM a real Xahau transaction's hooks') and then layers details. While it could be slightly more concise, it remains well-organized and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains what the tool returns: a comparison of on-chain and VM directions, with 'agree' null in specific cases. It covers all behavioral aspects (rate limiting, read-only) and parameter constraints. For a tool with two simple parameters and a focused use case, the description is complete and leaves no major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two parameters: txHash (required, with a minimal description already) and network (enum with default). The tool description does not elaborate on these parameters beyond what the schema provides. Schema description coverage is 50% (only txHash has a description in the schema), and the tool description adds no additional guidance on how to use them (e.g., format or validation hints). Thus, the description adds little value to parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to post-mortem a Xahau transaction's hooks by fetching the transaction, running each hook's bytecode through a local VM, and comparing VM results with on-chain decisions. It uses specific verbs ('POST-MORTEM', 'fetch', 'run', 'compare') and explicitly distinguishes itself by describing its unique functionality. None of the sibling tools have similar descriptions, so differentiation is inherent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool answers ('why did these hooks accept/rollback, and would the VM agree?') and provides context on when it is appropriate: for post-mortem analysis of hooks execution. It also mentions limitations (VM run is best-effort, on-chain is authoritative) and notes that 'agree' is null in degraded cases. However, it does not explicitly state when not to use this tool or suggest alternatives, but the domain is narrow enough that this is acceptable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states the tool is 'Read-only', performs '3 serial RPC reads', and returns 'an unsigned opt-in or claim ClaimReward when applicable'. It also details the calculation formula, providing full transparency despite no annotations being present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is informative but somewhat verbose with phrases like 'Balance Adjustment doctor' and 'EXACT genesis reward-hook formula'. Essential information is front-loaded, but it could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all essential aspects: what the tool does, the information it provides, its read-only nature, the number of RPC calls, and what it returns. Since an output schema exists, the absence of specific return field details is not a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 50% description coverage, with basic descriptions for 'address' and 'network'. The tool description does not add parameter-specific details beyond the schema, but the context (account address and network) is clear from the tool's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: checking reward status for Xahau accounts, including opt-in status, accrued amount, claim timing, and overdue status. It distinguishes itself from siblings like 'compute_reward' by offering a comprehensive 'full answer' including unsigned transaction generation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates this tool is 'the full answer' for retail reward queries, implying it should be the primary tool for such needs. It mentions 'Read-only' and '3 serial RPC reads' but does not explicitly list when not to use it or provide alternative tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the offline nature and the conversion rate. Since no annotations are provided, the description carries full burden. No side effects or errors are mentioned, but for a local conversion, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The purpose and key detail (conversion rate) are front-loaded. Extremely concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with 2 parameters and no output schema. The description covers the conversion purpose, the conversion factor, and offline nature. No gaps for this specific tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description does not explicitly describe parameters. However, the schema provides an enum for 'from' and required fields, which are self-explanatory. The description adds the conversion context but no additional parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool converts between XAH and drops with the conversion rate. It distinguishes itself from sibling tools, which are various Xahau utilities unrelated to unit conversion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage context: use when needing to convert XAH to drops or vice versa. It explicitly says 'Offline', indicating no network call is needed. No alternatives are listed, but given the tool's simplicity, this is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: returns unsigned JSON + preflight, does not sign, uses testnet by default, and notes prerequisite. With no annotations, description carries full burden and handles it well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact sentences plus note, front-loaded with purpose, no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers input requirements, return format, prerequisites, and limitations. Lacks error handling or edge cases but sufficient for a transaction builder.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description clarifies key parameter roles (account = issuer, holder = target) beyond schema, and notes currency limitation. Schema coverage 80%, description adds value for the two key parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly identifies the tool as assembling an unsigned clawback transaction, specifying the issuer and holder roles, and distinguishes from sibling builders like build_payment_unsigned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Specifies prerequisite (clawback enabled), limitation (cannot claw native XAH), and behavior (never signs, testnet default). Lacks explicit alternatives but provides clear context for when to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: the tool never signs, defaults to testnet, returns unsigned JSON + preflight. It explains parameter ranges (repeatCount 0–256) and the meaning of startTime/startInSeconds. Given no annotations, this provides adequate transparency, though error handling is not covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise at 4 sentences, front-loads the main purpose, and every sentence adds value. No redundancy or unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the main aspects: purpose, key parameters, return type, default network, and prerequisite. However, the return description ('unsigned JSON + preflight') is slightly vague, and more detail on output structure would improve completeness for a tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds significant meaning beyond the input schema: explains startTime as Ripple-epoch seconds, startInSeconds as convenience for now+N, and clarifies that omit repeatCount for one-off. Compensates for schema parameters (like delaySeconds) that lack descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Assemble an UNSIGNED CronSet — schedule a Hook's future self-invocations.' It uses a specific verb ('assemble') and resource ('CronSet'), and distinguishes from sibling tools like build_sethook_unsigned by focusing on cron scheduling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for use, such as the prerequisite ('account must have a Hook installed') and the cancel functionality ('set cancel:true for tfCronUnset'). However, it does not explicitly contrast with alternatives or specify when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It details the inverted/active-low encoding and active-high SetHook bit handling, and states it is offline. It lacks explicit safety or auth notes but covers key behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no superfluous words. Every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, the description does not need to explain return values. It provides sufficient encoding context for a decoding tool, making it complete for the intended use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter hookOn is described in the schema as 'HookOn hex (up to 64 chars)'. The tool description adds crucial context: it is a 256-bit bitmap with inverted encoding, going beyond the schema's minimal description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: decoding a HookOn 256-bit bitmap into transaction types. It includes specifics about encoding and offline operation, distinguishing it from siblings like encode_hook_on.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Offline' to imply no network needed, but does not explicitly state when to use this tool versus alternatives like decode_hook_can_emit or encode_hook_on. No when-not guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it's a read-only RPC call that decodes chain data without re-execution. It explains what it decodes (failure codes, rollback strings, partial payments) and what it doesn't (no replay). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-structured, starting with the core question and then listing features. Every sentence adds value, though it could be slightly trimmed without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of diagnosing failed transactions and the presence of an output schema, the description comprehensively covers all aspects: failure codes, rollback decoding, partial payment trap, and not-found triage. No missing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% with basic descriptions for both params. The description does not add new semantic detail beyond the schema, but the schema already provides adequate info (txHash required, network enum with default).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: providing plain-English diagnosis for failed transactions using on-chain facts. It lists specific features (decoding hook rollbacks, partial payment trap, not-found triage) and distinguishes itself from sibling 'hook_execution_postmortem'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (when a transaction fails or has issues) and explicitly says not to use for re-execution, directing to a sibling tool. However, it could be more explicit about exclusions (e.g., for very new transactions).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It clearly states the tool is read-only and explicitly warns that it performs ~9 serial RPC reads, making it slow but thorough. This exceeds typical transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph of moderate length, front-loading the purpose. It is dense but not verbose, though it could be slightly more structured (e.g., bullet points) for easier scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of an output schema, the description adequately covers the checks performed, read-only nature, and performance characteristics. No gaps are apparent for the intended troubleshooting use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two parameters, but only 'address' has a description ('host r-address'). Schema description coverage is 50%, and the description adds no additional parameter details beyond what is in the schema, so it does not compensate for the missing schema description for 'network'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the tool as a 'one-call health check for an Evernode host' and enumerates specific checks (registration, heartbeat, instance load, etc.), making it distinct from sibling tools which focus on accounts, hooks, transactions, or other features.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for host troubleshooting and mentions read-only behavior, but does not explicitly state when not to use or provide alternatives. Among siblings, it is uniquely positioned for host diagnostics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It discloses the non-execution safety guarantee and lists what the tool inspects. Lacks details on error handling or side effects, but the safety assertion is key.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. Front-loads purpose and enumerates outputs efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description should hint at return structure. It lists key outputs (imports, exports, memory, etc.) but doesn't specify format. Still adequate for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must explain parameters. It clarifies that wasmHex and wasmBase64 are hex or base64 encoded CreateCode WASM, adding meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'Parse' and specific resource 'Hook's CreateCode WASM'. Lists extracted elements (imports, exports, memory, etc.) and emphasizes offline safety, distinguishing from execution-oriented siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'never executes the module', alerting agents to safe, read-only usage. However, does not explicitly contrast with alternative tools like execute_hook or simulate_hook_trigger.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explicitly states read-only behavior, never signs or submits, and defaults to testnet. It warns about potential mainnet account issues. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the main action. Somewhat dense but still clear. Could be slightly more structured, but no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Missing description of return value (modified transaction JSON) and error cases beyond actNotFound warning. No output schema, so description should cover that. Overall adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (33%), but description explains the tx parameter (must include Account + TransactionType), the network parameter (default testnet, use mainnet for mainnet accounts), and lastLedgerOffset implied in 'now + offset'. Adds significant meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it autofills an unsigned transaction with live network values (Sequence, Fee, LastLedgerSequence, NetworkID) for offline signing. It distinguishes itself from sibling tools like build_payment_unsigned by being a read-only preparation step, not a tx builder or signer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells when to use (to prepare tx for offline signing) and provides network selection guidance. It does not explicitly exclude alternatives, but the sibling list implies other tools for building or simulating transactions. The warning about mainnet vs testnet is helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavioral traits: read-only, heavy RPC usage, sampling methodology, and output details (exposure breakdown, balance-at-risk).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Packed with useful information, front-loaded with purpose and scope. Could reduce wordiness slightly, but every sentence contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 6 parameters and an output schema, the description explains high-level outputs (exposure classes, grade tiers) and usage context (sample vs census, heavy RPC). Output schema exists, so return format is covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 17% (only accounts described). The description mentions cap, network, accounts, markdown, maxPages, sampleLedgers but adds minimal semantics beyond their names. Some context (e.g., markdown for public report) is helpful, but incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it's a 'Network-level Quantum Readiness Scorecard' aggregating HNDL exposure and config grade, clearly distinguishing it from sibling tools like hndl_exposure and quantum_grade which focus on individual components.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: operates on a sample, not a ledger census, and notes sampling bias. Does not explicitly state when not to use or name alternative tools, but the limitations are well-communicated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral details: it loads a corpus, runs bytecode, compares direction, computes agreement only over comparable runs, excludes degraded runs, states it is strictly offline, and handles empty corpus. This is comprehensive given no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly concise given the complexity, with a clear structure: purpose, method, calculation details, and caveats. It could be slightly tighter but remains effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all necessary aspects: what it does, how it works, edge cases (empty corpus), and the metric calculation. An output schema exists, so no need to detail return values. It is complete for decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'includeMismatches' is already described in the schema. The description adds no additional meaning beyond what the schema provides. With 100% schema coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose: measuring fidelity of the local Hook VM against on-chain results. It uses specific verbs like 'measures how faithfully... reproduces' and distinguishes it from sibling tools by focusing on a specific metric.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does and how it works, providing enough context for when to use it. However, it does not explicitly state when not to use it or reference alternatives among the many sibling tools, which would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description thoroughly discloses behavioral traits: decoding rules by byte-width, confidence levels ('definite' only for canonical XFL), that raw hex is always preserved, and that it is fully offline with no network calls. This is exceptionally transparent, especially since no annotations are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but well-structured, starting with the overall purpose and then detailing decoding rules. While slightly lengthy, each sentence adds value and the information is logically organized. It could be slightly tightened without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a single parameter and no output schema, the description fully explains what the tool does, how it processes the input, and what the output will contain (e.g., decoded values with confidence). It covers all necessary behavioral aspects for an agent to correctly invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds crucial semantic detail beyond the schema: it explains that each trace element is 'label: HEXVALUE', how each byte-width is interpreted (XFL float, int64, UInt32, Ripple-epoch date, account-id to r-address, tx/hook hash, raw blob), and that confidence varies. This is far more informative than the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool annotates the trace[] array from an execute_hook result, specifying its purpose of decoding hex blobs into human-readable formats. It uses a specific verb (annotate) and resource (hook trace), and is distinct from sibling tools which are about different aspects of Xahau.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool should be used after execute_hook to decode trace output, but it does not explicitly state when to use it versus alternatives or when not to use it. No exclusions or alternative tools are mentioned, leaving usage guidance implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: auto-creating missing trustlines, paying token reserves, creating destination account if absent, all-or-nothing execution, and returning unsigned JSON + preflight + offline signing instructions. It also clarifies it never signs and defaults to testnet.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph that conveys essential information without excessive verbosity. While it could benefit from bullet points for readability, it is efficient and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, nested objects, no output schema), the description covers key aspects: purpose, behaviors, return type, and default network. It does not cover error scenarios or limits, but it provides sufficient context for an AI agent to understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 60%, so the description adds value by explaining high-level behavior (e.g., 'Optionally Inform a third-party hook' for the 'inform' parameter). It does not detail every parameter but provides context that supplements the schema. For example, it explains that amounts can be native or issued tokens.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: assembling an unsigned Remit (XLS-55) for Xahau's atomic multi-asset push payment. It specifies the actions: sending multiple currencies, transferring URITokens, minting new URITokens, all in a single all-or-nothing transaction. This distinguishes it from sibling tools like build_payment_unsigned, which handles simpler payments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you need atomic multi-asset push payments with auto trustlines and account creation. It explicitly states it does not support partial payments or pathing, guiding users away from those use cases. However, it does not directly compare to alternatives like build_payment_unsigned, which could be clearer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the tool decodes offline (no network call) and produces transaction plus a summary and specific safety warnings (SetHook, AccountDelete, key changes, no-expiry, already-signed). In absence of annotations, this sufficiently conveys behavior without contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence that conveys the core action, input types, output components, and safety context. No extraneous words; every phrase serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists (not shown but noted), the description explains the return value (transaction + summary + warnings). The two parameters are adequately addressed. The tool's role among 80+ siblings is clear due to its unique focus on sign request decoding with safety warnings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates by referencing the two parameters: txjson as 'Xaman/Xumm payload's txjson' and txBlobHex as 'raw tx_blob hex'. This adds meaning beyond the schema's empty property descriptions. While it doesn't detail formats, it gives enough context for correct use.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool decodes a sign request (specific resource: Xaman/Xumm payload or raw tx_blob) into a transaction and a plain-English summary with safety warnings. It distinguishes from siblings like decode_tx_blob and decode_sethook by emphasizing the sign request context and the human-readable output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises 'Offline — understand before you sign', indicating when to use it. While it doesn't explicitly exclude alternatives, the safety focus implies it should be used before signing. This provides clear context, though a note about when to use the simpler decode_tx_blob instead would improve score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It states computation is offline, returns per-entry capacity, reserve units, overflow warnings, and minimum scale. It does not mention if any network calls are made, but 'offline' implies local computation. Good but could explicitly note no side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences with no waste. First sentence states purpose, second and third explain outputs, fourth gives implementation tip. Front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Describes return values (capacity, units, warnings, min scale) adequately without output schema. However, lacks explicit return structure (e.g., object fields), but enough for an AI to infer usage. Sibling tools provide contrast.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description adds meaning for all 3 parameters: explains 'scale' range (1–16), 'entries' as objects with valueBytes (size in bytes), and 'ownerReserveIncrementXah' for optional XAH conversion. This goes beyond the schema, which only describes one parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it computes owner-reserve cost of Hook State entries under ExtendedHookState, using specific verb 'Compute' and resource 'owner-reserve cost'. It distinguishes from sibling tools like 'estimate_hook_fee' by focusing on state entries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance on when to use: given value size and scale, returns cost info. Also specifies optional parameter to get XAH figure. However, no explicit when-not-to-use or alternatives are mentioned beyond the tool's scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses read-only nature and precise RPC behavior (5 serial reads spaced ≥1100ms apart), plus lists all the data categories fetched, giving agents clear expectations of cost and time.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence front-loads purpose, then bullet-like list of contents, followed by behavioral notes. No fluff, every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with no output schema, description comprehensively lists all return fields (balance, key safety, hooks, trustlines, URITokens, activity, warnings) and notes read-only behavior. Adequate for an agent to understand output and side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% – 'address' is described as 'r-address' in schema and 'network' has enum default. The description does not add further parameter details beyond what's in schema, missing opportunity to clarify format or validation, but the tool's purpose implies the address parameter is the target account.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it provides a plain-English account snapshot enumerating specific components (balance, key safety, hooks, trustlines, URITokens, activity) and distinguishes from numerous sibling tools like get_account_info or get_account_objects by emphasizing the one-call comprehensive overview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes usage context as a 'one-call' snapshot for human-readable overview and notes it is read-only with exact RPC count and spacing, implying a trade-off between comprehensive data and speed. However, does not explicitly state when to use vs alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses outputs: tx JSON, plain-English summary, danger score. Mentions non-destructive offline nature. With no annotations, description fully carries burden and provides clear behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Front-loaded with core action and output, then context. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, description covers return values sufficiently. Single parameter is well-documented. Tool is simple and description is complete for its purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description of 'emitted'. Description reinforces it but does not add significant new meaning beyond schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description specifies verb 'decode' and resource 'emitted blob hex(es) from an execute_hook result'. It clearly distinguishes from sibling decode tools by focusing on hook emit output, not general transaction blobs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
States it is used after execute_hook ('Closes the loop on emitter hooks') and is 'Offline', giving clear context. However, it does not explicitly mention when not to use or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the tool is a pure decode operation, offline, and only for present values. Adds context about encoding but lacks explicit statement of no side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, each adding value: purpose, usage note, and offline status. No waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity and good schema, description covers input and key behavior. Could briefly mention output type (set of transaction types) but acceptable as is.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% but description adds meaning: explains it's a 256-bit bitmap and encoding similarity to HookOn, going beyond the hex string description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool decodes a HookCanEmit bitmap into transaction types, and distinguishes it from siblings like decode_hook_on and encode_hook_can_emit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: use when the field is present; when absent, decoding is unnecessary. Also notes offline operation and encoding similarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description provides extensive behavioral details: determinism (no randomness/clock), reporting of counts, boundary findings, sample inputs, and honest handling of degraded/halted runs (excluded, inconclusive if all fail). This fully compensates for missing annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph that front-loads the core purpose and efficiently covers axes, reporting, and honesty. Every sentence adds value with no repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the tool's behavior, inputs, and outputs (counts, boundaries, sample inputs) thoroughly given the complexity. However, it does not detail all 18 parameters (e.g., state, feeBase, ledgerSeq), which are left to the schema. The overall completeness is high but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, and the description adds meaning by explaining the axes (e.g., txType, amount range, account/destination ids) and their roles. It clarifies the purpose of parameters like amountMin/amountMax and mentions wasmHex/wasmBase64 for bytecode. However, some parameters (state, feeBase, otxnFields) remain unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is a 'DIFFERENTIAL FUZZER' for finding a Hook's decision boundary by running real bytecode with deterministic inputs. It specifies the resource (Hook) and action (fuzz to find boundaries), and the detailed axes distinguish it from sibling tools like simulate_hook_trigger.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description outlines when to use the tool (for fuzzing hooks to find decision boundaries) but does not explicitly mention when not to use it or suggest alternatives. The context is clear, but no exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: offline, read-only, risk assessment only, per-rule findings, and the honest caveat that it does not detect confirmed scams. It lists specific patterns it checks (SetHook, AccountDelete, etc.) and explains the output structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph that covers purpose, outputs, rules, and caveats. It front-loads the main verb and resource, but could be more structured (e.g., bullet points) for easier scanning. Every sentence adds value, but it is slightly long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description thoroughly details the return format (dangerScore 0-100, SAFE/CAUTION/DANGER tier, verdict, per-rule findings). It lists the rules checked and explains tool limitations, making it complete for an agent to understand what the tool returns and its constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds full meaning: it explains both parameters ('txjson' and 'txBlobHex') as alternative inputs for the sign request. The description clarifies that txjson is an object and txBlobHex is a hex string, compensating entirely for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Score a sign request (txjson or raw tx_blob hex) for risky patterns BEFORE signing.' It specifies the outputs (dangerScore, tier, verdict, per-rule findings) and distinguishes from sibling tools by focusing on scam risk assessment pre-signing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'BEFORE signing' and 'Offline + read-only.' It clarifies that findings are potential risks, not confirmed scams, and that the tool does not consult block lists or verify on-chain addresses. This provides clear context on when and how to use the tool, though it lacks explicit 'when not to use' or alternative tool recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses that it is static, offline, uses no bytecode, no ledger reads, and returns roles (strong/weak) and partial flags. Lacks explicit mention of non-mutative nature but it's implicit; still very transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that immediately convey the core functionality and usage. Every sentence adds crucial information—no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a static prediction tool with one parameter and no output schema, the description is complete: it explains what it does, when to use the alternative, and flags limitations (partial flag). No additional context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (tx described), and the description adds value by specifying minimum required fields (TransactionType + Account) and that it works without ledger read. This goes beyond the schema's generic description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool statically predicts hook invocations from transaction fields without bytecode execution, clearly distinguishing it from simulate_transaction. The verb 'predict' and resource 'accounts' hooks' make the purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: use simulate_transaction for full prediction with bytecode, and notes that for some tx types a partial flag is returned. This helps the agent choose correctly among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description fully discloses behavior: fetches a transaction, applies overrides, runs simulation at the historical ledger with hooks and state as they were, and is read-only. No contradictions or hidden effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with 'TIME MACHINE', and packs the essential idea into two clear sentences without extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema and the simplicity of input parameters, the description covers the necessary context: what it does, how overrides work, and that it operates on a historical ledger. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds value beyond the schema by explaining the override object with examples (Amount, Destination). While the schema covers 2 out of 3 parameters, the description clarifies the overall flow and intent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs a counterfactual replay of a real historical transaction on its original ledger. It distinguishes from siblings like simulate_hook_trigger or simulate_transaction by specifying the historical context and read-only nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It notes the tool is read-only and nothing is signed, which guides usage. However, it doesn't explicitly state when to use this versus similar simulation tools, nor does it list prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavioral traits: constraints (max 32, unique names, byte limits), cost (+1 drop/byte), encoding (hex vs UTF-8), return value (unsigned JSON + preflight), and side effects (no signing). It also clarifies ownership requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two dense sentences covering the core purpose, constraints, and return. Both sentences earn their place without redundancy. Front-loaded with the main verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of building a transaction with nested remarks, the description is complete: it specifies inputs, constraints, output format, and safety note (no signing). No output schema exists, but the description covers return value. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite low schema coverage (25%), the description adds significant meaning: it explains the remarks structure (name required, value omitted for delete, immutable flag), the hex encoding, and the purpose of each parameter (account as owner, objectId as target). This complements the schema well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (assemble/build unsigned), the resource (SetRemarks transaction), and the specific actions (attach, update, delete key-value remarks). It distinguishes from sibling build tools by specifying the transaction type and its purpose, such as powering dynamic NFTs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool (for remark management on owned objects or issued tokens) and notes that it never signs and defaults to testnet. However, it does not explicitly list alternatives or state when not to use it, though the sibling tools cover different transaction types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![xahau-mcp MCP server](https://glama.ai/mcp/servers/Hugegreencandle/xahau-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Hugegreencandle/xahau-mcp)

Score Badge

Copy to your README.md:

[![xahau-mcp MCP server](https://glama.ai/mcp/servers/Hugegreencandle/xahau-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Hugegreencandle/xahau-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/Hugegreencandle/xahau-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server