dero_get_encrypted_balance

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

Beyond the readOnlyHint annotation, the description discloses essential behavioral context: the returned bytes are encrypted and not a cleartext balance, only a wallet holding the spend key can decrypt, and the tool should never present encrypted bytes as a balance to the user. It also explains the meaning of topoheight=-1 and scid handling, adding significant value beyond the annotations.

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 well-structured with clear section labels (CRITICAL, When to call, Input Requirements, Output) and front-loads the most important caution about encrypted bytes. Every section contributes necessary operational guidance, and the length is justified given the tool's cryptographic sensitivity and domain 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?

The description is complete for most invocation needs: it explains input constraints, output shape, and the critical caveat about encryption. Since there is no output schema, the explicit output summary helps. It could be slightly more complete by describing the registration field or providing an example, but the current level is sufficient for correct tool use.

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%, but the tool description adds crucial semantic details: address must start with dero1 or deto1, topoheight -1 means latest chain tip, and scid should be omitted for native DERO while 64-hex SCID is for assets. These are not fully expressed in the schema and materially improve correct invocation.

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: 'Get the ENCRYPTED balance blob for a DERO address at a topo height via DERO.GetEncryptedBalance.' It immediately disambiguates the result as an opaque encrypted blob rather than a cleartext balance, which clearly distinguishes this tool from any balance-returning sibling. The mention of the RPC method adds precision.

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 explicitly provides 'When to call' guidance, including verifying on-chain encrypted state, use before transfers, and as a sub-step in another tool. It also recommends citing dero_docs_search for user understanding. However, it does not explicitly specify when not to call it or name a direct alternative, so it lacks a full when-not/exclusion statement.

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