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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds real scope context beyond annotations - 'active only' (a hidden filter) and 'Company facts only' (implying no contact/person data is returned) - but leaves pagination behavior and the meaning of 'last N days' unquantified.

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?

A single dense sentence front-loads the core resource and window, then lists filters. No filler. Slightly compressed parentheses ('active only', 'Company facts only') cost a bit of readability but earn their place.

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?

Insufficient evidence to score higher; with 7 parameters at 14% schema coverage and no output schema, the description should at minimum explain the days window semantics, the limit parameter, and what 'Company facts only' excludes from results. It gestures at these but leaves the agent guessing on defaults and result shape.

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 only 14% (just state), so the description carries real weight: it names state, cargo, hazmat, interstate and for-hire as filters, which covers five of seven parameters conceptually. However it omits 'limit' and never clarifies the days window bounds (1-90) or default of 7, nor any format for cargo/state beyond the schema's '2-letter code'.

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 resource and scope: FMCSA-added carriers within a rolling N-day window, active-only. An agent can distinguish this from vet_carriers and carrier_alerts by implicit function, but the description never names siblings or contrasts with them, so differentiation is inferred rather than stated.

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?

There is no when-to-use guidance or exclusion criteria. The filter list implies a prospecting/new-registration use case, but nothing tells the agent when to prefer this over carrier_alerts or vet_carriers, nor what happens if no filters are supplied.

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