Analyze Obyte Unit

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

Annotations already mark it read-only, non-destructive, and idempotent, and the description adds substantial behavioral detail beyond that: it serves both Obyte networks at once, amounts are raw smallest units, output is hub data in a stable JSON envelope, and raw integers must not be shown to users. This is rich, non-obvious context that helps the agent invoke and interpret results correctly.

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 key purpose, then adds network and amount guidance in logically grouped paragraphs. Every sentence carries functional weight, including the user-facing formatting rule. It is detailed but not padded.

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?

Despite having no output schema, the description tells the agent what kind of output to expect ('stable JSON envelope'), how to handle networks, and how to handle raw amount values. It also give a concrete trigger for invocation. This is enough for reliable selection and correct calling.

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%, but the description compensates fully. It explains the unit hash format ('44-character base64 string, usually ending in "="'), the network parameter values and default, and the behavior of include_aa_response_chain ('follows the AA response chain for trigger units'). The agent receives actionable meaning for all 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 is explicit: it is the 'Recommended tool whenever the user pastes an Obyte unit hash... or asks about an Obyte transaction', and it names its core action: 'Fetches the joint and, when requested, follows the AA response chain'. This clearly identifies both the resource and the operation, making it distinguishable from the many sibling 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 gives strong usage context: when to use it, what it does, and how to handle network ambiguity ('If the user has not made the network explicit, confirm which network they mean before calling'). It does not explicitly list exclusions or compare itself to siblings like obyte_get_joint, but the 'Recommended tool... whenever' phrasing effectively establishes its primary role.

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