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

Annotations already declare readOnly/idempotent/non-destructive, so credit is for what the text adds: the arithmetic invariant ("cost moved + cost remaining = total cost exactly"), exact-decimal behavior, the >1 year holding-period labeling, and the tax-advice disclaimer. These are real behavioral expectations an agent could not read off the annotations. It stops short of describing output shape (though an output schema exists) or the 20-lot cap surfaced in errors.

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 core sentence is well front-loaded and dense with useful facts, but the trailing three sentences are procedural boilerplate ("Follow its required fields and exact choices") or confusing references to a REST calculator field. Roughly a third of the text does not earn its place, and key content is buried mid-sentence.

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, deeply nested calculation tool with an output schema, the description covers purpose, methods, numeric guarantees, and argument nesting — enough to call it correctly. Missing pieces are the treatment of fees and the lot-count limit, both of which the schema encodes but does not explain semantically.

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 schema is unusually self-documenting: nested required fields, date patterns, method enums, specific-lot sub-objects, and a worked example. The description adds only the enumeration of methods and the instruction to nest arguments under `inputs`. It says nothing about how fees affect basis, how `specific` lot references must be formed, or the maxItems limit — and the phantom `units` mention is a detractor.

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?

"Lot accounting for crypto... realized gain/loss per disposal" names a specific computation plus the four supported methods and the outputs (remaining lots, average cost, holding-period label). An agent can tell this is a crypto cost-basis calculator rather than a payment/fee/ABI tool. It does not explicitly contrast itself with any sibling such as buscalc_chain_impermanent_loss, so it falls short of a 5.

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 only guidance is argument-plumbing ("Put tool fields inside inputs", "Follow its required fields") plus a "not tax advice" disclaimer. There is no statement of when to pick this over alternatives, no prerequisites, and no exclusion cases. "Supply units or modelVersion only when listed in inputSchema" is actively unhelpful because no `units` field exists in the schema, forcing the agent to resolve the mismatch itself.

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