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

Annotations already declare readOnly, idempotent, non-destructive, so the safety profile is covered. The description adds genuinely non-redundant context: a per-call price of $0.001 USDC via x402 on Solana, and a parallel HTTPS endpoint — critical for an agent deciding whether to call. It stops short of stating error behavior for out-of-range n or rate limits.

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?

Front-loaded with the core semantics and a compact example, then ranges, then pricing/endpoint metadata. Slightly over-specified where it repeats schema limits, but every sentence contributes.

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?

No output schema exists, and the description fully specifies return values (-1, 0, 1) plus the out-of-range-returns-0 rule, so the agent knows exactly what comes back. For a simple two-parameter read tool, nothing needed to call it correctly is missing.

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 must carry the load, and it does: place is defined as counting from 0 at the right, both value ranges are restated, and the edge case (a place past the end yields 0) is spelled out. The worked example resolves any remaining ambiguity about place indexing.

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?

States a concrete verb+resource: extracting the balanced ternary digit of n at a given place, returning -1/0/1, and clarifies with a worked example (5 = "1TT"). It is clearly distinguishable in practice from siblings like balanced_ternary or ternary_len, though it never names or contrasts them explicitly.

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?

Usage is implied through the example and the out-of-range rule, so an agent can infer correct invocation. However, there is no explicit when-to-use/when-not guidance and no mention of when balanced_ternary, ternary_value, or ternary_len would be the better choice despite dozens of closely related siblings.

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