Haulroll

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds genuine context beyond that: the 25-carrier cap and the 'empty = nothing new' result semantics. It does not mention what happens when more than 25 carriers are supplied or how results are ordered, so the extra value is moderate rather than rich.

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 densely packed sentence front-loads the resource and scope, then appends the result-interpretation rule. No filler, no repetition of the title, and every clause carries information.

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 two-parameter read-only query with no output schema the bar is low, and the description covers the scope and empty-result case. It is still incomplete on the two things an agent must know to call it correctly: the carrier identifier format and the days default/ceiling, neither of which appears anywhere else.

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%, so the description carries the burden, and it does partially: 'last N days' maps to the days parameter and 'up to 25 carriers' corroborates maxItems on carriers. However, it omits the days default (30) and bounds (1-365), and critically never specifies the identifier format expected in the carriers array (DOT vs MC number), which is the highest-value unknown for a 0%-coverage schema.

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 names a specific resource (FMCSA events) with a precise scope (last N days, up to 25 carriers) and enumerates the event categories returned (out-of-service orders, authority suspensions, insurance cancellations). An agent can tell what this returns without opening the schema. It stops short of naming or contrasting the siblings new_carriers/vet_carriers, so it is clear but not sibling-differentiating.

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 explicit when-to-use statement or routing against alternatives; the tool reads as a monitoring/alerts feed but the description never says 'use this to check for changes on existing carriers, use vet_carriers to screen new ones.' The only usage-adjacent hint is 'Empty = nothing new,' which is about interpreting results, not about selecting the tool.

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

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.

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 usefully adds the batch cap (1-25), the accepted identifier formats, and the result ordering ('Riskiest first'), which the annotations do not convey. It does not mention auth needs or behavior on invalid/missing carriers.

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 purpose and identifier formats, then lists the returned evidence, closing with the ordering rule. No filler or repetition of the 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?

With no output schema, the description correctly enumerates the returned field groups and their ordering, which is what an agent needs to consume the result. It stops short of describing failure handling for unparseable or unknown carrier numbers, a minor gap for a single-parameter read tool.

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 descriptions already give example formats, so the baseline is 3. The description adds value by naming additional accepted identifier types (MC/MX/FF dockets, not just USDOT/MC) and by restating the 1-25 range, slightly tightening the agent's input expectations.

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 gives a specific verb ('Verdict') and resource (US motor carriers) and then enumerates exactly what is assessed: USDOT status/age, authority, insurance, OOS orders, inspections and crashes. An agent can tell this apart from carrier_alerts and new_carriers without opening the 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?

Usage is implied by the vetting framing and the explicit '1-25 carriers' batch scope, but there is no statement of when to prefer this over the sibling tools or what prerequisites (e.g., valid registration numbers) apply. Adequate but leaves the alternative selection to inference.

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