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 says 'broadcast', implying a network write, but does not disclose side effects, idempotency, failure modes, or whether it returns a transaction ID. For a broadcast operation, this is insufficient to set agent expectations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no filler. It efficiently communicates the action and object, earning a 5 for conciseness and structure.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple with one parameter, but there is no output schema and no description of the return value (e.g., txid, success flag) or potential failure conditions. An agent calling this tool has no indication of what to expect after broadcasting, making the context incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already fully describes the single parameter 'raw_tx' as a signed raw transaction in hexadecimal (100% coverage). The description adds no additional semantic value beyond repeating the same concept, so the baseline score of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'broadcast' and the resource 'signed raw transaction' to the Radiant network, making the core purpose evident. It does not explicitly distinguish from siblings like radiant_send_batch or radiant_send_rxd, but the specificity of 'signed raw transaction' implies a distinct use case. A 4 is appropriate because while clear, it lacks explicit sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus alternatives, no prerequisites mentioned (e.g., must have a signed transaction), and no indication of when not to use it. The description simply states the action without contextual usage advice, so it falls at the 'no guidance' level.

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

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

No annotations are provided, so the description carries the behavioral burden. It discloses the key behavior—building a profile with blake3 commitment—and implies preparation rather than execution of registration via 'suitable for'. It does not state whether any state changes, authentication requirements, or return values are involved.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence with no filler, front-loaded verb and object, and the downstream purpose in a subordinate clause. Every element earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 7 parameters and no output schema, the description is too thin to fully equip an agent: it doesn't explain what the tool returns, whether wave_name must be pre-checked, whether address must be validated, or whether the profile is local or broadcast. An agent would need external knowledge to call this correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all seven parameters are already documented in the input schema. The description adds only the WAVE/on-chain context rather than per-parameter detail, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Build') and resource ('AI agent identity profile') and adds the distinctive requirement of a blake3 commitment. This clearly separates it from sibling tools such as radiant_build_data_asset and radiant_resolve_agent_identity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description states the intended use context: profiles are suitable for on-chain registration via the AgentIdentity contract and WAVE naming system. It does not explicitly list alternatives or exclusions, but the use case is specific enough to guide tool selection.

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

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

No annotations exist, so the description carries the full burden. It says the tool returns a CBOR-ready metadata structure, which implies a pure build operation rather than an on-chain transaction, but it never explicitly states side effects, whether anything is broadcast, or whether wallet/contract context is required. This leaves key behavioral questions unanswered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence with no filler, front-loading the main purpose and output format. It is concise, though the brevity leaves behavioral and usage details undisclosed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 10 parameters, 6 required, no output schema, and no annotations, the description is too sparse. It does not explain what the resulting CBOR structure contains, how it relates to the DataMarketplace contract pattern, or what conditions make this tool appropriate among the large sibling set.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds the 'CBOR-ready metadata structure' output framing, but it does not add meaning beyond the schema for individual parameters such as content_hash format, price units, or license expectations.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool as building Glyph NFT metadata for a data marketplace assetainer, with a specific verb ('Build') and resource. The DataMarketplace contract pattern and CBOR-ready output help separate it from generic NFT/transaction builders, though it does not explicitly contrast with siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus alternatives like create_nft, build_transaction, or parse_glyph_envelope. The description implies a data-marketplace NFT metadata construction use case but does not state prerequisites, whether this is a pure off-chain step, or what should happen before/after calling it.

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

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

With no annotations, the description carries the burden, and it does well: it discloses that the default behavior does not broadcast, that broadcasting can be enabled, and what outputs to expect (raw hex, fee, size). It could additionally warn about the irreversibility of broadcast mode, but the 'committing' framing partly covers this.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two dense sentences front-load the core behavior ('Build and sign... WITHOUT broadcasting'), then add the use case and the critical dry_run toggle. There is no filler or repetition of schema content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description usefully names the return pieces (raw hex, fee, size). The rich parameter schema and the description together cover key selection, dry-run behavior, and high-value usage. Exact return shape and how to feed the raw hex into radiant_broadcast_transaction are left implicit, but the tool is still safely callable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all six parameters. The description adds no new parameter-level detail beyond restating the dry_run behavior already present in the schema, which is acceptable but not additive.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description is specific: 'Build and sign a transaction in dry-run mode' and immediately clarifies that it returns raw hex, fee, and size 'WITHOUT broadcasting'. This clearly differentiates it from sibling tools like radiant_broadcast_transaction and radiant_send_batch by emphasizing the no-broadcast default.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives concrete context: 'Critical for high-value operations: inspect the transaction before committing' and explains how to switch to broadcasting via dry_run=false. It doesn't explicitly name alternatives or state when not to use the tool, but the intended workflow is clear.

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

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

With no annotations, the description carries the full burden and discloses the key behavioral facts: permanence ('Permanently burn'), the exact burn mechanism (OP_FALSE OP_RETURN with Glyph envelope), and an authentication prerequisite ('Requires a WIF private key'). It does not mention return values or fee side effects, but the destructive behavior itself is well covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences, each earning its place: what the tool does, the mechanism/effect, and when to use it. No filler, no redundant restating of schema fields.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers purpose, mechanism, permanence, verifiability, and authentication, which is strong for a destructive tool with no annotations. However, with no output schema, it does not state what the call returns (e.g., txid or broadcast result), and it is slightly imprecise about the key_alias alternative to wif.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents all six parameters. The description adds protocol-level context but no per-parameter semantics, so the baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('burn'), a specific resource ('Glyph token'), a protocol identifier ('protocol 6 explicit burn'), and the exact on-chain effect ('spends the token UTXO into an OP_FALSE OP_RETURN output'). This unambiguously distinguishes it from token transfer and other token-related siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly positions the tool for retiring tokens ('Use this to retire tokens cleanly') and supports that with verifiability and on-chain recording. It lacks an explicit when-not-to-use or named alternative, but the intended use case is clearly conveyed.

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

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

No annotations are provided, so the description carries the full behavioral disclosure burden. It clearly implies a read-only access check and names the relevant contract pattern, but it does not disclose the response shape, whether the result is a boolean, or what happens when the balance is insufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence with the core behavior front-loaded and the contract-pattern qualifier appended. It contains no filler, redundancy, or restatement of schema details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple and all parameters are documented, but there is no output schema and the description does not explain the return value or side-effect profile explicitly. An agent can infer the behavior from 'check if', but the exact response semantics remain implicit.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already documents all three parameters with 100% description coverage. The tool description adds no parameter-level detail beyond the access-control context, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a concrete verb ('check'), a subject ('address'), a condition ('holds sufficient Glyph tokens'), and an objective ('access a gated service'). The TokenGatedService contract pattern and the notion of 'sufficient' distinguish this from simple balance or UTXO queries.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the intended use: determining whether an address can access a gated service based on a token balance threshold. However, it does not explicitly state when to use this tool over siblings like radiant_get_token_balance or radiant_get_token_utxos, nor does it provide exclusion criteria.

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

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

No annotations are provided, so the description carries the full burden. 'Check if... available' clearly signals a read-only query and qualifies the behavior with 'for registration,' but it does not explicitly state that no state is changed, how availability is determined, or how invalid/reserved names are handled.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence, front-loaded with the action and outcome, with no wasted words. It is appropriately concise for a simple single-parameter tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter predicate with no output schema, the description is nearly sufficient, and a boolean result is strongly implied by 'check if available.' However, it stops short of explicitly stating the return type or defining availability in edge cases like invalid or reserved names.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already documents the sole parameter with 100% coverage. The description adds no new parameter detail beyond restating the 'WAVE name' concept, so it does not exceed the schema baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('check') and a clear object/resource ('WAVE name availability for registration'). It distinguishes itself from related sibling tools like radiant_resolve_wave_name by focusing on availability for registration, though it does not explicitly name that distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'for registration' implies a pre-registration check, but the description gives no explicit guidance on when to use this tool instead of resolving a WAVE name or attempting registration directly. Usage context is implied rather than stated.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds meaningful context beyond the schema: the operation is offline, depends on an external binary, and produces ABI/ASM/hex artifacts. It could go further by noting failure modes for invalid source or missing compiler, but the core behavioral traits are disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two dense sentences with zero filler. The first sentence states the verb, resource, and outputs; the second covers offline behavior and the external dependency. Everything earns its place and the key information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 3-parameter tool with one required param and no output schema, the description covers the essential invocation context: what it does, what it needs (rxdc compiler), and what it returns. It lacks an explicit description of the return JSON shape or error behavior, but the provided details are sufficient for an agent to decide when and how to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already documents all three parameters with descriptions, giving 100% schema coverage, so the baseline is 3. The description's mention of 'ABI, ASM bytecode, and hex' loosely reinforces the format enum but adds no meaning beyond what the schema's parameter descriptions already state.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the specific verb (Compile), the resource (RadiantScript .cash/.rxd source code), and the concrete outputs (ABI, ASM bytecode, hex). It is clearly distinct from all sibling tools, which are chain queries, wallet operations, and transaction builders, so an agent can tell this is the compile/build tool at a glance.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context: it works offline and requires the rxdc compiler binary, including how to locate it via RXDC_PATH or a sibling repository. There are no similar sibling tools to exclude, so explicit when-not-to-use guidance isn't necessary; the prerequisites serve as the usage gate.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It lists the checks performed (latency, status, server info) but does not state whether the operation is read-only, whether it has side effects, or what the output format will be. This is a significant gap for a tool that could potentially be expected to be harmless but is not explicitly confirmed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, compact sentence with the verb and key details front-loaded. Every word contributes value, and there is no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple, parameterless tool, the description conveys the core action and the data points examined. However, it omits usage context (when to call it) and behavioral specifics (read-only nature, return structure), which would be helpful even for a basic check. Given no annotations or output schema, the description is adequate but not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, and the schema coverage is trivially 100%. There is nothing for the description to add about parameter semantics. Baseline 4 is appropriate for a parameterless tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear verb ('Check') and resource ('ElectrumX connection health') and lists specific aspects (latency, connection status, server info), making the purpose obvious and distinct from siblings like radiant_reconnect. However, it does not explicitly differentiate itself from other diagnostics (e.g., radiant_get_chain_info) beyond the general subject.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. For instance, it does not mention that it could be used before radiant_reconnect or to diagnose issues. The context of when a health check is appropriate is left entirely to the agent.

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

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

With no annotations, the description carries the behavioral burden. It usefully discloses the 2-transaction commit+reveal mechanism and the return of transaction IDs plus tokenRef, but it does not mention on-chain side effects, funding needs, finality, or the wif-vs-key_alias choice, which limits transparency for a state-changing operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, each earning its place: purpose, mechanism, and return value. The description is tightly written, front-loaded with the core action, and avoids re-listing schema fields.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers core purpose, mechanism, and return value, but the tool has 10 parameters, no output schema, and no annotations. Important operational context such as on-chain cost, irreversibility, and key-handling behavior is omitted, leaving the definition minimally viable rather than fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3 even with no additional parameter detail in the description. The schema already documents wif/key_alias exclusivity, defaults, and fee meaning, while the description adds no parameter-specific value and its 'Requires a WIF private key' line is a slightly misleading summary of the credential options.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb ('Mint') and a precise resource ('Glyph Fungible Token (FT) on Radiant'), making the tool's purpose immediately clear. It also mentions the 2-transaction commit+reveal pattern, which distinguishes it from token transfer or NFT creation siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no when-to-use guidance, no exclusions, and no comparison to alternatives such as radiant_transfer_token or radiant_create_nft. The only usage signal, 'Requires a WIF private key,' is incomplete because the schema explicitly allows either wif or key_alias and marks key_alias as preferred.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does mention an on-chain contract effect and the hash composition, but it omits important behavior such as whether this broadcasts a transaction, requires wallet/key setup, incurs fees, or is irreversible. For a state-changing tool, this is a notable gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single tight sentence, starts with the core action, and includes the precise formula without filler. Every clause contributes useful information about what the tool does and why.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a relatively simple three-parameter tool with full schema coverage, the core call is documented. However, there is no output schema and no mention of return values, prerequisites, or on-chain side effects, so the description is adequate but not complete for an agent invoking a mutation-style tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema coverage is 100%, so the schema already describes all three parameters in detail. The description adds the hash ordering (modelHash || inputHash || output), which is useful, but it does not meaningfully expand on parameter formats or constraints beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description states a specific verb and resource: 'Create a blake3 inference proof commitment' with an explicit formula 'hash(modelHash || inputHash || output)'. It also names the contract purpose, distinguishing it from the sibling verify_inference_proof tool by focusing on recording/creating on-chain commitments.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'Used to record AI inference results on-chain via the InferenceProof contract' gives clear contextual guidance for when this tool is appropriate. It does not explicitly state when not to use it or name the verify sibling as the alternative, so it falls just short of a 5.

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

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

With no annotations, the description carries the behavioral burden. It discloses the 2-transaction commit+reveal pattern, that two transaction IDs and a tokenRef are returned, and that a private key is required. The phrase 'Requires a WIF private key' is slightly more prescriptive than the schema's wif-OR-key_alias contract, so this is not perfect.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences, each earning its place: the operation, the transaction pattern, the return values, and the prerequisite. Information is front-loaded with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 8-parameter tool with a rich schema but no output schema or annotations, the description covers the key non-schema facts: the commit+reveal flow and the returned tokenRef. It could additionally state fee/funding implications or post-mint visibility, but the core invocation contract is present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds no param-level detail beyond repeating the WIF requirement; it does not clarify when to provide wif versus key_alias or how attributes/image map to the NFT, leaving that to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence is a specific verb+resource statement: 'Mint a new Glyph Non-Fungible Token (NFT) on Radiant.' This unambiguously distinguishes it from sibling operations such as radiant_create_ft, radiant_transfer_token, and radiant_burn_token.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context—use when minting a new NFT on Radiant—and states a key prerequisite ('Requires a WIF private key'). It does not explicitly name alternatives or when-not-to-use conditions, which prevents a 5, but the intended use is not left to inference.

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

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

With no annotations, the description carries the disclosure burden and does add meaningful behavior: the output involves a WIF or mnemonic, mnemonic mode is recoverable, and random mode has no mnemonic. The 'WARNING: Store the WIF/mnemonic securely' line flags sensitive credential handling. It does not explicitly state persistence or side effects, which prevents a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences front-load the core action, then pack mode trade-offs and a security warning. There is no filler and no repetition of schema details; every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 5-parameter creation tool with no annotations and no output schema, the description explains enough to invoke correctly: mode selection, recoverability, and secret handling. An explicit statement of the return shape or whether the wallet is persisted would fully close the gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3, but the description adds mode-level meaning beyond the schema: random key is fast/no-mnemonic, mnemonic mode is recoverable with 12-24 words, and WIF/mnemonic need secure storage. This helps the agent understand the trade-offs behind path, passphrase, and word_count.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a precise verb and resource: 'Generate a new Radiant wallet.' The two modes are explicitly described, and the word 'new' distinguishes this from restore/register siblings. It adds real semantic content beyond the tool name.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Clearly establishes the use case: new wallet creation rather than recovery or key registration. It also gives mode-selection guidance by contrasting random key as fast/no-mnemonic with mnemonic mode as recoverable. It does not explicitly name alternatives like radiant_restore_wallet, so it stops short of a 5.

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

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

No annotations are provided, so the description carries the full burden. It discloses the offline nature ('Works offline — no ElectrumX connection required'), which is a valuable behavioral trait, but it does not mention error handling, input validation, or that it is a read-only operation. For a simple decode tool, this is adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, with the primary action and key behavioral trait (offline) front-loaded. Every sentence adds value, and there is no wasted text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter tool with no output schema, the description is reasonably complete, but it leaves the return format vague ('human-readable opcodes') and does not specify behavior on invalid hex input. An agent might need more detail on the output structure to use the tool correctly, though the simplicity mitigates the gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description covers the single parameter (script_hex) with an example, so the description adds no extra meaning beyond the schema. Since schema coverage is 100%, a baseline of 3 is appropriate; the description does not need to compensate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Decode'), a resource ('raw script hex'), and an output ('human-readable opcodes'), making the tool's purpose unambiguous. It clearly distinguishes itself from the many sibling tools, even without explicitly naming an alternative.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description offers a use case ('Useful for debugging transactions and smart contracts') but does not specify when not to use this tool or mention alternatives like radiant_compile_script. The guidance is contextual but not explicit enough to steer an agent away from other options.

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

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

With no annotations, the description carries the burden. It transparently lists the return values and implies a pure derivation (no side effects). However, it does not explicitly mention that it is offline or caution about handling the mnemonic/WIF, which would be valuable for a key-related tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences, front-loaded with the core action and return values, and no superfluous wording. The purpose is stated immediately.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the essential return values and a practical usage pattern. It lacks explicit error-handling or output-format details, but given the tool's simplicity and full schema coverage, these are minor omissions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already documents all four parameters with 100% coverage, so the description adds little beyond the use-case note about varying account/index values, which is also reflected in the path parameter's description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Derive a Radiant address'), the resource (Radiant address from a BIP39 mnemonic and BIP32 path), and the output (address, public key, WIF). This distinguishes it from wallet creation or restoration tools among the siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides a concrete use case ('per-task sub-wallets') and advises varying account/index values, but it does not explicitly name alternatives or state when not to use this tool, leaving some inference to the agent.

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

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

With no annotations, the description carries the behavioral burden and it does well by disclosing the two return values (ElectrumX estimate and min-relay floor), their units, and the intended 'pay max' rule. It does not discuss failure modes or side effects, but 'estimate' signals a read-only operation and the main behavior is covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no filler; the action and parameter are front-loaded, followed by the return and decision rule. Every phrase earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter, read-only estimator, the description covers the parameter's role, the return values, and how to act on them. It omits exact response shape and error behavior, but these are secondary given no output schema and the simple interface. The unit mismatch in the max rule is a minor caveat.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single 'blocks' parameter is already documented with default, minimum, and maximum. The description only restates the N-blocks idea and adds no new parameter-level detail.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the operation ('Estimate transaction fee') and the key scoping input ('confirmation within N blocks'). However, it does not distinguish this from the similarly named sibling radiant_estimate_tx_fee, so it falls short of full differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The purpose implies a use case, but there is no explicit guidance on when to choose this tool over alternatives, especially the near-duplicate radiant_estimate_tx_fee, and no exclusion criteria.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It explicitly states 'Pure arithmetic — no network call,' which tells the agent the operation is deterministic, side-effect-free, and requires no network state. This is valuable context, though it could further clarify edge-case behavior or return format.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the core purpose, followed by key behavioral notes. Every sentence earns its place: the main function, the no-network-call guarantee, the usage context, and the OP_RETURN capability. No filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a low-complexity arithmetic tool, the description covers the key aspects: what it computes, the unit (satoshis), the main inputs, and one important extension (OP_RETURN). There is no output schema, but the description's phrasing implies the return is the estimated fee in satoshis. It could be more explicit about how fee_per_byte is applied, but the schema carries that detail.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all four parameters. The description adds a bit of meaning by connecting OP_RETURN outputs to 'token minting' and framing the tool around input/output counts, but it does not substantially go beyond the schema, warranting the baseline score of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('Estimate transaction fee in satoshis') and specifies the inputs ('given input/output counts'). It also distinguishes itself from siblings through 'Pure arithmetic — no network call' and the explicit OP_RETURN support, separating it from tools like radiant_estimate_fee or network-dependent operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives a clear usage context: 'Use this to budget before building a transaction.' It does not explicitly name alternative tools or state when not to use it, but the use case is concrete and unambiguous, which is sufficient for a focused estimation utility.

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

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

No annotations are provided, so the description carries the burden. It discloses that the tool returns both confirmed and unconfirmed balances and in two units (satoshis and RXD), which is useful behavioral detail beyond the schema. It does not mention side effects (e.g., read-only nature) or error behavior, but for a getter this is a moderate disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence, front-loaded with the verb and resource, and includes essential scoping details (confirmed/unconfirmed, units) with zero waste. It is efficient and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter, read-only getter with no output schema and no annotations, the description covers the core purpose and return values. However, it omits potential error conditions, response format specifics, and network requirements, which would be helpful given the lack of annotations. It is adequate but not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the address parameter is already fully documented in the schema (format and encoding). The description adds no additional meaning beyond restating 'for a Radiant address', which is redundant. The baseline of 3 applies because the schema carries the semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Get'), resource ('RXD balance'), and target ('a Radiant address'), and clarifies the return scope (confirmed/unconfirmed, in satoshis and RXD). It is clear and distinguishes from token balance tools like radiant_get_token_balance, though it does not explicitly name a sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage: if you need an RXD balance for an address, use this tool. However, it does not explicitly state when to use it over alternatives like radiant_get_utxos (which returns UTXOs) or radiant_get_history (which returns transaction history), leaving the agent to infer the right choice.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the core function and does not explain what happens on invalid heights, whether it is a read-only operation (implicit), or any error handling. A simple getter is implied, but nontrivial behavior like missing headers or network errors is unaddressed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence with no wasted words. It is front-loaded with the action and resource, making it easy to scan. For a simple tool with one parameter, this level of brevity is appropriate.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read operation with one well-documented parameter and no output schema, the description is adequate but lean. It does not mention return format, edge cases, or any additional behavior. Compared to more complex tools, this may suffice, but it lacks the depth that would make it fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the height parameter is fully described in the schema. The description reiterates 'by block height', adding no new information beyond what the schema already provides. The baseline score of 3 applies since the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (get), the resource (block header), and the input (block height). It is distinct from siblings like radiant_get_chain_info and radiant_get_transaction, which target different data. This makes the purpose unambiguous and aids selection.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or scenarios where another tool would be more appropriate. Agents are left to infer usage from the name and purpose alone.

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

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

With no annotations, the description carries the safety burden; 'Get current ... status' clearly signals a read-only operation with no parameters. It does not explicitly say 'does not modify state' or describe error behavior, but for a status query this is adequate behavioral disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single compact sentence front-loads the action and resource before enumerating the returned fields. No wasted words or repetition of structured data.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple (no parameters, no annotations, no output schema), and the description lists the key return values. It could be more explicit about the shape of 'network parameters' or response format, but it provides enough 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.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero parameters, so there is no parameter burden. The description adds no parameter semantics, but none are needed; baseline for 0 params is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description identifies a specific verb ('Get'), a specific resource ('current Radiant blockchain status'), and the exact return contents (latest block height, tip hash, network parameters). It is easily distinguished from siblings like radiant_get_block_header (specific header vs current tip) and radiant_connection_health (node connectivity vs chain state).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance about when to use this tool versus alternatives; usage is implied by the word 'current' and by the unique return fields. It does not state exclusions such as 'for a specific block use get_block_header' or 'for node health use connection_health.'

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Get', which implies a read-only operation, but it does not state return format, pagination, authorization needs, error behavior, or any side effects. For a filter tool without annotations, this leaves too much unspoken.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that states the action, object, and filter in six words. It is completely free of filler and front-loads the core purpose, making it easy for an agent to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter tool with no output schema, the description states the core purpose and the schema covers the parameter. However, it lacks usage guidance and behavioral details (e.g., whether results are limited, order, or what a returned contract contains), so it is adequate but not fully complete for an agent with no prior context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already fully documents the algorithm parameter with an explicit mapping (0=SHA256D, 1=BLAKE3, etc.), and schema description coverage is 100%. The description's 'mining algorithm' phrase adds no new information beyond the schema, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Get'), a clear resource ('dMint contracts'), and a distinct filtering criterion ('by mining algorithm'). This cleanly separates it from sibling tools like radiant_get_dmint_contracts (likely unfiltered) and radiant_get_dmint_contract (singular), so an agent can tell them apart without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool—when dMint contracts need to be filtered by mining algorithm—but it never explicitly states when to prefer this over alternatives like radiant_get_dmint_contracts or radiant_get_most_profitable_dmint. There is no when-not guidance or direct comparison, leaving selection partially to inference.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. 'Get details' makes the read-only nature clear and the parenthetical lists likely response fields, but it does not describe error behavior, what happens for an unknown contract, or any other side effects. This is adequate for a simple fetch but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence that front-loads the action and resource, then adds a compact parenthetical of key return fields. There is no filler or redundant information; every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity, one clearly documented parameter, and no output schema, the description provides enough to understand the return content and basic purpose. It could mention the need for a valid existing contract ref or note the sibling listing tool, but it is otherwise complete for straightforward usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter, 'ref', is fully described in the schema as 'Contract reference (72 hex chars)', so schema description coverage is 100%. The tool description adds no additional parameter meaning beyond what the schema already provides, matching the baseline for full schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Get details') and names the exact resource ('a specific dMint contract'), then enumerates the returned fields: difficulty, reward, algorithm, supply. This clearly distinguishes it from sibling tools like radiant_get_dmint_contracts, radiant_get_dmint_by_algorithm, and radiant_get_most_profitable_dmint.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'a specific dMint contract' implies the tool is for fetching one contract by reference, as opposed to the plural listing or algorithm-based tools. However, it does not explicitly state when to use this tool versus alternatives or mention any exclusions, leaving usage mostly to inference.

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

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

With no annotations, the description carries the full burden. It implies a read-only operation ('List') and adds domain context (PoW distribution), but it does not explicitly state that it is non-destructive, what 'active' means, or whether the response is paginated or includes a list of all contracts. It adds some context but lacks explicit behavioral disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that front-loads the verb and resource, then adds clarifying context. No wasted words and it is appropriately brief for a simple list operation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has no output schema, and the description does not explain what the response contains (e.g., list of contract refs, fields, or how 'active' is determined). It also does not differentiate from sibling tools, which could cause an agent to choose the wrong tool. For a tool that returns a list, more context on return format and selection criteria would be needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description covers the single 'format' parameter 100% (enum simple/extended with default). The tool description does not add any additional meaning about the parameter. Per the rubric, baseline is 3 when schema coverage is high, and no extra value is added.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'List' and the resource 'active dMint contracts', and adds useful context by explaining dMint as 'decentralized mining' and 'PoW distribution'. This distinguishes it from general token tools, but it does not explicitly contrast with the sibling radiant_get_dmint_contract (singular) or radiant_get_dmint_by_algorithm, leaving the list-vs-single distinction implicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus the other dMint-related siblings. There is no mention of alternative tools, selection criteria, or when not to use it. The only hint is the word 'List' implying a collection, but the description never states 'use this to get all contracts' or 'use get_dmint_contract for a specific one'.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It does this well by stating that ALL entries are returned, there is no pagination at this layer, and active addresses may produce a large response. It could add more detail about ordering or return shape, but the core behavior 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no wasted words. The main purpose is front-loaded, and the important behavioral caveat about large responses is placed immediately after.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter read tool, the description covers purpose, scope, and behavioral expectations. It is missing only explicit guidance about sibling alternatives and the response format, but neither is critical given the low complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the only parameter, 'address', is already described as 'Radiant address.' The tool description repeats this without adding extra semantic detail, so the schema carries the parameter documentation burden.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: 'Get transaction history for a Radiant address.' This clearly separates it from sibling tools like radiant_get_token_history or radiant_get_transaction, since it targets address-level transaction history rather than token history or a single transaction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context: it returns the full transaction history, and the 'no pagination' caveat warns agents when a response may be large. It does not explicitly name alternatives or state when-not-to-use it, so it stops short of a 5.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It correctly conveys that this is a read-only retrieval and adds useful behavioral context by specifying the ordering metric (reward/difficulty ratio). However, it does not mention return format, pagination, or error scenarios, making it strong but not fully comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence that front-loads the action and resource, then immediately specifies the sorting criterion. There is no wasted verbiage or repetition of schema information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one optional parameter and no output schema, the description is largely sufficient. It conveys the core behavior and the sort key. Minor gaps like not defining 'dMint contracts' are acceptable given the domain context and sibling tool names. The schema covers the parameter, so an agent can call it correctly with the given information.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter, 'limit', has a complete description in the schema ('Number of contracts to return'), so the schema covers 100% of parameter semantics. The description does not add any additional meaning about how limit interacts with the sorting, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Get'), the resource ('dMint contracts'), and the distinguishing characteristic (sorted by estimated profitability via reward/difficulty ratio). This differentiates it from siblings like radiant_get_dmint_contracts (generic listing) and radiant_get_dmint_by_algorithm (algorithm-filtered) without needing to open schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the use case (obtain the most profitable contracts) but provides no explicit guidance on when to choose it over radiant_get_dmint_contracts or other dmint-related tools. It lacks exclusionary language or named alternatives, leaving the agent to infer the selection based solely on the sorting phrase.

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

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

With no annotations, the description carries the behavioral burden, and it clearly indicates a non-mutating lookup. However, it does not disclose any operational traits such as output representation, error behavior, or whether the results are static definitions or network-dependent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single front-loaded sentence that states the action, scope, and returned fields without repetition or filler. Every element earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter informational call, the description covers the resource and content of the response. It is slightly incomplete because it does not describe the structure of 'valid combinations' or the conditions under which the tool might be unavailable, but overall it is sufficient for a low-complexity call.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters and the schema has 100% coverage, so the baseline is high. The description still adds value by specifying exactly what the no-argument call returns, compensating for the absence of an output schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Get') and resource ('all Glyph protocol types'), and enumerates the returned fields: IDs, names, descriptions, and valid combinations. This makes the tool's scope clear and distinguishable from a validation or chain-info tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for retrieving protocol metadata and works with no arguments, but it does not explicitly state when to choose it over related siblings such as radiant_validate_protocols or radiant_parse_glyph_envelope. There is no exclusion guidance or mention of alternatives.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only operation via 'Get' but does not confirm side effects, authentication needs, rate limits, or that it only covers DEX swaps. It lacks any behavioral detail beyond the basic action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that front-loads the core purpose without any filler. It is concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has no output schema and no annotations, so the description must provide sufficient context about the return format and the domain. It fails to mention that it returns swap history specifically for DEX trades, how it differs from other token history, or any details about pagination or ordering. This is incomplete for a tool with pagination and a nuanced domain.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema provides 100% coverage of all three parameters (ref, limit, offset) with descriptions. The tool description adds no additional semantics about these parameters; it simply states the general purpose without explaining how ref, limit, or offset function. Since the schema already handles parameter documentation, a baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action 'Get' and the resource 'trade history for a token on the on-chain DEX', which is specific and distinguishes it from generic token history tools. However, it does not explicitly contrast with the sibling radiant_get_token_history, which likely covers broader token transfers, so it is clear but not maximally differentiated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. It does not mention that it is specifically for DEX swap trades, nor does it reference sibling tools like radiant_get_token_history or radiant_get_swap_orders. The context for choosing this tool is entirely absent.

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

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

With no annotations provided, the description carries the full burden and does a good job disclosing the critical offset-based pagination behavior: orders can move in and out of the book, causing double-counting or missed orders, and advising a re-fetch from offset=0 for a fresh snapshot. It does not mention return format, but the key behavioral caveat is well surfaced.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is tight and efficient: the primary purpose is stated in the first sentence, and the important pagination caveat is clearly flagged and explained in the next two. Every sentence earns its place and the structure supports quick comprehension.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-style orderbook query with a fully documented schema, the description provides the core purpose and the one non-obvious behavioral trap (pagination inconsistency). It does not describe the return payload structure, but that is not strictly necessary given the tool's simplicity and the schema coverage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all four parameters. The description does not add extra semantic detail about buy_ref/sell_ref/limit/offset beyond what is in the schema, landing at the baseline of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get' and the resource 'open swap orders for a trading pair', with the added context 'on-chain DEX orderbook'. It is specific enough to distinguish from many sibling tools, though it does not explicitly name or contrast radiant_get_swap_history or other alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies this is for viewing the current DEX orderbook and includes a pagination caveat, but it does not explicitly state when to prefer this over radiant_get_swap_history or when not to use it. The intended use is clear by context 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.

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

With no annotations, the description carries the full burden of behavioral disclosure. The verb 'Get' implies a read-only operation, but the description does not explicitly state safety, permissions, error behavior, or return characteristics. This is a noticeable gap for a tool with zero annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no filler, immediately stating the action, resource, and parameter format. It is appropriately terse for such a simple one-parameter tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter getter with no output schema, the description is close to sufficient, but it does not describe what fields or shape the returned token information will have. Given the absence of annotations and output schema, a bit more detail on the result would make it complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the description repeats the token_ref format exactly as the schema does. It adds no new semantic information beyond what the schema already provides, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action ('Get') on a specific resource ('Glyph token information') using a clear lookup key ('token reference'). However, it does not distinguish itself from siblings like radiant_get_token_metadata or radiant_get_token_utxos, so an agent may need to compare definitions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for retrieving token information when a token reference is available, which gives some context. It offers no explicit when-not-to-use guidance or alternative tool names, so the usage decision is left to inference.

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

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

There are no annotations, so the description carries the behavioral disclosure burden. The verb 'Get' conveys a read-only intent, but the description does not specify return format, token units, or any other behavioral details such as decimal handling or whether unconfirmed balances are included.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded, 12-word sentence that states the action and scope without filler or redundant schema information. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter read operation with fully described inputs, the description is nearly complete for selection and invocation. The only notable gap is the absence of an output schema or explicit return-value/unit description, though the meaning of 'balance' is largely self-explanatory.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both parameters are already documented well. The description adds a 'Glyph' qualifier but no meaningful semantic detail beyond what the schema provides, which matches the baseline score for fully covered parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Get'), a specific resource ('balance of a specific Glyph token'), and a scope ('for an address'). This clearly distinguishes it from siblings like radiant_get_balance, radiant_get_token, and radiant_get_token_utxos.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit when-to-use or when-not-to-use guidance is given, and no alternative tools are named. The intended usage is only implied by the phrasing 'Get balance...', so an agent has to infer that this tool is for querying a single address's token balance.

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

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

With no annotations provided, the description carries the full behavioral disclosure burden. It goes beyond a generic 'get' statement by exposing the non-obvious offset-based pagination instability, warning about duplicate/gap risks, and suggesting a mitigation strategy. This is genuinely useful behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no wasted words. The purpose is stated first, and the critical pagination caveat is clearly flagged and separated from the main description. It is well-structured for quick consumption.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only token history tool with a fully documented parameter schemaaint and no output schema, the description covers the main operational hazard: pagination instability. It does not describe the shape of returned entries, but 'transaction history' is reasonably self-explanatory and the pagination guidance is the key missing piece that the description supplies.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already describes all three parameters with 100% coverage, so the baseline is 3. The description adds meaningful nuance by explaining how offset behavior can cause shifting entries, which enriches the semantics of limit/offset beyond their schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb-resource pair: 'Get transaction history for a specific Glyph token.' This effectively distinguishes it from more generic history tools like radiant_get_history, though it does not explicitly name alternatives or contrast them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The pagination caveat gives practical usage guidance for this specific tool, recommending a single-call fetch for stable enumeration when count is bounded. However, it does not state when to prefer this tool over siblings such as radiant_get_history, radiant_get_token_utxos, or radiant_get_swap_history.

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

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

No annotations are provided, so the description must convey behavioral transparency on its own. It indicates this is a read operation ('Get') with no mention of side effects, but it also does not disclose error handling, authentication requirements, or the exact structure of the returned metadata. The description is not misleading, but it lacks depth beyond implying a read-only fetch.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that gets straight to the point. It front-loads the key action and resource, and the parenthetical example fields add useful context without padding. This is an efficient, well-structured description with no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has one parameter, no output schema, and no annotations, the description is reasonably complete for a simple getter. It lists example fields that hint at the return content. However, it does not explain how this tool differs from similar token tools, nor does it mention potential errors or the exact return format, leaving some gaps for an agent deciding whether to use it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already documents token_ref as 'Token reference (txid_vout)' with 100% coverage. The description does not add any additional meaning to the parameter, such as format examples, constraints, or clarifications about what 'txid_vout' means. Since the schema covers the parameter fully, the description adds no extra value in this dimension.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool retrieves full CBOR metadata for a Glyph token, listing examples like name, description, image, and attributes. It specifies the verb (Get) and resource (CBOR metadata) precisely. However, it does not explicitly differentiate it from sibling token tools like radiant_get_token, leaving some ambiguity about its unique role.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus other token-related tools such as radiant_get_token, radiant_get_token_utxos, or radiant_get_token_balance. It does not mention any exclusions or alternative conditions. An agent would have to infer from the name and description that this is for metadata retrieval, but without explicit routing guidance, it is easy to confuse with similar getters.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It goes beyond the schema by explicitly warning about offset-based pagination causing double-counting or missed entries between calls, which is a valuable non-obvious behavior for an agent to know.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact: one clear action line followed by a focused pagination warning. Every sentence earns its place, and the most important caveat is clearly flagged.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list-style read tool, the schema fully documents parameters and the description adds the key runtime caveat. The lack of an output schema is not compensated by a return-format description, but this is unlikely to prevent correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents limit, offset, and the full token_type ID mapping. The description adds little semantic value beyond restating 'FT, NFT, etc.', which is already captured by the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action ('Get tokens') and a clear differentiator ('filtered by type'), with concrete examples (FT, NFT, etc.). This distinguishes it from siblings like radiant_get_token, radiant_list_tokens, and radiant_search_tokens without requiring the agent to open their schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'filtered by type' implies the tool's use case, and the pagination caveat is operationally useful. However, there is no explicit guidance on when to choose this over alternatives such as radiant_search_tokens or radiant_list_tokens, nor any when-not-to-use conditions.

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

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

No annotations are provided, so the description must disclose behavior. It lists the return fields (tokenRef, txid, vout, height, satoshi value), which is helpful. However, it does not explicitly state that the operation is read-only or mention error handling, pagination, or edge cases. The verb 'Discover' implies read-only, but it is not explicit.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the core purpose, and includes the return fields and a clear usage workflow. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple query tool with one parameter and no output schema, the description is complete: it states what is returned and how to use the result. It also connects to sibling tools, making the workflow clear. Nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has one parameter (address) with a clear description. The tool description does not add additional detail about address format, validation, or constraints. Since schema coverage is 100%, the baseline is 3, and the description adds little beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Discover all Glyph tokens held by an address') and clearly distinguishes from sibling tools like radiant_get_balance or radiant_get_utxos by focusing on token UTXOs. The resource and scope are precise.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says when to use the tool ('without prior knowledge of token references') and what to do next (pass tokenRef to radiant_transfer_token or radiant_burn_token). This gives clear guidance and implies it is the discovery entry point for token operations.

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

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

No annotations are provided, so the description carries the behavioral burden. It only restates the lookup action and gives no details about response format, error behavior, or how unknown/unconfirmed txids are handled.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence that communicates the core purpose with no filler or redundancy. Every word contributes.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter read tool the description is sufficient for basic invocation, but it does not specify what 'detailed information' includes and there is no output schema. An agent must guess at the response shape and potential failure cases.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema fully documents the only parameter, txid, including its required status and 64-hex format. The description adds no additional parameter meaning, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Get'), a specific resource ('detailed information about a transaction'), and the access method ('by its txid'). This clearly distinguishes it from sibling tools like get_block_header or get_history.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the right usage context: when the agent has a txid and needs transaction-level details. However, it does not explicitly say when not to use it or name any alternatives, such as get_history or broadcast_transaction.

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

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

With no annotations provided, the description carries the behavioral burden. 'List' clearly implies a read-only operation, but the description does not disclose details like whether mempool UTXOs are included, ordering, pagination, or output format. This is adequate for a simple getter but not highly transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no filler. Every word contributes to conveying the operation and its scope.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter, read-only list operation with complete schema coverage, the description is largely sufficient for an agent to select and call the tool. It could be more complete by clarifying the distinction from token UTXOs or describing the response shape, but those are not critical for basic invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already fully documents the single 'address' parameter. The description reinforces that the address is a Radiant address but adds no meaningful semantics beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('List') and resource ('unspent transaction outputs (UTXOs)') scoped to a Radiant address. It does not explicitly distinguish itself from the similarly named sibling radiant_get_token_utxos, so it misses the top score for sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The usage context is implied: use this tool when UTXOs for a Radiant address are needed. However, there is no explicit guidance about when not to use it, such as when token-specific UTXOs or a balance overview would be more appropriate.

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

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

With no annotations, the description carries the full burden, and it handles this well by explicitly stating that WIFs are never returned and specifying the exact fields that are returned. For a read-only list operation, this is meaningful behavioral and privacy-relevant disclosure beyond the basic verb.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence that front-loads the core action and then adds the key constraint (WIFs never returned). Every word earns its place, with no filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter listing tool with no annotations and no output schema, the description is fully sufficient: it explains what the tool lists, what it returns, and what it deliberately does not return. No additional information is needed for an agent to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero properties, so there are no parameters to document. The description adds no parameter-level detail, but none is needed; the baseline of 4 is appropriate for a parameterless tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('List') and resource ('aliases registered in the server-side keyring'), making the tool's function unmistakable. It also narrows the return set to alias, derived address, and entry time, which distinguishes it from token-listing or wallet-listing siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly communicates the context: use this tool to enumerate keyring aliases. It does not explicitly name alternatives or exclusions, but the keyring-specific scope and the presence of related sibling tools like radiant_register_key and radiant_remove_key make the intended use obvious.

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

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

With no annotations provided, the description carries the full behavioral disclosure burden. It discloses a critical behavioral trait: limit-based truncation with non-deterministic cut-off when holdings exceed `limit`, and it gives actionable mitigation advice. It does not mention return format or ordering, but the pagination caveat is the most important hidden behavior for this kind of list tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences and every part earns its place: the first states the core operation, the second delivers an important caveat with actionable guidance. The warning is prominently front-loaded with 'PAGINATION CAVEAT,' making it easy for an agent to notice and account for.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter list tool with fully documented parameters, the description covers the main operational risk (pagination truncation) and the correct parameter strategy. Since there is no output schema, a brief note on the shape of returned token entries would have made it fully complete, but the current text is sufficient for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already documents both parameters with 100% coverage, setting a baseline of 3. The description adds meaningful behavior beyond the schema by explaining that `limit` can cause non-deterministic truncation and advising callers to set it high enough. This extra semantic makes the limit parameter more than a bare 'maximum tokens' field.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action and resource: 'List Glyph tokens held by a Radiant address.' It is clear this enumerates a holder's tokens rather than fetching balances or searching the token registry. It does not explicitly name a sibling alternative, so it falls short of a perfect 5, but the scope is adequately differentiated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies its use case: when an agent needs all Glyph tokens for a Radiant address. It provides practical guidance about setting `limit` high enough to avoid truncation. However, it does not explicitly contrast with sibling tools such as `radiant_get_token_balance` or `radiant_get_tokens_by_type`, leaving the when-to-use-vs-alternatives decision to inference.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the creation action and gives no details about side effects (e.g., locking funds, on-chain commitment), prerequisites, errors, or response format. The word 'Create' implies mutation, but the description does not elaborate on what happens after invocation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence with no wasted words. However, it is under-specified for a tool with 5 parameters and no annotations; the brevity comes at the cost of missing critical operational context. It is not overly verbose, but it could be more informative without being wordy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool involves creating a micropayment channel, which has significant complexity (funding, timeouts, parties). The description does not mention return values, required funds, channel lifecycle, or relationship to 'radiant_update_channel'. With no output schema and no annotations, the description leaves too much to the agent's inference, making it incomplete for reliable invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers 100% of the parameters with descriptions, so the baseline is 3. The tool description adds no additional meaning beyond what the schema already provides. It does not explain how parameters interact or provide context beyond the schema entries.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Create initial state') and the resource ('micropayment channel between two agents'), and mentions the contract pattern. It is specific enough to distinguish from the sibling 'radiant_update_channel', but it does not explicitly name the sibling or contrast itself, which would make it a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It does not mention that this is for opening a new channel or that 'radiant_update_channel' is for modifying an existing one. Without such context, an agent may not know when to select this over related tools.

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

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

With no annotations provided, the description must carry the full burden of behavioral disclosure. It states that it parses and decodes, implying a read-only operation, but does not mention whether it mutates anything, requires authentication, or has side effects. The lack of explicit safety information is a gap, but the read-only implication is reasonably clear.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, with a single sentence that includes a parenthetical clarification. It front-loads the main action and provides context, with no wasted words. It could be slightly more structured but is efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has a single parameter and no output schema, so the description is nearly sufficient for calling it. However, it does not describe the return value or any potential errors, which could be important for a parsing tool. Overall, it is adequate but lacks details about the parsed result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema describes 'script_hex' as 'Script in hexadecimal', which covers the parameter's meaning. The description adds that it is 'raw script hex' and clarifies the context (transaction output), but does not provide format or example. Given high schema coverage (100%), baseline 3 is appropriate; the description adds minimal extra value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Parse a Glyph envelope') and the resource ('raw script hex'), and explains the purpose ('decode token metadata from a transaction output'). It is specific enough to distinguish from generic scripts like 'decode_script', though it does not explicitly contrast with any sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is used to decode token metadata from transaction outputs, but does not state when to use it vs. alternatives like 'get_token_metadata' or 'decode_script'. No explicit exclusions or conditions are provided, so an agent must infer the appropriate context.

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

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

With no annotations, the description carries full responsibility for behavioral disclosure. It reveals the full sequence of actions: tears down the socket, clears the backoff counter, and re-handshakes. This is comprehensive for a connection-reset tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with zero fluff. The purpose is stated first, then the trigger condition and the mechanics are packed into the second sentence. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a zero-parameter tool, no output schema, and no annotations, the description fully explains what the tool does, when to invoke it, and what to expect internally. No critical information is missing for an agent to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters, and the schema is trivially 100% covered, so the baseline of 4 applies. The description adds nothing about parameters because none exist; there is no missing semantic burden.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action ('Force a fresh ElectrumX reconnect') and identifies a precise trigger condition ('when the auto-reconnect logic has given up after 5 backoff attempts and the session is wedged'). This clearly distinguishes it from other Radiant tools that focus on chain info, balances, or transactions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly tells the agent when to use this tool and describes the failure condition that warrants it. It implies normal auto-reconnect is preferred, giving clear decision context without needing further inference.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that the key is stored server-side, specifies the keyring file path and required POSIX permissions (0600), and implies the write is persistent and the key is not transmitted again. It doesn't explicitly state error behavior or that this is a write operation, but the nature is clear from the context. It adds meaningful value 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, front-loaded with the core purpose, then adds storage details and permissions. Every sentence earns its place, with no redundancy or fluff. It is appropriately sized for the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool is a simple write operation with 3 parameters and no output schema, the description covers the purpose, storage location, permissions, and parameter semantics. It doesn't explain return values, but that's not necessary without an output schema. The only minor gap is the lack of explicit error-handling or idempotency notes, but these are covered by the overwrite parameter and general behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description enriches the parameters: it explains that the WIF is the last transmission, that the alias is used as key_alias on signing tools, and that overwrite defaults to false. These details add practical meaning beyond the schema's bare descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb ('Store') and resource (WIF private key in server-side keyring under an alias). It distinguishes itself from sibling tools like radiant_list_keys and radiant_remove_key by explaining its role in storing keys for later signing, making it unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use the tool: to store a key so that signing tools can reference it by alias instead of resending the WIF. It also provides context about keeping the WIF out of transport and logs, which helps the agent decide when this is appropriate. It doesn't explicitly name alternatives or exclusions, but the context is clear enough.

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

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

With no annotations, the description carries the full burden, and it discloses a key behavior: the tool returns success even if the alias doesn't exist, and the 'removed' field indicates actual removal. This is valuable non-obvious behavior that an agent needs to interpret results correctly. It also implies a mutation (removal) without explicit destructive warning, which is acceptable given the tool's purpose.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with zero fluff. It front-loads the primary action and then adds a critical behavioral nuance. Every word earns its place, making it an exemplary model of conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with a single parameter, full schema coverage, and no output schema, the description is complete. It tells the agent what it does, how to interpret the result (via 'removed' field), and there are no edge cases or prerequisites missing. The behavioral note is especially important for correct invocation and result handling.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already fully describes the sole parameter 'alias' with 100% coverage, so the description adds little beyond what the schema provides. It does not add format or constraint details, but none are needed. Baseline 3 is appropriate since the schema handles the parameter semantics well.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Remove an alias from the server-side keyring') with a specific verb and resource. It differentiates from siblings like 'radiant_register_key' and 'radiant_list_keys' by focusing on removal, making its purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use this tool: when a key alias needs to be removed. It does not explicitly exclude alternatives, but the action is so specific that no sibling could be confused. The note about checking the 'removed' field adds practical usage context, though it doesn't contrast with other tools.

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

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

No annotations are present, so the description carries the burden of disclosing behavior. It mentions return categories but does not state whether the call is read-only, what happens for unknown or invalid WAVE names, or any authentication 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short, front-loaded sentences with no filler. The action and resource come first, followed by a compact summary of return values, and the description avoids repeating schema details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter tool with no output schema and no annotations, the description gives only high-level return categories. It omits expected return structure, error handling, and the distinction from other wave-name tools, so it is adequate but not complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema fully covers wave_name with 'Agent's WAVE name', so the baseline is 3. The description adds no new format, constraints, or examples; it only reuses the term 'WAVE name' without enriching parameter meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb (Resolve) and a specific resource (an AI agent's identity from its WAVE name), and it lists the return content (capabilities, pricing, API endpoint). It is clear, though it does not explicitly differentiate from the closely related sibling radiant_resolve_wave_name.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus alternatives like radiant_resolve_wave_name or radiant_build_agent_profile. The intended use is only implied by the verb 'Resolve'; no exclusions or routing hints are provided.

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

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

With no annotations, the description carries the behavioral burden. It clearly indicates a read-style lookup operation that returns zone records, and it adds useful context by explaining that WAVE is Radiant's on-chain naming system. It does not spell out edge cases like unregistered names or whether subdomains are included, but the core behavior 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, front-loads the operation and output in the first sentence, and provides minimal necessary context in the second. Every word adds value and there is no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter resolver, the description is nearly complete: it names the input, lists representative output fields, and explains the domain. The main gap is that there is no output schema and the description does not specify the exact return shape or behavior for invalid/unregistered names, but an agent can still 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.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already documents the single parameter with a clear description and examples ('alice', 'myapp'), so schema coverage is 100%. The tool description adds little parameter-specific meaning beyond what the schema provides, matching the baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Resolve'), a precise resource ('WAVE name'), and the result ('zone records (address, avatar, description, DNS records, etc.)'). This clearly distinguishes it from the other WAVE-related sibling tools such as reverse lookup, availability check, and subdomains without needing to name them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description makes the use case clear—use this to resolve a WAVE name to its zone records—and explains what WAVE is. However, it does not explicitly guide the agent away from related tools like radiant_wave_reverse_lookup or radiant_wave_subdomains, nor does it state 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.

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

The description adds useful behavioral detail by stating that the mnemonic checksum is validated and the private key is derived via BIP32. However, with no annotations available, it does not disclose whether the restore persists the wallet, overwrites an existing one, or what happens on failure — a meaningful gap for a state-changing wallet tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences, front-loaded with the main purpose and no filler. Every clause carries meaning, and the structural balance between what the tool does and how it works is efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Although all parameters are documented, there is no output schema and no annotations, and the description never states whether the restored private key or wallet is returned, stored, or whether restoration can overwrite an existing wallet. For a security-sensitive restore operation, this is a significant completeness gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all four parameters. The description reinforces that the mnemonic is BIP39 and the derivation is BIP32, but it does not add materially new parameter-specific semantics beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Restore a Radiant wallet from a BIP39 mnemonic phrase.' It further clarifies the operation by naming checksum validation and BIP32 derivation, making it easy to distinguish from siblings like radiant_create_wallet and radiant_derive_address.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'Restore... from a BIP39 mnemonic' implies the appropriate use case of recovering an existing wallet, but there is no explicit guidance about when to prefer this over radiant_create_wallet or radiant_derive_address, nor any exclusions or prerequisites.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. 'Search' implies a non-mutating, read-only operation and the parenthetical about NFTs with DAT protocol adds useful context. However, it does not disclose return shape, pagination behavior, or any marketplace-specific constraints 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single well-structured sentence that front-loads the core action and resource, then provides clarifying detail. Every word contributes value and there is no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a straightforward search operation, the description plus fully documented schema is largely complete. The main gap is the lack of any information about the return format, but the absence of an output schema and the intuitive nature of search make this a minor omission.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema covers all three parameters with clear descriptions ('Search query', 'Filter by asset type', 'Max results'), so the baseline is 3. The tool description adds no additional meaning beyond the schema fields, but no compensation is needed given the high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the action ('Search') and the resource ('the data marketplace') with concrete examples of assets ('datasets, models, and other data assets'). It is specific enough for an agent to understand the tool's purpose, though it does not explicitly distinguish itself from the sibling `radiant_search_tokens`.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the appropriate use case: searching for data assets in the data marketplace. However, it does not explicitly state when to prefer this tool over a sibling like `radiant_search_tokens`, nor does it provide exclusions or conditions for alternative choices.

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

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

With no annotations, the description carries the behavioral burden, and it does disclose a key behavior: responses are capped at `limit` and there is no offset/cursor pagination, instructing callers to set limit appropriately. It does not cover output format or matching semantics, but the main trap (assuming pagination) is surfaced.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, with the purpose front-loaded and the pagination caveat immediately after. No filler or repetition; every clause contributes.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple 3-parameter search tool with full schema coverage and no output schema, the description covers the operation, matching criteria, and the only major behavioral constraint. It does not describe the match object shape, but that is less critical for deciding whether to invoke and set limit.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds value by explaining why limit is important (single response, no pagination upstream) and re-affirming query is by name/ticker, which is more actionable than the schema's 'Max results'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states a specific operation (search), a specific resource (Glyph tokens), and the matching criteria (name or ticker symbol). This differentiates it from sibling lookups like get_token, list_tokens, and get_tokens_by_type in intent, so an agent can pick it based on the query mode.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context for using the tool (searching tokens by name/ticker) and important operational guidance about the lack of pagination. However, it does not explicitly compare against sibling tools such as list_tokens or get_tokens_by_type, so when-to-use vs alternatives is only implied, not stated.

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

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

With no annotations available, the description carries the full behavioral disclosure burden. It usefully reveals that 'inputs are selected once and change is returned in a single output,' which goes beyond the schema. However, it omits important side effects for a send tool—such as signing/broadcasting an irreversible on-chain transaction and how fees are deducted—so an agent must infer those.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, all informative: the action, the economic rationale, and the canonical use case. The key purpose is front-loaded, and there is no filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has no output schema and no annotations, so the description must carry the operational contract. It does not state what the tool returns (e.g., a transaction ID) or explicitly confirm on-chain broadcast and irreversibility. The schema covers constraints like max 100 outputs and fee defaults, but the full operational behavior is incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds slight semantic color around change handling and cost efficiency, but it does not add meaningful per-parameter meaning beyond what the input schema already documents.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description opens with a specific verb and resource: 'Send RXD to multiple recipients in a single transaction.' It clearly distinguishes this from the single-send sibling by emphasizing batching, cost savings, and repeated-input selection, so an agent can understand its purpose without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context for when to use the tool: multiple recipients, with an explicit cost rationale ('Much cheaper than N separate transactions') and a concrete use case ('agent fan-out payments'). It does not explicitly name alternatives or state when not to use it, but the usage context is strong.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It transparently states that the tool fetches UTXOs, selects coins, builds, signs, and broadcasts the transaction, which clearly signals a mutating, on-chain operation. It also notes the WIF requirement. It does not mention irreversibility, insufficient-funds errors, or the return format, but the core behavior is well disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the primary purpose ('Send RXD (photons) to an address'). It packs the entire pipeline and the key prerequisite into a compact, scannable format with zero waste. The structure is efficient and easy for an agent to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a complex transaction tool with 6 parameters and no output schema. The description explains the overall process and the WIF requirement, but it omits the return value (likely a transaction ID), error conditions (e.g., insufficient balance, rejected fee), and how the fee_per_byte and change_address parameters affect the operation. For a tool of this complexity, these gaps are notable and could leave an agent uncertain about expected outcomes.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents every parameter (wif, key_alias, fee_per_byte, change_address, etc.). The description adds minimal value beyond that – it reiterates the WIF requirement and the photon unit, which are already in the schema. Since the schema handles the heavy lifting, a baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear, specific action: sending RXD (photons) to an address. It goes further to outline the internal pipeline (fetch UTXOs, select coins, build, sign, broadcast), which distinguishes it from siblings like radiant_broadcast_transaction (broadcast only) or radiant_build_transaction (build only). The verb 'Send' plus the resource 'RXD' and the address make the purpose unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context: it sends RXD (not tokens), and it explicitly requires a WIF private key, which helps an agent decide when this tool is appropriate. However, it does not mention exclusions, such as using radiant_transfer_token for token transfers or radiant_send_batch for multiple recipients, so it lacks explicit 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.

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

With no annotations, the description carries the full burden of behavioral disclosure. It does disclose that the token UTXO must be at the sender's address and how to specify amounts for FT vs NFT, but it omits side effects such as spending the UTXO, creating/broadcasting a transaction, fee behavior, change-address handling, and whether a transaction ID is returned. It also says 'Requires a WIF private key' even though the schema allows key_alias as an alternative, slightly overstating the requirement.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is tight and front-loaded: the primary action is in the first sentence, followed by two crucial usage conditions. It wastes no words, though the final 'Requires a WIF private key' is slightly misleading given the key_alias alternative and could be more precise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a state-changing transfer tool with 7 parameters and no output schema or annotations. The description covers the token type and amount semantics, but it does not explain what happens upon success (transaction broadcast? txid returned?), the role of fee_per_byte and change_address, or that key_alias can replace wif. An agent would have to infer significant execution behavior from the schema alone.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds the FT/NFT distinction and restates base-unit/amount=1 semantics, but those are already present in the amount parameter's schema description. It does not add significant new meaning beyond what the schema provides, so it neither compensates nor detracts.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Transfer') and resource ('Glyph token (FT or NFT)') and names the action destination ('another address'), clearly distinguishing it from sibling tools like radiant_create_ft, radiant_create_nft, radiant_burn_token, and radiant_send_rxd. An agent can tell what this tool does without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage by stating what the tool does, and it provides important prerequisites ('token UTXO must be at the sender's address', 'Requires a WIF private key'), but it never names alternatives or when-not-to-use conditions. Given siblings like radiant_send_batch or radiant_build_transaction, explicit routing would be better; without it, usage is implied rather than clearly contrasted.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It states the direction of transfer but does not disclose side effects, whether the channel must already exist, whether the balances are mutated, whether the update is off-chain or on-chain, or what happens to the previous state.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no filler. It communicates the purpose and the payer-to-payee direction efficiently, and every phrase contributes to understanding the operation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a state-changing tool with nine required parameters and no output schema or annotations, this description is incomplete. It omits expected return behavior, prerequisites, whether the call mutates channel state permanently, and any nonce or timeout usage context that would help an agent invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so all nine parameters are already documented in the input schema. The description adds a payer/payee framing that reinforces the transfer semantics, but it does not add meaningful parameter-level detail beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description identifies a specific verb and resource ('Update a micropayment channel state') and explains the core action as transferring photons from payer agentA to payee agentB. It is clearly distinct from channel-opening tools like radiant_open_channel, though it does not explicitly name a sibling alternative.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided about when to use this tool versus alternatives, such as radiant_open_channel or transfer-related tools. There are no prerequisites, exclusions, or contextual cues beyond the tool's name, leaving the agent to infer usage from the operation name alone.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the core read-only behavior and a hint of the output (the address type), but it omits how invalid addresses are handled (error vs. false result), any return format, or network-specific behavior. For a simple validation tool this is acceptable but not fully transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is one concise sentence with no filler. The key action ('Validate') and key output ('show its type') are front-loaded, and every word earns its place. It is appropriately sized for a single-parameter tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no annotations, the description should explain both behavior and result semantics. It explains what the tool does and that it returns the address type, but does not clarify the result for invalid addresses, the exact return structure, or potential error conditions. This leaves meaningful ambiguity for an agent deciding how to interpret the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema covers the single parameter with 'Address to validate', and the description adds the Radiant-specific context and the type-checking behavior. This is meaningful but minimal; it does not specify expected format, encoding, or any constraints beyond what the schema already provides. Baseline 3 is appropriate given 100% schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Validate'), a clear resource ('a Radiant address'), and the tool's specific outcome ('show its type (P2PKH or P2SH)'). This distinguishes it immediately from siblings like radiant_derive_address or radiant_get_balance, so an agent understands exactly what this tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The intended use is implied: use this tool when you need to verify a Radiant address and learn its type. However, there is no explicit when-to-use guidance, no mention of alternatives (e.g., radiant_derive_address for generating addresses), and no exclusions. The context is clear but not elaborated.

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

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

No annotations are provided, so the description carries the behavioral burden. 'Validate/check' implies a non-mutating operation, but the description does not state the return shape (e.g., boolean vs. error details) or whether it consults chain state. This is a moderate gap, not a contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence with a helpful parenthetical clarification. The core action is front-loaded and there is no filler or redundant phrasing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter validation tool, the purpose and parameter are adequately covered. However, with no output schema and no annotations, the description does not state what a successful or failed validation returns, leaving some ambiguity about how to interpret the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already provides 100% coverage, describing protocols as an array of protocol IDs to validate. The description adds no additional parameter-level meaning, so the baseline score of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Validate') on a specific resource ('a Glyph protocol combination') and clarifies the intent with 'check if protocol IDs can be used together'. This distinguishes it from sibling tools like parse_glyph_envelope and get_protocol_info, which parse or retrieve rather than validate combinations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description makes the use case explicit: use it when you need to determine whether a set of protocol IDs is compatible. It does not name alternatives or state when not to use it, so it falls just short of full routing guidance.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It clearly states that the operation is off-chain and specifies the exact hashing algorithm and concatenation order used for verification. It does not mention return values or failure behavior, but the core behavior is well exposed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no filler. The primary purpose is front-loaded, and the technical detail about the hash check is compact and relevant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description captures the essential verification logic but omits what the tool returns (e.g., boolean true/false) or what happens on mismatch. Given no output schema and no annotations, a slightly fuller description would make the tool fully self-contained for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds extra value by explicitly defining the hash construction as 'blake3(modelHash || inputHash || output)', which clarifies how the parameters are combined and in what order.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action ('Verify'), a specific resource ('inference proof commitment'), and a defining detail ('off-chain'). It also names the exact check performed, making it clearly distinct from the sibling 'radiant_create_inference_proof' and other validation tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for verifying a commitment after one has been generated, but it does not explicitly say when to use it versus alternatives like 'radiant_create_inference_proof'. There is no exclusion guidance or mention of alternative tools.

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

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

With no annotations, the description carries the full burden. It discloses that the tool returns the current status hash, subscribes to future changes, and delivers notifications as ElectrumX push events. It could add subscription lifetime/cancellation details, but the core behavior is clearly conveyed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three dense sentences with no filler. The purpose is front-loaded, the return behavior is stated, and the polling alternative is included at the end—every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter subscription tool with no output schema, the description covers what it does, what it returns, and how notifications arrive. It is slightly incomplete around exact response shape and subscription lifecycle, but an agent can 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.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the parameter is already documented as a 'Radiant address to watch.' The description reinforces that it is a Radiant address but adds no new format or validation details beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Subscribe to real-time payment notifications for a Radiant address via ElectrumX scripthash subscription.' It clearly distinguishes itself from the sibling read tools by focusing on live watching/subscription rather than one-time queries.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Use this instead of polling for payment detection,' which gives a clear use case and an implicit when-not. It does not name a specific sibling alternative, so it falls just short of the highest bar.

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

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

With no annotations provided, the description carries the full burden. It implies a read operation (finding names) and does not mention any side effects, pagination, or error behavior. For a simple lookup, this is adequate but not detailed; it could disclose that it returns a list or that results are limited by the limit parameter.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that is front-loaded with the core purpose. There is no redundant wording or unnecessary detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a straightforward reverse lookup, the description is sufficient. It lacks an output schema, but the return (a list of WAVE names) is implied. It does not specify error cases or edge conditions, but given the low complexity, this is acceptable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% for both parameters, so the schema already documents address and limit. The description adds minimal value beyond implying address is the owner, which is already clear from the schema. No additional parameter-level semantics are provided.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'find' and the resource 'WAVE names' scoped to an owner address. It is concise and unambiguous, but does not explicitly distinguish it from sibling tools like radiant_resolve_wave_name (which does the opposite mapping). Still, the purpose is evident.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. It does not mention that this is the reverse lookup to radiant_resolve_wave_name, nor does it describe any prerequisite or context such as 'use this to list all names held by an address'.

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