Get AA Response Chain

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds substantial behavioral context beyond that: it reveals that the server serves both Obyte networks at once, what the default network is, and that raw amounts are integers in smallest units with explicit instructions for how to display them. This goes well beyond what annotations provide.

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 opens with a one-sentence purpose, then uses two clearly labeled paragraphs for network and amount handling. Every sentence carries operational weight, and the headings make it easy to scan. No redundant 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?

Because there is no output schema, the description must convey return-value meaning. It says the tool returns the response chain and describes the amount fields (display_total, raw integers), which is helpful. It could still clarify what a 'response chain' contains, but the essential calling requirements—trigger_unit, network selection, and amount interpretation—are covered.

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%, so the description must compensate. It explains the network parameter thoroughly, including enum values, the default, and the confirmation rule. However, trigger_unit is only described as 'a trigger unit' with no extra semantic detail such as what kind of unit, how it is used, or expected format beyond the schema constraints. Partial compensation.

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 ('Returns'), a specific resource ('autonomous-agent response chain'), and the key input ('trigger unit'). The phrase 'Raw hub read' signals a low-level read operation, which helps distinguish it from more analytical tools, though it never explicitly contrasts it with the sibling obyte_get_aa_responses.

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 network-selection guidance: it explains that both networks are served, that mainnet is the default, and that the agent should confirm the network with the user if not explicitly stated. However, it does not say when to use this tool versus alternatives like obyte_get_aa_responses or obyte_dry_run_aa, so tool-selection guidance is only implied.

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