freight-intel

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It describes the output as a 'full safety + contact profile' but does not explicitly state that this is a read-only operation, nor does it mention any side effects, rate limits, or authentication requirements. Given the simplicity of a lookup tool, the description is acceptable but could be more transparent about the read-only nature.

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, clear sentence that front-loads the core functionality ('Full safety + contact profile') and lists key return fields. No unnecessary words.

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 tool has one parameter and no output schema. The description lists what fields are returned (identity, fleet, authority status, etc.) but does not specify the return structure (e.g., JSON object) or whether it returns a single result. Given the context of sibling tools and the lack of output schema, the description is functional but could be more precise about the output format.

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 covers 100% of parameters (the 'dot' field is described as 'USDOT number'). The description merely restates 'by USDOT number' without adding format, validation rules, or examples. Since baseline is 3 when schema coverage is high, this 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 clearly states the tool's purpose: retrieving a full safety and contact profile for a single carrier by USDOT number. It lists specific fields (identity, fleet, authority status, etc.), and the verb 'lookup' is implied. This differentiates it from siblings like carrier_risk_lookup (risk-focused) and safety_screen (screening), which have narrower scopes.

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 no explicit guidance on when to use this tool versus alternatives such as 'carrier_risk_lookup' or 'safety_screen'. It does not mention prerequisites, edge cases, or when not to use it. The only usage hint is that it requires a USDOT number, which is already in the schema.

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 fully discloses behavior: returns out-of-service rate vs national average, inspection history, etc. Mentions 'Honest-null with a 'no roadside inspection history' flag for brand-new carriers' and states it's a transparent triage signal, not a guarantee. This covers edge cases and limitations.

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?

Description is well-structured with the purpose upfront and details following. It is concise for the information provided, though a few phrases (e.g., 'A transparent triage signal...') could be condensed without losing meaning.

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 one parameter, no output schema, and no annotations, the description covers all necessary context: return values, edge cases, usage domain, and limitations. The alias mention ties it to sibling tools. No gaps are evident.

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 input schema already describes the sole parameter 'dot' as 'USDOT number.' The description only confirms 'by USDOT number,' adding no extra semantic value (format, length, examples). Since schema coverage is 100%, baseline 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?

Description clearly states the tool's purpose: risk-screening one carrier by USDOT number for insurance underwriting/factoring vetting. It lists specific outputs (out-of-service rate, inspection history, FMCSA rating, authority+insurance status, flags) and mentions it's an alias of safety_screen, distinguishing it from sibling tools like carrier_lookup.

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?

Description specifies the domain (insurance underwriting/factoring vetting) and advises verifying against SAFER for underwriting decisions. However, it doesn't explicitly contrast with sibling tools like chameleon_check or switch_signal, though the alias with safety_screen implies interchangeability.

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 reveals key behavioral traits: it returns a 0-100 score and match basis, down-weights filing agents, and is intended as a review signal. It does not document auth requirements or side effects but covers the core behavior well.

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, well-structured paragraph that front-loads the core concept, specifies the output, and adds context. Every sentence adds value without redundancy.

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 explains the return value and high-level logic, but lacks parameter details entirely. Given no output schema, the description should have elaborated on parameters to be considered fully 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 input schema has three parameters (limit, state, minScore) with no descriptions, and the tool description provides zero explanation of their meaning, usage, or defaults. With 0% schema description coverage, the description does not compensate.

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's purpose: detecting likely reincarnations of deactivated carriers using phone/address matching. It specifies the output (0-100 score + match basis) and distinguishes it from generic lookup tools by naming the specific entity-resolution task.

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 notes it's a review signal, not proof of fraud, and mentions that filing-agent clusters are down-weighted. However, it does not provide explicit guidance on when to use this tool versus alternatives like search_carriers or safety_screen, leaving the agent to infer relative context.

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 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.

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

With no annotations, the description carries full burden. It extensively details output fields (USDOT, name, safety layer, etc.), notes honest null handling, and mentions data source (public FMCSA census), but omits rate limits or pagination behavior.

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 paragraph that front-loads the purpose, then lists output fields and filters, with no redundant sentences. It is slightly long but every sentence adds value.

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 comprehensively explains return values and their context. It covers all key aspects for a feed tool, though it lacks details on pagination and error handling.

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%, and the description adds meaning by grouping filters (state, fleet size, since-date, hasEmail, forHire, financeable, insured) and explaining the purpose of 'financeable' as a verdict filter, exceeding what the schema 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 tool returns a feed of newly-authorized US motor carriers, newest first, and explicitly distinguishes itself as an alias of 'new_authority_feed', setting it apart from sibling tools like carrier_lookup and 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 identifies the target audience (insurance agents, factoring companies, vendors) and lists available filters, but does not explicitly state when not to use this tool or compare it directly to alternatives beyond the alias note.

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 the full burden. It discloses what the tool checks (live records plus internal layers) and what it returns (triage verdict and specific flags). It does not mention side effects (e.g., external API calls) or permissions, but the behavioral impact is well-explained.

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 coherent sentence front-loaded with the action and resource, followed by return details and use case. The closing demo sentence adds mild redundancy but does not waste space. Highly structured and readable.

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?

Despite lacking an output schema, the description enumerates the returned flags and verdict, providing essential context for interpreting results. The use case is clarified. Missing details like synchronous behavior or rate limits, but overall sufficient for the tool's modest complexity.

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 single parameter 'carriers' is fully described in the schema with coverage 100%, and the tool description adds specific identifier types (USDOT numbers and/or MC/docket numbers), enhancing understanding beyond the schema. This exceeds the baseline of 3.

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 verb 'Re-grade', the resource (list of carriers), and the specific data sources (FMCSA/L&I, switch-signal, chameleon layers). It also lists return flags and the target use case (factoring companies vetting lead lists), effectively distinguishing it from sibling tools like carrier_lookup (single carrier) or chameleon_check (single check).

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 ties usage to 'factoring companies vetting their own lead list,' providing clear context. However, it does not explicitly exclude alternative tools for single carrier lookups or other risk assessments, relying on the tool name and sibling list to imply 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 transparently discloses the data source (public FMCSA data) and explicitly states the output is 'not a guarantee'. It implies a read-only operation with no destructive side effects, which is adequate for a risk assessment tool.

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 two sentences, concise and front-loaded with key information. Every part adds value: the purpose, the data elements, the source, and the disclaimer. No unnecessary words.

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 tool's simplicity (single required parameter, no output schema), the description provides complete context: what it does, what data it uses, and what it returns. No gaps remain for an agent to use it correctly.

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 a USDOT number. The description mentions 'by USDOT number', adding meaning to the otherwise unadorned schema (0% coverage). This clarification is sufficient for correct usage.

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 using USDOT number, listing specific data points (out-of-service rate, inspection history, FMCSA rating, authority status, flags). It distinguishes its purpose for insurance underwriting/shipper vetting, though it does not explicitly differentiate from sibling tools like carrier_risk_lookup.

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 (insurance underwriting / shipper vetting) but does not provide guidance on when not to use the tool or suggest alternatives among siblings. The context is clear but lacks explicit exclusions.

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 returns pre-qualified, lead-ready rows and lists filters, but it does not disclose any behavioral traits such as pagination, performance characteristics, rate limits, or permissions. The description gives a reasonable overview but lacks depth.

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 two concise sentences with no redundant information. The first sentence lists filters, the second explains the output and provides a key alternative. Every word earns its 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?

Given the complexity (9 parameters, no output schema), the description is quite terse. It vaguely describes return value as 'pre-qualified, lead-ready carrier rows' without specifying structure, pagination, or ordering. While it provides a helpful sibling distinction, it 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?

With 0% schema description coverage, the description must compensate. It explains the purpose of most parameters conceptually (e.g., state, fleet size, since-date, has-email, forHire, financeable with valid values, insured), but does not cover 'limit' or specify formats for 'since' and 'state'. It adds value but is not fully comprehensive.

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 searches the 'new-authority carrier set' with specific filters and returns pre-qualified rows. It distinguishes itself from the sibling 'carrier_lookup' by noting that arbitrary DOT searches should use that tool instead.

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 provides an alternative for arbitrary DOT searches ('For an arbitrary DOT use carrier_lookup'), giving clear context for when to use this tool. However, it does not mention any prerequisites or scenarios where this tool would be inappropriate beyond that.

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?

Since annotations are absent, the description carries the full burden and discloses key behaviors: partial UCC coverage marked honestly, empty terminated list is truthful, default type behavior, and the rarity of UCC-3 terminations. This adds significant context beyond the schema.

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 verbose, dense with domain jargon, and lacks clear structure. It uses stream-of-consciousness style (e.g., 'PRIMARY = VIRGIN: a fresh authority...') rather than concise, front-loaded sentences.

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 covers type, state, default behavior, and data honesty, but does not explain the output format (no output schema) or the role of the 'limit' parameter. For a tool with 3 params and no annotations, this is adequate but not 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?

Schema coverage is 67% (type and state described). The description explains the meaning of 'virgin' and 'terminated' and the default when type is omitted, adding value beyond schema. However, the 'limit' parameter is not mentioned at all.

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 states the tool is a 'real-time factor-SWITCH lead feed' but does not use a clear verb like 'list' or 'get'. The purpose is implied but obscured by jargon, making it less accessible for an AI agent.

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?

No explicit guidance on when to use this tool versus sibling tools (e.g., new_authority_feed, search_carriers). The description contrasts with 'static annual UCC buckets' but does not mention alternatives or exclusion criteria.

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