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

Goes well beyond the annotations by disclosing that results come from stored snapshots (not live data), that access requires Pro/Business plans, and that billing is one lookup per unique identifier — all critical for cost and freshness decisions. Annotations already cover read-only/idempotent/non-destructive, and the description adds the operational context they can't express.

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?

Three tight sentences, each carrying distinct payload (scope, result parity, cost), with the capability and cap front-loaded. No 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?

With no output schema, the description usefully names the return fields (verdict, verdict_reasons, verdict_basis), and it covers the plan gate and cost model. It omits what happens to identifiers that aren't found or the snapshot's staleness window, which would matter for a batch tool prone to partial results.

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 coverage is 100% and the format example ('MC123456') lives in the schema, so the baseline is met. The description adds real meaning by saying the cap applies per call and that cost accrues per unique identifier, implying duplicates aren't double-billed — a subtlety the schema doesn't encode.

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 specific verb (look up) and resource (USDOT/MC numbers) plus a hard batching bound of 500 in one call, and explicitly ties its output to lookup_carrier's verdict fields. This lets an agent distinguish it from lookup_carrier and search_carriers without opening a 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?

Clearly frames the batch context and names the plan prerequisite (Pro and Business plans) that gates access, and references lookup_carrier as the single-item equivalent. It stops short of an explicit 'use lookup_carrier instead when you have one identifier' exclusion, so the alternative is implied rather than stated.

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