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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile needs no restating. The description adds genuinely new behavioral content: the response is the entire record (not a page), fields come back in Nero Work's own naming, and branding plus nero_trade_ref are included — useful since there is no output schema. It omits volume/size expectations for a 'full' export, which would matter in practice.

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?

One sentence, front-loaded with the verb and the returned content, with the purpose trailing as a subordinate clause. The parenthetical list is dense but each item is informative; nothing repeats the annotations or title.

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 one-parameter, read-only export with rich annotations, the description covers what comes back and why. The remaining gap is the output format and whether 'full record' implies size limits or a single unpaginated response — relevant given there is no output schema.

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 a single parameter at 100% schema description coverage, the schema already explains that trade_key is the value register_trade returned and that it starts with nrk_. The description adds no meaning beyond that, so the baseline of 3 applies.

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 opens with a specific verb and resource ('Returns the business's full record') and then enumerates the scope — every logged job, every rating, totals, branding, nero_trade_ref. That enumeration plus the 'full record vs. filtered views' framing distinguishes it from siblings like list_reviews and my_score without the agent needing to open either schema.

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?

It gives clear context for when this is the right call — loading the history into Nero Work or keeping a backup — which implies 'use this when you need the complete dataset for migration/archival.' It does not name an alternative or state exclusions (e.g., use list_reviews for paginated browsing), so it stops short of full when/when-not guidance.

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