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

With no annotations, the description carries the full burden, and it does so well. It discloses that the tool is free to call, that payment of $0.1 USDC on Base happens on the returned URL, and that the output is an x402 URL with a 402 → PAYMENT-SIGNATURE → delivery flow rather than direct data. This prevents the agent from assuming the tool itself returns the BASIC data synchronously.

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?

The description is front-loaded with the tool's subject and includes necessary cost, usage, and payment-flow details in a compact form. It loses a point because the opening sentence largely repeats the title and the abbreviation expansion could have been woven into the next sentence without much loss.

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 single-parameter tool with no output schema and no annotations, the description is remarkably complete. It covers the data source, what the measure includes, the intended timing before tendering, the cost, the payment location, and the exact return behavior, so an agent has enough context to invoke the tool and interpret its response.

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?

There is only one parameter, dot, and its schema description already covers it as 'USDOT number (required)', giving 100% schema description coverage. The tool description adds context about FMCSA carriers but no additional format or validation detail beyond the schema, so the baseline score of 3 is appropriate.

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 identifies the carrier's FMCSA Safety Measurement System BASIC measures as the resource and specifies the categories covered, such as unsafe driving and hours-of-service. It also distinguishes itself from carrier-authority-check by describing itself as 'the depth check behind' that flow, so an agent can tell which carrier-related tool is needed.

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?

The description gives explicit usage context: 'run both before tendering' and positions this tool as the depth check behind carrier-authority-check. It does not enumerate when not to use the tool or fully compare against all sibling tools, but the main decision point is clear enough.

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