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

Annotations already cover readOnly/idempotent/non-destructive and openWorld, so the marginal bar is higher. The description still adds real, non-obvious behavior: the PASS/REVIEW/FAIL verdict derivation rules, the 1-lookup cost, and the receipt_id side effect allowing later retrieval via get_receipt — none of which the annotations convey.

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 verb, resource, and inputs; supporting facts (verdict logic, mutual exclusivity, receipt, cost) follow in tight order with zero filler. The verdict sentence is a dense run-on with nested conditionals, which costs a little readability.

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, so the description carries the return-value burden and does: it lists profile fields, explains the verdict and verdict_reasons, and notes the receipt_id. For a 2-param read-only lookup, nothing an agent needs 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?

Schema coverage is 100% and both parameter descriptions include examples and formats. The description nonetheless adds a constraint absent from the schema — exactly one of dot or mc must be supplied, since neither is marked required and there is no oneOf — which is genuinely useful disambiguation.

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 and resource (get a US motor carrier's FMCSA profile) and enumerates the exact identity inputs (USDOT number or MC/FF/MX docket) plus the payload returned. An agent can distinguish it from search_carriers or batch_lookup without opening any 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?

'Pass exactly one of dot or mc' plus 'Costs 1 lookup' give clear invocation and cost context, and the get_receipt sentence establishes the follow-up workflow. It stops short of naming alternatives (batch_lookup for many carriers, search_carriers for name-only lookups), so the when-not branch is left implicit.

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