freight-pulse

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

With no annotations, the description fully discloses behavioral traits: it's model-based, not live; uses port congestion and slot scarcity models; provides indicative results; mentions premium payment (USDC or prepaid key). It honestly states limitations and how it works.

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 informative but verbose. It front-loads the main purpose, then includes lengthy explanations of outputs and examples. While all content is valuable, it could be more concise for faster 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 the complexity (7 parameters, no output schema), the description is very complete. It explains what the tool returns (optimal window, sequence, D&D savings) and provides examples for congested vs fluid ports. No gaps identified.

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%, so baseline is 3. The description adds meaning by explaining how parameters like origin and destination ports drive congestion analysis, how ship date sets arrival window, and how free days interact with dwell. This goes beyond schema descriptions.

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 plans terminal appointments and box sequences to avoid demurrage & detention. It specifies the output: optimal pickup window, pickup-to-empty-return sequence, and expected D&D savings. It distinguishes from siblings by focusing on appointment slot availability and dual-transaction behavior.

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?

Explicitly states when to use: provide lane and ship date to get appointment planning. It explains that it's indicative and not a live feed, setting expectations. While it doesn't name alternatives, the context makes clear this is for strategic planning before actual booking.

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?

Despite no annotations, the description is highly transparent about the tool's behavior: it reads demand pressure using seasonality and equipment-crunch signals, computes bands, and returns indicative probabilities. It explicitly states that outputs are not a space guarantee or carrier quote, and discloses payment requirements (USDC on Base or prepaid key).

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 but every sentence adds value. It could be slightly more structured (e.g., bullet points for outputs), but it effectively communicates complex logic without redundancy. The front-loading of purpose and context is good.

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 an output schema, the description thoroughly explains the tool's return values (booking window, rollover probability, premium trade-off) and the logic behind them. It covers all parameters and provides a complete picture of the tool's capabilities and limitations.

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 100% schema coverage, the description adds significant meaning beyond the schema. For example, 'criticality' is explained as 'how badly a rollover delay hurts' with possible values, and 'annual_containers' is linked to triggering named-account allocation. 'base_freight_per_container_usd' is contextualized as input to price premium and delay cost.

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: to reserve space and provide booking strategy based on lane, ship date, and criticality. It outputs optimal booking window, rollover probability, and premium trade-off. The tool is distinct from siblings like get_spot_rate or carrier_recommendation, focusing on strategic booking decisions.

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 explicit guidance on when to use the tool ('When and how to RESERVE space so your box isn't rolled...') and contextual usage based on market conditions (peak/CNY vs slack). It does not explicitly name alternative tools but contrasts strategies (spot vs guaranteed booking), which helps in decision-making.

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 full burden. It discloses that market bands are modeled, not filed tariffs, and mentions payment options (pay per call with x402 or prepaid key). It does not cover auth needs or rate limits, but the honest note adds credibility.

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 long but well-structured with front-loaded core action and bullet-like details. Every sentence adds value, though some trimming could improve conciseness without losing clarity.

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 of the tool and lack of output schema, the description is complete: it covers inputs, outputs (market-rate band, award criteria, bid sheet, timeline), integration with evaluate_bids, and the honesty disclaimer. No additional information is needed.

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 100%, and the description adds significant meaning: it explains the lanes array structure (origin_port, dest_port, annual_volume, container_type?) and priority options ('cost', 'reliability', 'balanced'). It also details the output contents, compensating for no output 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 builds the structure of a freight RFP/tender, specifying the verb 'build' and the resource 'tender structure'. It distinguishes from siblings like evaluate_bids by mentioning pairing and from procurement_strategy by focusing on ocean network tender creation.

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 says to pass lanes with annual volumes and recommends pairing with evaluate_bids. It implies use when putting ocean network out to bid, but does not explicitly state when not to use or provide alternatives beyond evaluate_bids.

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 full burden. It details computation method (GLEC/ISO), per-leg breakdown, vessel class effects, EU-ETS phase-in, and notes that factors are modeled bands, not audited. It also mentions payment via x402 or key.

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 long and dense, but front-loaded with purpose. It covers many details without being overly verbose for the complexity. However, it could be more concise by grouping some 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 the complexity (9 params, no output schema, no annotations), the description is very complete. It explains return values (per-leg breakdown, EU-ETS cost), addresses edge cases (non-EU lanes, no weight), and mentions reporting frameworks and modeling assumptions.

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 100%, so baseline is 3. The description adds significant value beyond schema by explaining why weight_kg is recommended, how container_type drives default mass, and details on eua_price_eur override and air_role 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 computes CO2e carbon footprint and EU-ETS carbon cost for a shipment. It distinguishes itself from sibling tools like compare_modes and get_spot_rate by explicitly comparing modes and noting that rate tools price money while this prices carbon.

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 explicit context for when to use (ESG reporting, EU-ETS compliance) and notes that CBAM taxes the product, not freight, clarifying a common confusion. However, it does not explicitly state when not to use, though the context is clear enough.

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 carries the burden. It details modeled indicative bands, premium payment, port normalization, priority-driven ranking, and refinement of lane OTP. It also states what the tool does NOT provide (quotes, tariffs, weekly KPIs).

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 primary purpose but is lengthy due to detailed alliance history and premium payment info. While well-structured, it could be slightly more concise for an AI agent.

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 (expected on-time performance, sailing frequency, network breadth, cost-positioning, fit score, trade-off). It covers corridor integration, priority effects, and feed into lead-time buffer. Fully complete for the tool's 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?

Schema coverage is 100% with descriptions for all 5 parameters. The description adds context on how priority affects ranking and how ship_date sets market baseline, going beyond the schema. However, the schema alone already provides adequate meaning.

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 explicitly states it 'recommend WHICH CARRIER or ALLIANCE to sail with on a lane' and distinguishes the decision context as the 'third decision after when to book and which mode'. It is specific about modeling the 2025-26 realignment, clearly defining the tool's purpose and resource.

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 after deciding time and mode, but does not explicitly state when to use versus alternatives like select_provider or booking_strategy. No when-not or exclusion criteria are given, though 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?

No annotations exist, so the description carries full burden. It discloses the tool's behavior: applies UCP 600 rules, returns discrepancies with remedies, reports clean/rejected status and severity. It also warns about judgement calls and waivable discrepancies. No contradictions.

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 long but dense with information, front-loading the key question and then detailing specific checks. Every sentence adds value; no fluff. Could be slightly more structured but appropriate for the complexity.

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 tool with 25 parameters, no output schema, and no annotations, the description is remarkably complete. It explains the input requirements, the list of checks, the output format, and even monetization. Nothing essential is missing.

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%, so baseline is 3. The description adds significant context beyond schema by explaining which parameters are involved in specific checks (e.g., invoice amount, currency, shipment dates) and how they interact, making the parameter relationships clearer.

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 checks letter-of-credit documents for discrepancies, using a specific verb 'check' and resource 'letter-of-credit documents'. It distinguishes from all siblings, which are logistics/supply chain tools with no overlap.

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 opens with a direct question about getting paid, setting clear context. It explains when to use the tool and provides warnings about its modeled nature and legal disclaimer. No explicit 'when not to use' is given, but the domain is well-defined and no sibling alternatives exist.

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 fully describes internal steps: gathering cross-validated spot, reliability, disruptions, forecasts, and checking thresholds. It also discloses that results are modeled signals (regla 7) and that the tool is premium (pay per call), ensuring no surprises.

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 long and includes marketing flair ('turns freight-pulse into a standing watchtower') and a 'regla 7' disclaimer, which adds bulk. While well-structured, it could be more concise without losing key 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 no output schema, the description compensates by describing return fields (observed value, reason, severity). It covers input parameter, internal logic, and usage context, though lacks explicit output type details. Overall sufficient for agent understanding.

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% with a simple optional watch_id. The description adds context by explaining the parameter's effect (check one vs all) and usage, going beyond the schema's basic description.

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 evaluates lane watches and returns fired alerts, referencing create_watch as the registration tool. It specifies that it checks against LIVE modeled market and lists output details, making purpose unambiguous.

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 indicates when to use (after create_watch) and how (by watch_id or all), but does not explicitly exclude other contexts or compare to sibling tools like check_lc_documents. However, the paired relationship with create_watch provides clear usage 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, the description carries the full burden of behavioral disclosure. It thoroughly explains the underlying model (survival model per packaging option, cost breakdown including expected thermal loss), provides an honest disclaimer about indicative nature, and mentions payment requirements. This is highly transparent.

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, spanning multiple paragraphs with technical details. It is well-structured and front-loaded with the main purpose, but could be more concise. Every sentence adds value, but overall length detracts from quick consumption.

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?

No output schema is provided, so the description must explain return values. It does so comprehensively: lists outputs (temperature requirement, excursion risk, recommended mode, packaging, GDP needs, total cost comparison) and explains the logic. For a complex tool with 11 parameters, the description is highly 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 100%, so the baseline is 3. The description adds context for some parameters (e.g., product examples like 'pharma vaccines 2-8°C', sensitivity classes, unit values) but does not go into depth for all 11 parameters. It adds some value beyond the schema but not extensively.

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: providing cold-chain/pharma GDP compliance recommendations for temperature-controlled shipments. It specifies inputs (lane and product) and outputs (temperature requirement, excursion risk, recommended mode, packaging, GDP needs). It effectively distinguishes itself from sibling tools by focusing on a specialized niche.

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 guidance on when to use the tool: for temperature-controlled shipments requiring cold-chain compliance. It compares modes (ocean vs. air) and packaging options, and mentions specific scenarios (e.g., pharma 2-8°C, frozen seafood). It lacks explicit 'when not to use' statements, but the context makes it clear that this is for detailed cold-chain analysis, not general logistics.

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 carries the burden. It discloses the decision model (capital cost, holding cost, stockout cost), the IATA chargeable weight calculation, air rate volatility (bands not quotes), and return format. All behavioral traits are transparent.

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 detailed but front-loaded with the core purpose. Every sentence provides necessary context for a complex tool; however, slight redundancy exists (e.g., repeated emphasis on economic cost). Slightly above average conciseness given the tool's complexity.

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 17 parameters and no output schema, the description fully explains the model, return values (table with columns), and each parameter's role. It is complete and self-contained for an agent to understand how to invoke the 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?

The schema covers 100% of parameters, but the description adds significant contextual meaning, such as explaining 'value' as capital tied up, volume/weight relation to volumetric weight, and the role of each parameter in the decision model.

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: to decide the transport mode (ocean, air, sea-air) based on total economic cost. It distinguishes itself from sibling tools by noting that other tools price the ocean move, while this one answers the prior question of mode selection.

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 explains when to use this tool (before deciding mode) and contrasts it with alternatives that price ocean moves. It also covers payment details and port normalization, providing comprehensive usage guidance.

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 that the tool models active disruptions, generates priced alternatives, and ranks them by urgency. The disclaimer 'MODELED, indicative... not a guarantee' honestly sets expectations. It also discloses the premium payment model, providing full behavioral transparency.

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 and includes marketing-like text ('PREMIUM: pay per call...') which is not essential for tool selection. The first sentence does a good job front-loading the purpose, but the overall length could be trimmed without losing necessary 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?

Despite having no output schema, the description provides a thorough explanation of what the tool returns (routing, modal-shift, port-swap options with costs and times) and how it works (ranks by urgency, recommends). It includes disclaimers and parameter default behaviors, making it complete for an AI agent to decide to invoke it.

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%, so baseline is 3. The description adds value by explaining the meaning of urgency values ('cost', 'time', 'balanced') and that disruption_type can model a what-if scenario. This goes beyond the schema's descriptions, but the additional detail is not extensive.

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 detects active disruptions and generates a playbook with routing alternatives. It uses specific verbs ('generate', 'detect') and resource ('playbook for lane disruption'), distinguishing it from sibling tools that handle other logistics tasks like rates or sourcing.

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 opening line 'My route just broke...' directly tells when to use the tool. It implies usage for impending disruptions. While it doesn't explicitly list when not to use, the context of needing an actionable response alternatives makes the use case clear. No specific alternatives mentioned but the sibling list implies 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?

With no annotations, the description thoroughly discloses behavioral traits: server-side persistence, per-key scope, return of watch id and thresholds, evaluation against modeled engine outputs, and pricing model. It also clarifies alerts are signals, not booking triggers.

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 well-structured, front-loaded with purpose, and uses bullet-like formatting for thresholds. Despite length, 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?

Given 5 params, no output schema, and complex thresholds, the description covers creation behavior, return values, integration with check_watches, and even pricing. No gaps remain.

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 high schema coverage (100%), the description adds significant value by explaining each threshold metric in plain language with examples, noting the default container_type, and giving a usage example. This goes beyond the schema's enum descriptions.

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 registers a standing watch on a lane for alerts, with a specific verb 'register' and resource 'watch'. It distinguishes itself from sibling tools like check_watches by explaining the pairing pattern and labels it as a recurring daily tool.

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 explains when to use this tool (to create persistent watches with thresholds) and mentions pairing with check_watches for polling alerts. However, it does not explicitly list when not to use it or direct alternatives among siblings.

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 full burden. It discloses that figures are modeled, indicative planning intelligence, not legal/tax advice, and that eligibility must be confirmed with a licensed broker. It also mentions premium payment and reuse of the landed-cost engine.

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 relatively long but front-loaded with the core purpose and required inputs. Some details could be condensed, but the structure is logical and the warning about non-legal advice is appropriately placed.

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 thoroughly explains return values (ranked levers with savings, type, catch, and checklist). It also covers payment model and integration with the landed-cost engine, fully addressing the tool's 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?

Schema coverage is 100%, but the description adds significant meaning: clarifies mutual exclusivity of hs_code and product, explains flow options in detail, describes dest_port's role in setting customs bloc, and emphasizes fob_value as the duty base.

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 finds and quantifies duty-saving levers, given product/HS code, lane, FOB value, and trade flow. It lists specific levers (duty drawback, FTZ, etc.) and distinguishes from siblings like customs_valuation by focusing on optimization strategies.

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 states required inputs (product/HS code, lane, FOB value, trade flow) and what the tool returns. While it doesn't explicitly state when not to use it or name alternatives, the context is clear enough for an agent to infer appropriate use cases.

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 provided, but description fully discloses behavior: normalizes to FOB origin, adds statutory additions, excludes non-dutiable items, applies country basis (CIF/FOB). Also mentions it is an indicative model and not legal advice. Premium payment method included.

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 long but well-structured and informative. Front-loaded with core purpose. Every sentence adds value given the complexity of customs valuation. Could be slightly more concise, but no wasted 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?

Despite 20 parameters and no output schema, the description explains what outputs to expect (line-by-line base, over/under-payment, alternative methods). Covers methods, adjustments, disclaimers, and premium payment. Fully adequate for agent to invoke 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?

Schema has 100% coverage, but description adds significant meaning beyond parameter descriptions, e.g., explains how destination country sets CIF/FOB basis, how assists and commissions affect the base, and the role of each parameter in the valuation logic.

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?

Clearly states it computes the dutiable base for customs duty, not just the invoice price. Mentions WTO Customs Valuation Agreement, multiple methods, and specific adjustments. Distinct from sibling tools like 'customs_optimization' or 'get_landed_cost'.

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?

Provides clear context: requires destination country, invoice price, and Incoterm. Explicitly states it is not a legal ruling. However, does not name specific alternatives among siblings when not to use.

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 behavioral traits: it uses a cost-ordered lever selection, returns detailed output (costs, reduction vs offset split, EU-ETS savings), and includes an honesty note about modeled indicative costs and offset flagging. This exceeds transparency expectations.

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 somewhat lengthy but front-loaded with the core purpose and process. Every sentence adds value, and the structure is logical (input, process, output, caveats). Could be slightly trimmed but remains efficient.

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, no output schema, and moderate complexity, the description is remarkably complete. It explains inputs, the algorithmic approach, output contents, and limitations. No output schema exists, but the description compensates fully by describing return values.

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%, so baseline is 3. The description adds meaning by explaining how parameters like cost_band, ship_date, and the relationship between port parameters and baseline_co2e_tonnes are used, enhancing understanding 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 creates a decarbonization roadmap for a transport network, specifying required inputs (lane or annual footprint, target %) and detailing the process (marginal abatement cost curve with specific levers). This distinguishes it from siblings like carbon_footprint, which likely only calculates footprint.

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 explains when to use the tool: when you have a lane or network footprint and a reduction target. It does not explicitly state when not to use or list alternatives, but the purpose is clear enough for an agent to decide. Could be improved with 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 provided, so the description fully carries the burden. It reveals the model's inputs (congestion, dwell distribution), outputs (probability, expected costs, recommendation), limitations (NOT carrier's filed tariff), and payment method. This is comprehensive and clear.

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 detailed but front-loaded with the main purpose. It contains all necessary information, though some sections (e.g., payment options) are less critical for tool invocation. Overall well-structured with minimal 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?

Despite lacking an output schema, the description clearly states the expected outputs (probability, expected chargeable days, expected D&D cost, p90, marginal value, target recommendation). Given the tool's complexity, this provides sufficient context 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?

Schema description coverage is 100% with each parameter already having a detailed description in the input schema. The tool description adds overall context but does not significantly improve per-parameter understanding. 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?

The description explicitly states 'Optimize the DEMURRAGE & DETENTION free-time strategy for a destination', with specific verb ('optimize') and resource ('free-time strategy'). It clearly distinguishes this from sibling tools by focusing on D&D cost calculation and free-day negotiation advice.

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 clear context on when to use: to determine negotiated free days and expected D&D costs considering port congestion. It mentions optional refinements (carrier, mean dwell) but does not explicitly list alternative tools or when not to use. Still, the guidance is substantial.

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 provided, so the description carries full burden. It discloses that inland figures are modeled market-typical bands, not actual quotes, and mentions PREMIUM pricing and UN/LOCODE normalization. It explains the various cost components and decision logic.

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 thorough but slightly lengthy. It front-loads the key purpose. Every sentence adds value, but could be more concise while retaining all 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 no output schema, the description explains what the tool returns (door-to-door total, p50/p90 transit, model bands). It covers the main features and limitations, though additional details on error handling or data sources could enhance completeness.

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 the description adds meaning beyond the schema by explaining the logic behind interior_mode (cheaper mode by distance, deadline-aware) and band (low/typical/high). It also provides context for inland_destination and container_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 calculates door-to-door cost and time, including inland legs, and explicitly distinguishes from port-to-port tools like get_spot_rate. It uses specific terms like 'TRUE DOOR-TO-DOOR' and contrasts with sibling 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 explains when to use (for true door-to-door cost) and contrasts with port-to-port tools. It implies usage scenarios by mentioning importers usually quoting port-to-port, but does not explicitly state when not to use.

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 exist, so the description carries full burden. It transparently describes the modeled structural+seasonal profile, returns (availability index, shortage-risk, EIS), limitations (no live depot count), and premium/payment details. It even mentions regulatory note (regla 7).

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 dense but front-loaded with core purpose. While lengthy, every sentence adds value (explaining trade imbalances, seasonal effects, alternatives). Slightly long but not wasteful; a clearer structure could improve scannability.

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 7 parameters, no output schema, and no annotations, the description is remarkably complete. It explains return values (availability index, shortage-risk, EIS), modeling approach, limitations, premium, and even trade mechanics. It fully compensates for missing structured fields.

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%, but description adds significant context: e.g., carrier 'refine availability by its own-box fleet & depot depth', ship_date 'seasonal equipment swing evaluated for THIS date', container_type 'maps to 20DV/40DV/40HC equipment pool'. Each parameter's purpose is elaborated 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 'Check whether the shipper can even GET A CONTAINER on a lane' and distinguishes it from rate tools like get_spot_rate, which assume a box exists. It uses specific verbs and resources, and the context of 'before pricing the move' differentiates it from sibling 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?

Explicitly tells when to use: 'BEFORE pricing the move.' Also clarifies when not to expect live inventories: 'NOT a live depot inventory.' Provides alternatives when box is short and suggests passing a carrier to refine the numbers, giving clear usage boundaries.

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 fully discloses the scoring methodology (COST + RELIABILITY + COVERAGE), the low-ball detection mechanism, the output (awarded cost vs naive-cheapest cost, flagged low-balls), and its advisory nature ('modeled decision aid'). No contradictions.

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 purpose, then provides necessary detail in a logical flow. While it is dense, every sentence adds value—from input format to scoring logic to output summary. It could be slightly tightened, but it remains efficient for the complexity it covers.

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 what the tool returns at the network level (awarded cost vs naive-cheapest cost, number of low-balls flagged). It does not detail the exact output structure (e.g., JSON format), but the behavioral description is sufficient for an agent to understand what to expect. The payment info is ancillary but does not detract.

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 covers both parameters thoroughly (lanes structure and priority options). The description adds significant meaning beyond the schema by explaining how the parameters influence scoring (e.g., 'DETECTS LOW-BALLS — a bid implausibly under the lane's modeled market band... scores them DOWN on credibility'). This enriches the agent's understanding of what each parameter does and how they interact.

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 starts with a clear verb-resource pairing: 'Evaluate carrier BIDS on a freight tender and pick the best award per lane.' It details what it does (scores bids on cost, reliability, coverage, detects low-balls) and implies a niche distinct from siblings like carrier_recommendation by focusing on bid evaluation rather than carrier sourcing.

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 tells the user what to pass as input: 'Pass your lanes (with annual volumes) and the bids each carrier submitted (carrier + all-in rate, optionally transit/sailings/free-days).' It also provides a cautionary note about not treating it as a procurement decision without verification. However, it does not explicitly contrast with alternative tools or state 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?

No annotations provided, so description fully discloses behavior: classification against dual-use lists, embargo check, decision tree outcomes (blocked, licence, permitted, review-required), and limitations (modeled, non-authoritative, must verify). Also mentions pricing.

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 long but each sentence adds value, covering purpose, usage, limitations, and warnings. Front-loaded with main purpose. Slightly verbose but justified by legal sensitivity.

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?

No output schema, but description fully explains return outcomes and decision tree. Covers input options, classification, embargo, limitations, and verification requirement. Complete for a legally sensitive 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%, so baseline is 3. Description adds meaning beyond schema by explaining how parameters are used (country-level checks, same classifier) and giving examples. Adds context about optional container_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 it checks legality of exporting a product, focusing on goods-side trade compliance, and explicitly differentiates from denied-party screening. The verb 'check' and resource 'export compliance' are precise.

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?

Provides explicit when-to-use (goods-side compliance) and when-not (denied-party screening). Instructs to pass product description or HS code + lane, and references same classifier as get_landed_cost. Includes legal sensitivity warnings.

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 that it is a modeled reference analysis, not financial advice, and explains limitations like capped hedge ratio due to variable spend. It also mentions premium payment and the analytical nature of recommendations.

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 relatively long but well-structured, front-loading the main purpose. It includes essential details without redundancy, though some minor trimming could improve conciseness.

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 no output schema, the description thoroughly explains all outputs (exposure, volatility, adverse move, hedge ratio, forward points, ladder plan). It covers inputs, limitations, pricing, and context, making it fully complete for an analytical 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%, so baseline is 3. The description adds value by explaining how optional parameters like spend_cv, horizon_months, and risk_tolerance affect the output, beyond 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 quantifies and hedges currency risk for ocean-freight spend, specifying inputs (home currency, annual spend) and outputs (exposure, volatility, adverse move, hedge ratio). It is distinct from sibling logistics 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 explains when to use (pass home currency and annual spend) and includes a disclaimer that it is not for live quotes or financial advice, implying when not to use. However, it does not explicitly list alternative tools for similar tasks.

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 full burden. It extensively discloses behavioral traits: the tool models surcharges, tags values as 'typical' or 'modeled', states the output is indicative not a carrier tariff, explains route awareness, lists surcharges applied and excluded, and even mentions the premium payment model. This is comprehensive and transparent.

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 long but packed with essential information. It front-loads the core purpose and then details surcharges, route logic, and output. Every sentence adds value with no redundancy. While slightly lengthy for the complexity, it remains well-structured and efficient.

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 complexity (8 parameters, no output schema, no annotations), the description is exceptionally complete. It covers the output structure, modeling methodology, route-specific surcharge application, tagging of values, and payment model. No significant gaps remain for an agent to understand what the tool does and how to use it.

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 description coverage is 100%, so baseline is 3. The description adds value beyond schema by explaining how certain parameters drive specific surcharges (e.g., ship_date drives Peak-Season Surcharge, fuel_proxy drives BAF model) and providing context on defaults and usage. This elevates the score above baseline.

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 the ALL-IN ocean freight cost (true landed cost) for a lane, explicitly distinguishing it from get_spot_rate which returns the base spot rate. The verb 'Get' plus resource 'all-in rate' is specific, and the differentiation from the sibling tool is explicit.

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 names the alternative (get_spot_rate) and explains when to use this tool: when the true landed cost is needed, not just the base spot rate. It provides context on the surcharges modeled and route awareness. However, it does not explicitly state when not to use the tool, missing a clear 'when-not' clause.

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 full burden. It discloses that estimates are indicative, not binding, explains duty modeling per country, origin-sensitive remedies, de-minimis handling, and premium payment. This is thorough and honest about 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?

The description is lengthy but well-structured with clear sections and bullet points. It contains valuable information, though some minor trimming (e.g., payment details) could improve conciseness.

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 (12 parameters, no output schema), the description is exceptionally complete. It covers duty calculation, HS classifier, origin sensitivity, de-minimis, VAT, and output format expectations. The agent has enough information to correctly invoke the 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% with good parameter descriptions. The tool description adds overall context but does not provide additional per-parameter semantics beyond what the schema already offers. 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 clearly states it calculates the full landed cost breakdown (FOB, freight, insurance, duty, VAT) and includes an HS-code classifier. It distinguishes from sibling tools like get_spot_rate which only provides spot rates, not the complete cost picture.

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 detailed context on when to use the tool (for importing, HS classification, duty estimation). It does not explicitly state when not to use it or name alternatives, but the context is clear enough for an agent to decide.

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?

Discloses the statistical method (Holt-Winters), that it runs on server-side history, returns indicative market intelligence not a carrier quote, and has a payment model. No annotations exist, so description carries full burden and does so 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 comprehensive but verbose, containing marketing language and technical details. The first sentence clearly states purpose, but subsequent paragraphs could be more 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?

No output schema exists, but description fully explains all returned components (time series, forecast, seasonality, anomaly, recommendation), plus pricing and prerequisite tips. Highly complete for a complex 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 covers all parameters (100% coverage). Description adds extra context for ship_date (seasonality evaluation) and forecast_weeks (widening intervals), going beyond schema descriptions.

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 forecasts ocean spot rates for a lane and provides a book-now-or-wait recommendation. It distinguishes itself from sibling get_spot_rate by mentioning it seeds history and is a separate premium call.

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?

Provides guidance to call get_spot_rate first to seed history and mentions premium payment requirement. Does not explicitly state when not to use, but the use case is well-defined.

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 fully bears the burden of disclosure. It clearly states the tool returns modeled, indicative data ('Every figure is a MODELED structural typical + a dated disruption overlay; it is INDICATIVE, NOT a live waiting-time feed'), describes its construction (35 curated profiles, dated catalogue), and outlines behavioral traits such as disruption window evaluation and premium payment requirements. No contradictions are present.

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 detailed but quite verbose, containing multiple clauses and run-on sentences. While it is front-loaded with the core purpose, the length and lack of bullet points or structured formatting reduce conciseness. It could be more succinct without losing key 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 the complexity of the tool, no output schema, and 4 parameters, the description thoroughly explains all outputs (congestion index, waiting days, operational-risk score, active disruptions) and provides context on data sources, limitations, and premium access. It covers what an agent needs to invoke and interpret results 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?

Schema coverage is 100% with descriptions for all 4 parameters. The description adds valuable context beyond the schema: it explains how 'ship_date' is used to evaluate congestion and disruption windows, connects 'origin_port' resolution to get_spot_rate, and clarifies 'container_type' as informational. This extra meaning justifies a score above 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 explicitly states the tool gets port congestion and disruption intelligence for a lane, operational state of ports, and live disruption events. It clearly distinguishes from rate tools and lists specific outputs (congestion index, waiting days, operational-risk score, rate pressure, active disruptions).

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 explains when to use this tool (to check if ports can clear on schedule) and contrasts with rate tools ('The rate tools tell you what a move costs; this tells you whether the PORTS can actually clear it on schedule'). It also notes limitations (indicative, not live feed) and premium access. However, it does not explicitly compare to sibling tools or mention 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 discloses behavioral traits such as 'returns... per subject, on-time %... trend' and flags 'Honest (regla 7): your own empirical log, small samples flagged,' indicating data reliability. It also mentions premium pricing, adding transparency about cost.

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 lengthy and includes marketing language ('turns freight-pulse into a recurring decision tool') and pricing details. While it front-loads the main purpose, it could be more concise by trimming extraneous phrases.

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 thoroughly lists the return fields (on-time %, average delay, damage rates, reliability score, trend, ranking) and constraints (optional subjects, small sample flagging). It is complete for a read tool with two optional parameters.

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 100%, so baseline is 3. The description reinforces the schema's parameter explanations (e.g., 'Drill into one carrier/supplier/lane') but adds minimal new semantic value beyond the schema descriptions.

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 'Read[s] your accumulating supplier/carrier/lane SCORECARD' and lists specific KPIs returned, making the verb and resource explicit. It distinguishes from siblings by focusing on scorecard reading, which is unique among given sibling 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 provides explicit guidance: 'Omit 'subject' for the whole network or pass one to drill in,' clarifying when to use each parameter. It implies a use case for decision-making ('who do I award next year's volume to?') but does not explicitly state when not to use it or compare to alternatives.

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 provides substantial behavioral context: cross-validates multiple indices, reconciles into a single number, handles port normalization via UN/LOCODE. It does not mention data freshness or error handling, but overall it is transparent about its internal process.

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 comprehensive yet structured: it front-loads the purpose, then explains return values, data sources, normalization, examples, and sibling differentiation. Every sentence adds value without unnecessary verbosity.

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 values (USD figure, confidence, market direction). It covers supported lanes, input formats, and limitations. Minor omissions like error handling do not detract significantly from completeness.

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 already includes details like defaults and synonyms for container_type. The description adds extra value by explaining port normalization via UN/LOCODE, which goes 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's purpose: getting the current ocean container spot rate for a lane, with specific details on outputs (USD figure, confidence score, market direction). It distinguishes itself from the sibling tool get_lane_trend, which handles trends and recommendations.

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?

Explicitly states when to use (to decide whether to book now or wait) and when not to (for weeks-long trends, use get_lane_trend). Also clarifies it is free and indicative, not a carrier quote.

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 fully carries the burden. It comprehensively discloses behavioral traits: what is returned (risk transfer point, cost breakdown, insurance mandates, classic traps, container warning), payment details, and a legal disclaimer. This is exceptionally transparent.

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 and packed into a single paragraph. While it is front-loaded with the main purpose, it contains extraneous details (e.g., premium payment info) that could be moved to an output schema or separate section. It is not optimally 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 lack of an output schema, the description fully covers what the tool returns: risk transfer point, cost split for each step, insurance requirements, common traps, container appropriateness, and a disclaimer. This is complete for a tool of moderate complexity with 5 parameters.

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%, so a baseline of 3 is appropriate. The description adds value by explaining the incoterm parameter (list of rules) and how container_type drives a container-appropriateness check, providing context beyond the schema descriptions.

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 explains the exact cost and risk split between seller and buyer for an Incoterms 2020 rule. It provides specific examples like 'FOB Shanghai' vs 'DDP my-warehouse' and lists what is returned, making the purpose highly specific and distinct from sibling 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 usage context (importer decision-making) and includes a disclaimer that it is not legal advice. However, it does not explicitly state when to use this tool versus alternatives among the many sibling tools, nor does it provide when-not-to-use guidance.

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 provided, but the description openly states it provides modeled market-typical bands (not a broker's quote) and mentions payment methods (pay per call or prepaid key). It implies a read-only computation with no destructive 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 a single paragraph but is well-structured, front-loading the purpose. Every sentence adds essential context, though it could be broken into shorter sections for easier scanning.

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 (10 parameters, no output schema, no annotations), the description is remarkably complete: it covers purpose, pricing logic, Incoterms implications, payment, and port normalization, leaving little ambiguity about tool behavior.

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% with parameter descriptions, but the description adds significant value by explaining the premium calculation formula (insured value vs loss profile vs mode vs route vs deductible) and the role of each parameter in that formula.

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 recommends cost-effective marine cargo insurance for a shipment, specifying it compares three Institute Cargo Clauses. This distinguishes it from sibling tools like carrier_recommendation or compare_modes.

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?

It provides context on when to use (for cargo insurance needs, especially under-buying importers) and includes Incoterms tie-in but does not explicitly list when not to use or compare with all alternatives.

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 the tool's behavior: it computes safety stock, reorder point, EOQ, and total cost using textbook formulas, and relies on a transit engine for lead time variability. It mentions the trade-off between modes and that results are indicative. No contradictions.

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 comprehensive but slightly verbose. It front-loads the main purpose effectively. Each sentence adds information, though some detail (like the formula) could be shortened. Overall, it is well-structured for an AI agent.

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 (13 parameters, no output schema, no annotations), the description covers the main return values (safety stock, reorder point, EOQ, total cost) and explains the trade-off. It does not specify output format, but the formula and context are sufficient for understanding the tool's results.

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 100%, so baseline is 3. The description adds value by explaining key parameters like 'unit_value_usd' (drives holding cost) and highlighting defaults. It also provides context beyond the schema, such as the output metrics and formula, earning a 4.

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: sizing inventory based on freight decisions. It uses specific verbs and resources ('size the INVENTORY', 'computes safety stock'), and distinguishes itself from sibling tools like 'ship_decision' or 'total_cost_ownership' by focusing on the inventory impact of mode choice.

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 explains when to use the tool: provide lane, demand, and value to get inventory metrics. It mentions overriding default cost parameters and premium payment, but does not explicitly state when not to use it versus alternatives. However, the context is clear enough for an agent to decide.

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 full burden. It clearly states the tool returns a modeled, indicative score (not a live threat feed or insurance-grade), includes pricing details, and does not hide limitations. The honesty disclaimer adds transparency.

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 and includes extraneous details like pricing and legal disclaimers, which could be shortened. However, it is front-loaded with the core purpose and structured in sections. Some sentences earn their place, others could be trimmed.

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 7 parameters, no output schema, and no annotations, the description covers inputs (with contextual meaning), outputs (composite score, breakdown, mitigations), limitations, and pricing. It adequately informs the agent about what to expect, though a bit more structure would improve completeness.

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%, but the description adds meaningful context by explaining how each parameter contributes to risk dimensions (e.g., ship_date overlays seasonal windows, port_count affects concentration). This goes beyond the bare schema descriptions.

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 begins with a clear, specific verb+resource ('How FRAGILE is this route?') and explains that it computes a composite lane-risk score from multiple dimensions. It distinguishes itself from siblings by being a composite of risk factors modeled elsewhere, clearly stating its unique value proposition.

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 risk mapping by supply-chain directors and provides parameter guidance, but it does not explicitly state when to use this tool versus alternatives like get_lane_trend or get_port_intel. No 'when not to use' or explicit alternative recommendations are given.

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 provided, so the description carries the full burden. It discloses that the output is 'indicative stowage PLANNING' and not a certification, and mentions the PREMIUM payment requirement (x402 USDC or prepaid key). It also warns about road weight limits and overweight scenarios. There is no contradiction with annotations.

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 thorough but verbose, containing many details in a single block. It is front-loaded with the main purpose and uses bullet points in spirit, but could be more concise. Every sentence adds value, but the length may reduce readability.

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 10 parameters, no output schema, and no annotations, the description is highly comprehensive. It explains the key outputs (units fit, binding constraint, utilization, container comparison, overweight warning, mix) and covers important edge cases (dense vs. light cargo, road weight limits).

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 100%, with each parameter having a description. The tool description goes beyond the schema by explaining how parameters are used (e.g., weight drives weight-binding logic, target_units produces container mix). It adds contextual meaning without contradicting 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's purpose: 'Optimize how a product LOADS into a container' and lists specific computations (units fit by volume/weight, binding constraint, utilization, container comparison). It distinguishes from sibling 'pallet_plan' by focusing on container stowage rather than pallet optimization.

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 inputs ('Give the CARTON dimensions and gross weight') and optional parameters, and explains when to use (stowage/cube-and-weight question). It also notes what it does not do ('not a load-securing certification'). However, it does not explicitly contrast with sibling tools like 'pallet_plan'.

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 details the report contents, that it's sourced from modeled engines, includes an honesty disclaimer, and mentions payment. It does not cover rate limits or authentication, but for an insight tool this is reasonable.

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 relatively long but well-structured with numbered sections and bullet points. It front-loads the purpose. Some details like payment instructions could be considered extra, but overall it efficiently conveys the tool's capabilities.

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 thoroughly explains the output report structure, data sources, and usage context. It covers all necessary aspects for an agent to invoke the tool correctly and understand the return value.

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%, so the baseline is 3. The description adds value by explaining which optional parameters unlock specific sections (e.g., merchandise value unlocks landed cost). However, parameter semantics are mainly covered by schema descriptions.

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 composes a comprehensive executive market-intelligence report for a lane, listing all sections. It distinguishes from sibling tools that focus on specific aspects (e.g., spot rates, landed cost, carrier recommendations).

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 indicates the tool is for generating a committee-ready brief for a head of logistics, implying a comprehensive overview. It does not explicitly state when not to use it or list alternatives, but the context of sibling tools provides 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 provided, so the description carries full burden. It reveals key behavioral traits: global optimization, network constraints enforcement (budget, service level, CO2 ceiling), output of top saving lanes, consolidation opportunities, and trade-offs. It also includes a disclaimer that output is indicative, not committed. Missing details on error handling or permissions.

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 dense but well-structured, with key terms capitalized for emphasis. It front-loads the main purpose and then details constraints and outputs. It could be slightly more concise, but every sentence provides relevant 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 the complexity (7 parameters, no output schema, no annotations), the description is quite complete. It explains the high-level process, constraints, and expected outputs (savings, consolidation, trade-offs). It lacks a structured return value description, but given no output schema, it provides enough context for an agent to form expectations.

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 100%, baseline 3. The description adds value by explaining how parameters interact (e.g., budget shifts lanes to locked contracts, CO2 ceiling targets heaviest lanes) and provides context beyond the schema definitions. This helps an agent understand the optimization logic.

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: 'Optimize a shipper's ENTIRE annual lane PORTFOLIO at once'. It specifies the verb 'optimize' and the resource 'annual lane portfolio', and distinguishes it from single-lane tools by stating it answers the question they can't. The scope is explicit.

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 when to use this tool (for a portfolio of lanes) by noting that single-lane tools can't answer this question. It also mentions it reuses engines from per-lane tools for coherence. However, it does not explicitly state when not to use it or compare to sibling tools like procurement_strategy or simulate_scenario.

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 that results are indicative rectangular-packing geometry capped by weight/height, not a stow guarantee. Also mentions the premium payment model, providing complete behavioral context.

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 fairly long but well-structured, starting with the main purpose and then detailing outputs and trade-offs. Every sentence adds value, though it could be more concise without losing substance.

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, no annotations), the description is remarkably complete: it explains inputs, outputs, constraints, limitations, and even the premium model, enabling an agent to understand and use the tool effectively.

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%, so baseline 3. The description does not add additional meaning beyond what the schema provides for individual parameters, though it gives context on how parameters are used (e.g., 'total case count' for shipment needs).

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 optimizes palletization across the chain (product→case→pallet→container) and distinguishes it from a box→container load optimizer, with specific verbs like 'computes' and 'contrasts'.

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?

Provides clear context: tells user to pass a total case count, contrasts palletized vs floor-loaded, and mentions when to use. However, lacks explicit 'when not to use' or alternative tool names besides the vague sibling reference.

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 full burden and does well. It discloses that it scores instruments, recommends based on a matrix, prices LC commissions, ties to Incoterms, and notes that figures are modeled and not financial advice. This provides clear behavioral expectations.

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 lengthy but well-structured with logical progression: inputs, scoring, recommendation logic, pricing, and disclaimers. Every sentence adds value, though some condensation might improve readability.

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, no output schema, and medium complexity, the description is quite complete. It explains the decision logic, inputs, pricing, and tie-ins to Incoterms and premium payment. It lacks explicit output format but is sufficient for an AI agent.

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 100%, so baseline is 3. The description adds meaningful context beyond schema: e.g., relationship as the biggest driver, invoice value as basis for pricing, and how origin/dest ports map to countries. This enriches understanding.

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 recommends trade finance payment terms for import deals, specifically calling out it is 'the other half the transaction the freight tools ignore.' It lists the payment instruments and the decision matrix, making purpose very specific and differentiating from sibling 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 explains when to use the tool (for import deals) and provides guidance on required inputs (lane, invoice value, relationship). It gives examples of recommendations based on relationship and country risk. While not explicitly stating when not to use it, the context is sufficient for correct invocation.

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 fully discloses behavioral traits: it costs three strategies, uses Holt-Winters forecast, reads market regime, computes break-even, optimizes mix, models MQC penalties and loading priority, and mentions pricing. This is comprehensive without omitting critical 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 dense and front-loads the main purpose but contains very long sentences and extensive technical detail. While informative, it lacks brevity and could be structured more concisely for quick comprehension by an AI agent.

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 params, no output schema), the description covers the model, assumptions, and expected outputs (break-even, optimal mix, etc.) quite well. However, the lack of an output schema means the agent may not fully anticipate the response structure, reducing completeness slightly.

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 provides 100% coverage with descriptions. The description adds beyond the schema by explaining the role of annual_volume as the basis, risk_tolerance's effect, and contract_rate_offered's scoring purpose. This adds meaningful context, going beyond the baseline 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 tool decides ocean sourcing strategy (contract, spot, or split) over a year, distinguishing it from operational booking tools: 'not 'book this box now' but 'how do I source my whole volume?'. The verb 'decide' and specific resource 'OCEAN SOURCING STRATEGY' make the purpose highly specific.

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 for strategic annual volume decisions and distinguishes from tactical tools. It mentions prerequisites like annual volume and optional contract rate. However, it does not explicitly state when not to use or provide clear alternatives among siblings, though the context suggests a distinct role.

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 bears full burden. It discloses the tool is a modeled, indicative aid, explains the underlying rules, and warns about legal exposure. It mentions pricing but does not explicitly state read-only or destructive 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 informative but verbose, including detailed examples and warnings. It is front-loaded with the core question, but could be more concise by trimming less essential examples and separating pricing info.

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 complexity (7 parameters, no output schema, no annotations), the description is highly complete. It explains inputs, logic, output format (verdict, reasons, RVC points, paths to qualify), limitations, and links to related tools.

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%, so baseline is 3. The description adds meaningful context beyond schema descriptions, e.g., explaining transaction_value as 'FOB value of the finished good in USD (the RVC denominator)' and detailing the materials structure.

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: checking if a product qualifies for FTA preference. It specifies the verb 'compute' and resource 'FTA origin qualification', and distinguishes itself from siblings by referencing iter4 and iter14.

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 clear context on when to use the tool, listing required inputs. It warns that it's an indicative aid, not a legal determination. However, it does not explicitly state when not to use it or compare to sibling tools.

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 provided, but description fully discloses data sources (Drewry WCI + Freightos FBX), method (modeled dispersion), and limitations. Payment model (pay per call) is also mentioned, which is helpful.

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 verbose but well-structured with front-loaded purpose. Each sentence adds value, though could be slightly more concise. For a complex tool with 8 parameters, length is justified.

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 complexity, no output schema, description covers return values (percentile, over/under payment, leverage) with examples. Also explains model limitations and payment, making it fairly 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?

All 8 parameters have schema descriptions, and description adds context: explains is_contract flag for contract rates, default values for ship_date and container_type, and annual_containers for annualizing savings.

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 benchmarks a rate against market, providing percentile position and savings. It distinguishes from siblings like get_spot_rate and market_report by focusing on 'am I being clamped?' check for rates already paid.

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?

Explicit guidance: use when you have a paid rate and want to know if it's fair. Also warns about limitations (modeled dispersion, not real quotes) and suggests alternative for true benchmark, using honest (regla 7) caveat.

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 full burden and thoroughly discloses behavior: records data server-side, returns running KPIs, notes that KPIs reflect only recorded data and flags small samples, and mentions PREMIUM pay-per-call pricing.

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 and uses marketing language, which detracts from conciseness. Although the key purpose is front-loaded, several sentences could be condensed without losing clarity.

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 (10 parameters) and lack of output schema, the description adequately covers the tool's complete behavior: what it logs, what metrics it returns, and how it integrates with other tools like 'get_scorecard'.

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?

While schema coverage is 100%, the description adds value by grouping parameters conceptually (e.g., 'promised vs actual transit days', 'on-time, damage, documentary discrepancy, rollover') and explaining their role in the tool's purpose.

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 ('Log') and resource ('supplier/carrier/lane SCORECARD'), and distinguishes from sibling tool 'get_scorecard' by labeling this as the empirical counterpart for recording individual events.

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 pairs with 'get_scorecard' for ranking and trending and mentions it as the empirical counterpart to 'iter8', providing clear context for when to use. However, it does not explicitly state 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?

No annotations are provided, so the description carries full burden. It describes the output and mentions pricing and port normalization, but does not declare side effects (likely none). It is transparent about limitations (not binding) and scope.

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 long but well-structured: purpose first, then content breakdown, parameter guidance, caveats, and pricing. Each sentence adds value, though some details (e.g., specific penalty amounts) could be trimmed without 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?

With 6 parameters, 2 required, no output schema, the description adequately describes the return value (a checklist covering commercial, specials, destination filings, COO). It also mentions responsibilities with incoterm and includes disclaimers. Some might want more on output format, but it's sufficient.

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 the description adds significant value beyond parameter names: e.g., hs_code 'overrides text classifier', product triggers specific docs, incoterm tags responsibilities, dest_port drives filing type. Every parameter is enriched with examples and usage 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 produces a checklist of trade documents for a specific goods-destination pair. It distinguishes itself from sibling tools like get_spot_rate or customs_optimization by focusing on documentary requirements.

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 explains when to use (to avoid fines, holds, overpaid duty), what it includes (commercial set, goods-triggered specials, destination filings), and caveats (indicative, not binding). It lacks explicit 'use this instead of X' but provides sufficient context among siblings.

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 bears full burden. It discloses the tool's behavior: it calculates three dispositions, picks best net recovery, uses default multipliers and recovery fractions, flags storage bleed, and notes it's indicative and not legal advice. It also mentions pricing.

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 dense but well-organized, starting with the purpose and then detailing inputs, logic, and caveats. It is slightly long but every sentence adds value, so it earns its length.

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?

No output schema is provided, so the description explains that the tool prices three dispositions and picks the best net recovery. It also covers extras like storage bleed and honesty disclaimers. While not specifying exact output format, it gives sufficient context for an AI agent.

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 100%, but the description adds value by explaining how parameters like unit_value_usd drive recovery and decision logic. It goes beyond schema descriptions to show how inputs are used in the model.

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 models reverse logistics, takes inputs (lane, units, value, condition), and outputs the best disposition (return, destroy, liquidate) based on net recovery. It is distinct from all sibling tools, which focus on forward logistics or other areas.

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 explains when to use (goods returning from destination) and provides decision rules (e.g., high unit value + recoverable duty + cheap reverse freight → RETURN). It does not explicitly list when not to use, but the context makes it clear for reverse logistics scenarios.

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 exist, so the description fully covers behavioral traits. It discloses that recommendations are indicative, not endorsements, mentions honesty (regla 7), and explains the shifting weights and output. It also notes premium payment options.

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 long but structured with clear sections: purpose, examples, honesty, premium. Every sentence adds value, though some redundancy could be trimmed. It remains focused on the tool's functionality.

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 7 parameters, no output schema, the description fully explains the tool's output (scores, ranks, recommendation, scorecard) and how weights shift with need. It is complete for the tool's 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?

Schema coverage is 100%, and the description adds meaning beyond the schema by explaining how parameters affect the tool's logic (e.g., cargo_type as alias for specialisation, needs_warehousing pulling toward 3PL/4PL). This enriches the semantic understanding.

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 selects the right freight intermediary type, scores provider archetypes, ranks them, and recommends a type with pairing. It distinguishes from siblings like carrier_recommendation by focusing on intermediary roles rather than specific 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 implies the use case (giving a need profile to get ranked archetypes) but does not explicitly address when to use this versus sibling tools like carrier_recommendation or evaluate_bids. No when-not-to-use guidance is provided.

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 of behavioral transparency. It discloses that the tool is indicative, not a binding booking or quote, and mentions payment per call via crypto or prepaid key. It also states that each component is computed by its own engine and the breakdown is shown. This provides adequate transparency about the tool's nature 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?

The description is thorough but slightly lengthy. It front-loads the core purpose and then lists outputs and inputs. Each sentence adds value, though some sections (like payment info) could be condensed. Overall, it is well-structured for a complex tool, balancing detail with clarity.

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 substantial complexity (14 parameters, no output schema), the description is remarkably complete. It explains the tool's role as a unified decision maker, covers all key input effects, describes the output components (mode, carrier, timing, cost, risks), and sets proper expectations (indicative, not a quote). No critical aspect is missing.

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 100% schema description coverage, the description adds substantial meaning beyond the schema. It explains how optional parameters like urgency can override mode choice towards speed, how deadline adds stockout cost, how volume_m3 affects air volumetric weight, and how product enables landed-cost calculation. This richly contextualizes the parameters for the agent.

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 is a unified decision tool that integrates multiple freight-pulse layers to provide a single actionable answer for a concrete shipment. It lists specific outputs (recommended mode, carrier, timing, total cost, risks) and distinguishes itself from specialized sibling tools like get_spot_rate or carrier_recommendation by being comprehensive.

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 explains when to use the tool: for a concrete shipment decision by providing lane and merchandise value. It explicitly states it is 'indicative decision support — not a booking or a quote,' setting clear expectations. However, it does not explicitly contrast with alternatives like get_all_in_rate or compare_modes, leaving some usage guidance implicit.

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 recomputes engine outputs with perturbed inputs, models adjustments as 'explicit, transparent adjustments — never silently', and reports baseline, scenario, and deltas. It also mentions port normalization consistent with get_spot_rate. The description is thorough and honest.

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 dense but front-loaded with the core purpose ('Run a WHAT-IF on a lane'). It contains some repetition (e.g., 'recomputes' appears twice) and is longer than necessary, but every sentence adds value. Minor redundancy prevents a 5.

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 complexity (8 parameters, 4 scenarios, no output schema), the description is complete. It covers all scenarios, parameter usage, behavioral details (transparent adjustments), payment methods, and port normalization. It provides sufficient context for an AI agent to invoke the tool 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?

Schema description coverage is 100%, so the baseline is 3. The description adds significant value by pairing parameters with scenarios (e.g., fuel_spike_pct for 'fuel-spike', tariff_delta_pp for 'tariff-change'), explaining defaults, and providing context (e.g., 'ship_date drives the CNY-year and baseline all-in'). This goes beyond the schema descriptions.

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 runs a WHAT-IF on a lane, recomputing COST and TIME impact under structural changes. It lists specific scenarios ('red-sea-reopen', 'fuel-spike', 'cny', 'tariff-change') with brief explanations, making the tool's purpose distinct from the 48 sibling tools which cover various logistics operations.

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 explains when each scenario is material (e.g., 'red-sea-reopen' only on Suez-exposed lanes) and notes premium payment requirements (x402 or FREIGHT_PULSE_KEY). It clarifies that the what-if is a modeled counterfactual, not a prediction. However, it does not explicitly contrast with sibling tools or state when this tool should not be used.

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 that cost indices, risk scores, and lead adders are modeled and directional, and that users should follow up with quotes and rules-of-origin checks. It mentions premium pricing. However, it does not detail error handling or edge cases.

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 dense and contains multiple ideas in one long paragraph. While informative, it lacks clear structure and is verbose. For a complex tool, some verbosity is acceptable, but it could be more concise and organized.

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 7 parameters and no output schema, the description effectively covers the tool's inputs, outputs (ranking, recommendation, dual-source mix), and limitations. It provides enough context for an agent to understand the strategic value and what results to expect.

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 covers all 7 parameters with descriptions (100% coverage). The description adds context beyond the schema, such as that 'fob_value' is the China-equivalent cost and other origins are scaled, and that 'priority' options include explicit weightings. This enriches understanding.

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 defines the tool's purpose: strategic CHINA+1/NEARSHORING analysis comparing multiple origins on cost, lead time, and risk. It explicitly distinguishes from sibling tools like get_landed_cost or total_cost_ownership by focusing on multi-dimensional, origin-comparison with a de-risking recommendation.

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 guidance on when to use: provide the same product, destination market, and China-equivalent FOB cost. It outlines the context (strategic sourcing decision) but does not explicitly state when not to use or mention alternative tools. The 'Honest' note provides caveats.

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 thoroughly discloses that all figures are modeled planning data, not certified declarations. It details what is returned for each assessment (DG, reefer, OOG) and mentions the premium payment model. No contradictions with annotations since none exist.

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 informative and front-loaded with the main purpose, but it is verbose (around 500 words). While every sentence adds value, it could be more structured (e.g., bullet points) to improve readability. It balances detail with clarity.

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 complexity (13 parameters, no output schema, no annotations), the description is remarkably complete. It explains all three assessment types, edge cases (e.g., breakbulk fallback), and port normalization. The agent has sufficient context to use the tool 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?

Schema description coverage is 100%, so baseline is 3. However, the description adds substantial meaning: it explains how 'product' can infer DG class, that 'length_cm' triggers OOG assessment, how 'other_classes' affects segregation, and defaults for 'container_type'. This goes well 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 assesses special/non-standard cargo (dangerous goods, reefer, out-of-gauge) for a lane, contrasting with plain dry box rate models. The verb 'assess' plus the specific resource types provides a clear purpose, and the mention of 'Same UN/LOCODE port normalization as get_spot_rate' helps distinguish it from a sibling tool.

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 says use for special cargo 'a plain dry box rate model can't price' and includes a disclaimer that figures are modeled planning data, not authoritative rulings. It mentions premium payment but does not explicitly compare to sibling tools like cold_chain, though the context is clear enough.

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?

The description discloses that the tool composes indicative outputs from other engines, is not audited or binding, and includes a premium pay-per-call model. Since no annotations are provided, it fully carries the behavioral burden and is transparent about its limitations and cost structure.

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 long but each sentence provides necessary information: function, inputs, outputs, ranking insight, and honesty clause. It could be slightly more concise, but the structure is clear and front-loaded with the core purpose.

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 complexity (17 parameters, no output schema), the description thoroughly explains what the tool returns (ranked strategies with cost components and reasoning). It covers the main use case, edge cases (e.g., air winning for high-value goods), and indicates the scope of the output without an explicit schema.

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 covers all 17 parameters with descriptions (100% coverage). The description adds meaningful context about how parameters like fob_value serve as a baseline and how the tool composes costs from the given inputs. It adds moderate value beyond the schema by explaining the overall logic.

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 function: it composes total cost of ownership per strategy (origin x mode) and ranks them, for a given product, destination, FOB, and demand. The verb 'composes' and resource 'total TCO per strategy' are specific, and the explanation of how it ties the supply chain together distinguishes it from more narrow sibling tools like get_landed_cost or sourcing_analysis.

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 this is the comprehensive decision tool ("ties the entire freight-pulse stack into one decision") and gives examples of when nearshore or air modes win. However, it does not explicitly state when not to use it or directly compare to alternative tools. 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.