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 discloses that values are raw base-unit strings, never floats, and warns that unknown denoms must not be scaled. This is meaningful behavior beyond a basic tool description, though it does not cover error cases or response shape in complete detail.

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 core purpose is front-loaded, and the critical formatting caveat is placed immediately after, making the most important operational detail prominent.

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 single-parameter tool, the description covers the essential return semantics and a key calculation constraint. Without an output schema, a bit more detail about the exact response structure could be helpful, but the provided information is sufficient for correct invocation and interpretation.

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% for the single required parameter, address. The description only repeats the parameter type ('terra1... bech32 address') and does not add new semantic meaning beyond the schema. The baseline of 3 applies because the schema already documents the parameter fully.

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 returns native token balances for a terra1... address and specifies the return type. It is specific enough to separate it from balance-related contracts, but it does not explicitly differentiate it from siblings like wallet_overview or contract_query.

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: use it when you need native token balances for an address. However, it does not explicitly state when to prefer this over wallet_overview or other sibling tools, nor does it mention exclusions such as contract or IBC balances.

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 of disclosure. It reveals that the supply value is a raw base-unit string exceeding 2^53 (BigInt), and that the canister accumulates snapshots into a public time series. It does not explicitly state it is a read-only operation, but the context implies it, and the large-number handling is a critical behavioral detail.

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 necessary technical caveats (BigInt) without fluff. Every clause adds value.

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 parameterless tool with no output schema, the description is reasonably complete: it specifies the returned data, its type, and the accumulation behavior. It lacks a note on authentication or exact output format, but these are minor given the simplicity.

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 is an empty object (100% coverage), so there is nothing to add. Per baseline, a score of 4 is appropriate for no-parameter tools.

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 snapshot) and resource (burn economics: burn_tax_rate and uluna supply), making the purpose clear. It does not explicitly differentiate from sibling tools like tax_params, but the content is distinct enough that an agent can infer its 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 explicit guidance on when to use this tool versus alternatives. It only states it is a point-in-time snapshot, but does not mention when it should be preferred over tax_params or other economic data tools, nor any exclusions.

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 does well by disclosing 'passthrough' behavior and 'raw JSON' output. 'Query' implies a read-only operation, and the smart-query envelope clarifies the expected request shape, though error or edge-case behavior is not mentioned.

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

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

A single sentence conveys the action, target resource, input format, and output format without wasted words. It is fully front-loaded with the core purpose before the supporting 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 two-parameter passthrough tool with no output schema, the description covers the essential details: input query envelope, target address, and raw JSON output. It does not explain failure modes or access restrictions, but for a generic read-only query tool these are not critical.

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 adds a critical detail the schema example does not: the query must be wrapped in a '{"smart":...}' envelope. This directly helps an agent construct valid input beyond what the schema alone shows.

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 ('run') and names the resource ('CosmWasm contract') plus the exact query envelope ('{"smart":{...}}'). 'Generic passthrough' also distinguishes it from more specialized sibling tools like balance or simulate_tx.

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 word 'generic' implies this is the fallback for arbitrary contract queries, but the description does not explicitly state when to prefer it over specialized siblings or when not to use it. Usage context is implied rather than directly 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 explicitly states 'Informational only — never authorization,' which is a strong guarantee that this tool does not perform any mutating or authorization actions. It also indicates the output is human-readable summary lines, giving the agent a clear expectation of the response type. While it does not mention error behavior or edge cases, the key behavioral trait (read-only, non-authorizing) is clearly 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 with no wasted words. The primary action and output are stated in the first sentence, and the critical caveat (informational only) is placed in the second. It is front-loaded with the essential purpose and includes only necessary details. Perfectly concise.

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 one parameter, no annotations, and no output schema, the description is sufficiently complete. It explains what the tool does, what the output looks like (human-readable summary lines with specific components), and its informational nature. It does not detail error handling or missing-transaction behavior, but for a read-only decoder this is acceptable. The description covers all essential aspects an agent needs 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 schema provides a 100% description coverage for the single parameter 'hash,' specifying it as a lowercase hex 0x-less 64-character string. The tool description only references 'by hash' without adding additional meaning beyond what the schema already provides. Since the schema fully documents the parameter, the description does not need to add more, so 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: 'Fetch a transaction by hash and decode it into human-readable summary lines.' It specifies the resource (transaction by hash) and the output format (summary lines with messages, amounts, fees, tax). This clearly differentiates it from siblings like simulate_tx (which simulates) and balance (which checks balances). The purpose is unambiguous and specific.

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: use this when you have a transaction hash and want a decoded human-readable summary. The phrase 'Informational only — never authorization' implies it is for reading, not for executing or authorizing, but it does not explicitly name alternatives or exclusions. There is no explicit when-not-to-use guidance, but the context is sufficient for an agent to infer its appropriate use.

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 states the query returns verified findings with evidence and verdicts, but doesn't disclose that status can be refuted/disputed/open, nor that repo is optional, nor any pagination or ordering. It doesn't contradict anything, but it's minimal. The word 'Query' implies read-only, but no explicit behavioral detail beyond that.

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, concise sentence that front-loads the resource and purpose. It efficiently communicates the core intent without unnecessary elaboration. The only minor waste is the phrase 'verified findings' which could mislead about status filtering, but overall it's tight 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?

For a simple query tool with two optional parameters and no output schema, the description gives enough to understand the domain and purpose. However, it doesn't explain the meaning of the status enum (beyond listing verified) or what repo refers to, leaving some ambiguity. It's adequate but not complete for an agent to call it with confidence.

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 0% and the description does not mention either parameter (repo, status) at all. The enum in the schema provides status values, but the description adds no meaning to what statuses mean or how repo should be formatted. Since there are 2 parameters and coverage is low, the description fails to compensate, leaving the agent without guidance.

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 uses a specific verb 'Query' and a specific resource 'attested audit finding registry (lunc-audit)', and clarifies content (evidence, repro commands, verdicts). It clearly distinguishes from sibling tools like balance or simulate_tx, which are unrelated. The slight ambiguity of 'verified findings' (since status includes refuted/disputed) is minor but doesn't undermine clarity.

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 use for audit findings but provides no explicit when-to-use or exclusions. It doesn't name alternative tools or conditions, even though siblings are clearly different domains. The context makes it obvious this is for audit registry queries, so a 3 is appropriate (implied but not explicit).

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

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 hints at conditional behavior ('when known') but does not state what happens for unknown hashes, whether this is a read-only operation, or what errors or empty results look like. The description is thin on behavioral detail beyond the basic lookup.

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 zero filler. It efficiently communicates the action, the input, and the output format in one pass, which is ideal for a simple lookup 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 tool, the description covers the core return format (path + base denom). It does not address behavior for unknown hashes, nor does it reconcile the base denom input case. The missing failure semantics and input mismatch leave the description slightly incomplete for a fully 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 baseline is 3. However, the description narrows the accepted input to 'IBC denom hash' while the schema explicitly allows 'ibc/... hash or base denom'. This contraction could mislead an agent into thinking base denoms are not valid, subtracting value rather than adding 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 states a specific verb ('Resolve'), a clear resource ('IBC denom hash'), and the expected output ('trace (path + base denom)'). This distinguishes it from the sibling tools, none of which relate to IBC denom tracing. The 'when known' qualifier is slightly ambiguous but does not obscure the core purpose.

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 guidance on when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. 'When known' is a behavioral condition, not usage guidance. With a sibling list present, the lack of differentiation is a meaningful gap.

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 discloses ordering, filter capability, and the inclusion of verified tally params, plus the API version rationale. It doesn't explicitly state read-only nature, but that's implied and 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?

The description is a single, information-dense sentence that leads with the core purpose, then provides rationale and extra parameters. No fluff 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?

While the description covers ordering, filter, tally params, and API version, it doesn't describe the return format or pagination behavior. Since there's no output schema, this is a gap, but the tool is simple and the provided context is reasonably complete for basic 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 'status' is an enum, and the description merely says 'status filter' without explaining the enum meanings or default behavior. The schema already provides the enum list, so the description adds little beyond what's in the schema, but the parameter is simple enough that this is acceptable.

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

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

The description clearly states the tool lists governance proposals, specifies ordering (newest first) and a status filter. It distinguishes itself from siblings by focusing on proposals, and no sibling appears to cover the same resource.

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 explains why gov/v1 is used over v1beta1, implying this tool is the correct choice for modern proposals. However, it does not explicitly name alternative tools or state when not to use this tool, though the sibling list doesn't suggest a direct alternative.

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 behavior disclosure. It conveys that this is a simulation (not a broadcast), that it uses the current rate, and that math is exact integer; however, it does not explicitly state side-effect-free behavior, error conditions, or response shape.

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 compact sentence with no filler: it names the operation, the accepted input format, the outputs, and a key computational detail. The important action and output 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 single-parameter tool with full schema coverage, the description is nearly sufficient. It clearly states the two expected outputs (estimated gas and burn-tax impact), though no output schema exists and exact return field names are left unspecified, which is a minor 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 covers the single parameter completely with 'unsigned tx JSON (amino style)', so the baseline is 3. The description reinforces 'amino JSON' and adds context about simulation and output, but it does not meaningfully extend what the 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?

The description states a specific action ('Simulate an unsigned tx') and a specific resource type ('unsigned tx (amino JSON)'), and specifies the outputs: estimated gas and burn-tax impact. This is concrete enough to be told apart from siblings like explain_tx or tax_params, even without naming 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 implies the intended use case: call this when you need gas and burn-tax estimates for an unsigned amino-format transaction. It also provides a clear input prerequisite ('unsigned tx (amino JSON)'), but it gives no explicit guidance about when to prefer an alternative sibling 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states that the tool returns parameters, gives the current value of burn_tax_rate (0.015), and specifies the gas-price table. It also corrects a common route error by explicitly noting the route is /terra/tax/v1beta1/params, which is behavioral context that prevents misrouting. It doesn't describe data format or error behavior, but for a read-only param fetch, this is adequate.

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

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

The description is compact: one sentence that packs the resource, fields, and a critical route correction. No fluff, and the most distinguishing detail (route) is front-loaded. Every word earns its place, making it efficient for quick parsing.

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 params, no output schema), and the description is sufficient for an agent to call it correctly. It identifies the exact route, the fields to expect, and a current value. The only gap is that it doesn't specify the response format (e.g., JSON structure), but given the simplicity and lack of output schema, this is a minor omission. The description is complete for practical purposes.

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 schema coverage is 100% (vacuous). The description explains what the tool returns (burn_tax_rate and gas-price table), which adds meaning beyond the empty schema. It also provides the current value of burn_tax_rate as an example, which helps the agent understand the output. With no params, the baseline is 4, achieved because the description adds context about the data structure.

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 resource (Terra Classic burn-tax parameters) and specifies the fields it exposes (burn_tax_rate and gas-price table). It distinguishes it from general Cosmos endpoints by explicitly stating the route is NOT /cosmos/..., which helps differentiate it from sibling tools like balance and validator_set. However, it doesn't name a specific sibling that it complements or differs from, but the route distinction is strong.

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: an agent would use this to fetch the burn tax rate or gas prices on Terra Classic. It gives the exact route, which is a clear usage directive. However, it doesn't explicitly state when to use this tool versus alternatives, such as when to use burn_snapshot for burn history or contract_query for other params. There's no exclusion or alternative mention beyond the route correction.

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 tokens are raw base-unit strings and rank is by integer power, which are helpful behavioral details. It does not explicitly state read-only or side-effect-free nature, but the wording implies a query. It adds value beyond the name.

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 concise sentence that front-loads the primary purpose ('Current active validator set') and appends necessary clarifications in parentheses. Every word earns its place; no fluff 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?

Without an output schema, the description should clarify the return structure. It mentions voting power and token format, but does not specify whether the result is a list or object, or include fields like validator address or moniker. For a simple tool with no params, it's adequate but could be slightly more explicit about the output shape.

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

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

The tool has zero parameters, so schema coverage is trivially 100%. The baseline for 0 params is 4, and there is no need for parameter explanation. The description appropriately avoids redundant parameter discussion.

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 resource (validator set) and the operation (returns current active set with voting power). It also specifies data format details (raw base-unit strings, integer power rank), which distinguishes it from generic list tools. No ambiguity.

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 it (to fetch validator set info) but does not explicitly mention alternatives or exclusions. Since it's a simple read-only query with no parameters, the usage is self-evident, but the lack of explicit routing to siblings like 'proposals' or 'balance' leaves 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes an 'Aggregate view' which implies read-only, but it never explicitly states that it performs no state changes, requires no special permissions, or has any side effects. The lack of explicit transparency is a gap for a tool that could be mistaken for a mutation.

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 that front-loads the core purpose and lists the included data types efficiently. There is no extraneous information or repetition, making it highly concise and easy to scan.

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 one parameter and no output schema, the description lists the key data categories but does not describe the output structure, formatting, or potential errors. It is adequate for a high-level understanding but lacks details an agent might need for precise invocation (e.g., whether results are paginated, units of balances, etc.).

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 coverage is 0%, and the only parameter is 'address' with no description. The tool description merely says 'of an address' without adding any format constraints (e.g., bech32), validation rules, or examples. It does not compensate for the schema's lack of documentation.

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 purpose: an aggregate view of an address covering native balances, delegations, unbonding, rewards, and authz grants. It distinguishes itself from the sibling 'balance' tool by including multiple data categories, making it clear this is a comprehensive overview rather than a simple balance lookup.

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 hints at a specific use case via the parenthetical '(agent-blast-radius check)', suggesting when to use it for security/permission assessment. However, it does not explicitly state when not to use it or mention alternatives like 'balance' for simpler queries. The usage context is implied but not formally guided.

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