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

With no annotations provided, the description carries the full burden. It details the tool's read-only nature (returns data) and explains the derived data fields and sources (FMCSA census + L&I). However, it does not address potential side effects, permissions needed, or rate limits, though for a read-only endpoint this is less critical.

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 four sentences, front-loading the core purpose, then explaining the value and listing filters. Every sentence contributes meaningful information without redundancy. It is well-structured and easy to parse.

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?

Given no output schema, the description describes the return fields (financeable verdict, forHire, authorityStatus, etc.) and data sources, which is sufficient for most agents. It also mentions ordering ('newest first'). However, it does not explicitly mention default limit or pagination behavior, which is a minor gap.

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?

The schema has 78% description coverage. The description adds meaning by summarizing filter categories (e.g., 'fleet size' covers minPowerUnits/maxPowerUnits) and reiterating key parameters. While the schema already describes most parameters, the description ensures clarity for the fleet size and financeable filters, adding value for agents.

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 clearly states the tool returns US trucking carriers newly granted FMCSA operating authority, newest first. It specifies the resource (new authority carriers) and the verb (return/list). Among sibling tools like 'carrier_lookup' and 'search_carriers', this tool is uniquely positioned to provide the 'newly granted' feed, making its purpose distinct.

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 explicitly frames the tool as a broker/factoring lead signal, indicating when to use it (for identifying newly authorized carriers with financeable attributes). It does not, however, provide guidance on when not to use it or compare directly with alternatives like 'search_carriers' for general queries, but the context is clear.

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