freight-intel

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

No annotations are provided, so the description carries the full burden. It discloses that the tool returns a comprehensive profile including identity, fleet, authority, safety, rating, and contact details. However, it does not mention potential limitations such as data freshness, permission requirements, or error handling for invalid DOT numbers.

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 a single, front-loaded sentence that efficiently conveys the tool's purpose and output. Every word adds value, and the list of data categories is clear and concise.

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 the simple parameter set (1 required string) and no output schema, the description provides a detailed list of returned information, which is sufficient for basic usage. However, it could be improved by mentioning error scenarios or whether the data is real-time, but it is otherwise complete.

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 provides 100% coverage for the single 'dot' parameter with a description of 'USDOT number.' The description reinforces this by stating 'by USDOT number' but adds little additional semantic meaning beyond what the schema already provides.

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 action (lookup by USDOT number) and resource (carrier profile). It explicitly lists the returned data categories (identity, fleet, authority, safety, rating, contact) and distinguishes itself from siblings like 'search_carriers' by specifying 'for one carrier'.

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 implies use when a USDOT number is available to retrieve a full profile, but it does not explicitly state when to use this tool versus siblings like 'search_carriers' or 'safety_screen', nor does it provide exclusions or prerequisites.

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?

With no annotations, the description carries full burden. It discloses the matching logic (phone/address with deactivated carrier, down-weighting of filing agents) and the output nature (0-100 score + match basis). It does not mention side effects or permitted actions, but the read-only nature is implied.

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 brief and front-loaded with the tool's purpose. It covers key aspects in a few sentences, but could benefit from clearer structure, such as listing parameters and usage notes.

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 the absence of annotations, output schema, and parameter documentation, the description provides reasonable context for the tool's purpose and behavior. However, the lack of parameter information limits its completeness for effective invocation.

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 3 parameters with 0% schema description coverage. The description does not explain any of the parameters (limit, state, minScore) or their semantics, leaving the agent to infer usage from context.

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 it performs chameleon/reincarnation entity-resolution, returning a score and match basis. It differentiates from sibling tools by its specific focus on detecting reincarnations, but does not explicitly contrast with other tools.

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 implies use as a review signal ("A review signal, not proof of fraud") but does not provide explicit guidance on when to use it versus alternatives, or when not to use it.

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?

With no annotations, the description carries full burden. It explains data derivation from FMCSA census + L&I datasets and lists returned fields (financeable, forHire, etc.), but does not mention read-only nature, rate limits, or potential side effects. The transparency is good but not exhaustive.

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 three sentences with no wasted words. The first sentence states core purpose and ordering, second explains the lead signal, third lists data fields and filters. Well-structured and front-loaded.

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 explains return fields (financeable, forHire, etc.) and derivation. It covers filtering options. Lacks mention of pagination or default limit 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?

Schema coverage is 78%. The description adds meaning beyond schema by grouping filters and explaining the financeable verdict and forHire concept. For undocumented parameters (maxPowerUnits, minPowerUnits), it provides context via 'fleet size'. Overall, adds significant semantic value.

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 broker/factoring lead signal and differentiates from siblings like carrier_lookup and search_carriers by focusing on new authorities.

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 implies usage for finding new carriers eligible for factoring ('each carrier just became able to legally haul'), but does not explicitly state when not to use or list alternatives. The context of sibling tools aids differentiation.

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?

No annotations are provided, so the description carries the full burden. It discloses that the tool checks live records and proprietary layers, and lists possible return flags. However, it lacks details on error handling, input validation, rate limits, or what happens with invalid carriers. For a tool with no annotations, more behavioral context is needed.

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 extremely concise: two sentences that front-load the action and output. Every word adds value, and there is no redundancy or fluff.

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?

The description lists possible return flags but does not specify the overall structure or format of the response. Given that there is no output schema, this leaves uncertainty about the exact return object. It is adequate for a simple list tool but could be more complete.

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 provides a 100% description of the single 'carriers' parameter. The description adds context by specifying that identifiers are USDOT numbers and/or MC/docket numbers, which aligns with the schema description. It does not add substantial new meaning beyond the 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 clearly states the tool re-grades a list of carriers against live FMCSA/L&I records and proprietary layers, returning specific flags. It mentions identifiers (USDOT/MC) and the target audience (factoring companies). However, it does not explicitly distinguish this from sibling tools like chameleon_check or switch_signal, which likely provide parts of this functionality.

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 implies usage for vetting a list of carriers, but it does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention when not to use it. No prerequisites or exclusions are stated.

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?

No annotations are provided, so the description carries the full burden. It states the tool is a 'transparent triage signal from public FMCSA data' and lists the data components, implying a read-only informational operation. However, it does not explicitly declare it as non-destructive or detail any side effects.

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 moderately concise (three sentences), front-loading the primary purpose. It could be slightly shorter, but every sentence adds value (purpose, data elements, disclaimer).

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 or annotations, the description covers the input, purpose, data sources, and limitations. It provides enough context for a simple risk assessment tool, though it lacks explicit differentiation from siblings.

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 only parameter 'dot' is explained in the description as 'by USDOT number', compensating for the 0% schema description coverage. This gives the agent clear meaning beyond the schema's basic string type.

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 provides a 'risk verdict for a carrier by USDOT number' with specific data elements (out-of-service rate, inspection history, etc.), and explicitly ties it to insurance underwriting/shipper vetting. This distinguishes it from sibling tools like carrier_lookup or search_carriers.

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 specifies the use case ('for insurance underwriting / shipper vetting') and adds a caveat ('not a guarantee'). However, it does not provide explicit exclusions or mention alternative sibling tools, leaving the agent to infer when to choose this over others.

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?

As a search tool, read-only behavior is implied. The description discloses that it returns pre-qualified, lead-ready rows and lists the filter criteria. Without annotations, it could be more explicit about being read-only, but it adequately describes the operation.

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?

Two sentences: the first efficiently lists the filter criteria, the second states the return type and provides a usage alternative. No redundancy, front-loaded 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?

Given 9 parameters with no descriptions and no output schema, the description covers the core functionality well. It could mention pagination, error handling, or further details on the return rows, but it is adequate for a search 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?

Despite 0% schema description coverage, the description lists most parameters (state, fleet size, since-date, has-email, forHire, financeable verdict with enum hints, insured). It misses the 'limit' parameter but adds meaning beyond the raw schema by explaining filter options.

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 it searches the 'new-authority carrier set' with specific filters and returns 'pre-qualified, lead-ready carrier rows'. It also distinguishes from the sibling 'carrier_lookup' by noting the alternative use case for arbitrary DOT.

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 provides a clear alternative for when to use 'carrier_lookup' (for arbitrary DOT), giving context on when this tool is appropriate. However, it does not explicitly exclude other siblings or provide when-not-to-use conditions.

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?

Without annotations, the description carries full burden and does well by disclosing data quality nuances: partial UCC coverage, honest handling of non-covered states, and the rarity of terminated leads. It also clarifies that an empty terminated list is not a dead feed.

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 core concept and efficiently packs essential details. While dense, every sentence adds value, though it could be restructured slightly for easier parsing.

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 could be improved by specifying the output format (e.g., list of leads). It covers purpose, parameter behavior, and data caveats well but omits what the user receives.

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 description adds significant meaning beyond the schema for 'type' (explains default) and 'state' (discusses coverage). The 'limit' parameter has no description in schema or description, but overall added value is high given 67% coverage.

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 identifies the tool as a real-time lead feed for UCC lien status changes, distinguishing between virgin and terminated types. It explains the advantage over static annual data, but does not explicitly differentiate from sibling tools like 'new_authority_feed'.

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 provides context for when to use the tool (real-time needs) and explains default behavior and filtering options. However, it lacks explicit comparisons to sibling tools or guidance on when not to use it.

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