Resolve Obyte Asset

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

Beyond the read-only/idempotent annotations, the description reveals concrete behavior: symbols are uppercased before lookup, asset IDs are case-sensitive, network defaults to mainnet when omitted, unregistered symbols return null asset/symbol with a note, and registry mappings are only convenience metadata. These details materially affect how an agent should interpret results and make the tool safer to use.

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 front-loaded with the tool's role and input formats, then covers return behavior and network selection in compact paragraphs. Every sentence contributes either a behavioral rule or an actionable instruction; no filler or repetition is present.

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 resolver with no output schema, the description covers accepted inputs, return fields on both success and missing-symbol cases, network selection, and a safety caveat about registry legitimacy. The main gap is the undocumented `token_registry_address` parameter, which prevents the description from being 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?

With 0% schema description coverage, the description compensates well for `value` by defining accepted formats and case rules, and for `network` by listing the enum values, default, and a confirmation requirement. However, `token_registry_address` is never mentioned, leaving its purpose and relationship to 'selected network's registry' unexplained.

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 says it is the 'Recommended tool for resolving an Obyte asset id (44-character base64 string) or token symbol' in the network's registry, giving a specific verb, resource, and accepted input forms. It also distinguishes itself as recommended and names the related obyte_get_decimals_by_symbol_or_asset as an alternative, so an agent can tell when this tool is intended.

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 an explicit trigger: 'Always call this (or obyte_get_decimals_by_symbol_or_asset) before presenting amounts of unknown assets to users.' It also instructs the agent to confirm which network the user means when it isn't explicit, and states the default. That is actionable when-to-use guidance with an alternative, though it doesn't exhaustively enumerate when not to call the sibling symbol/asset lookup tools.

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