supply-chain-intelligence

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

Without annotations, the description carries the full burden and successfully discloses the return format (current price + 24-hour change) and tier restrictions. However, it omits safety classification (read-only vs destructive), rate limiting details, and error behaviors for unsupported commodities.

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?

Three well-structured sentences efficiently cover purpose, enumerated coverage (grouped logically by sector), and return format/tier limitations. The commodity list is lengthy but essential given the parameter-less design, making every clause necessary.

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 and no annotations, the description adequately compensates by detailing the 31 commodities covered, return data points, and tier restrictions. Minor gap: it does not clarify whether the tool returns a single aggregate object, an array of all commodities, or requires multiple invocations.

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 zero input parameters, the baseline score applies. The description correctly implies no filtering is possible by exhaustively listing all 31 tracked commodities, effectively compensating for the empty schema by defining the dataset scope.

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 monitors real-time commodity prices and volatility for supply chain management, with specific coverage of 31 commodities across 6 categories. However, it does not explicitly differentiate from siblings like get_commodity_volatility_alerts or get_energy_breakdown, though the commodity list implicitly defines scope.

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 tier-based usage constraints (free tier = 5 commodities, paid = 31), which helps users understand access limitations. However, it lacks explicit guidance on when to choose this tool over siblings like get_commodity_volatility_alerts or get_energy_breakdown.

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 disclosure. It successfully explains the validation methodology (Granger-causal, p≤0.01), return value semantics (ACTIVE, WATCH, CLEAR), data sources (GDI/SMI), and access restrictions (paid tier). It lacks operational details like rate limits or error handling, but covers the essential behavioral contract adequately.

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?

Four sentences with zero redundancy. Information is front-loaded (action and resource first), followed by methodology details, return values, and access constraints. Every sentence adds distinct value: sentence 1 defines scope, sentence 2 explains statistical rigor, sentence 3 documents return statuses, and sentence 4 states tier restrictions.

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 compensates effectively by enumerating the return statuses (ACTIVE, WATCH, CLEAR) and explaining the signal composition. For a zero-parameter tool with no annotations, the description provides sufficient context to understand the tool's domain (predictive supply chain/economic indicators) and invocation requirements.

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 contains zero parameters. Per evaluation rules, 0 params equals a baseline score of 4. The description appropriately does not invent parameter documentation where none exist, while the '100% schema description coverage' indicates the schema itself is complete (trivially true for empty schemas).

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 uses a specific verb ('Get') and resource ('statistically validated leading indicator signals'), and clearly distinguishes from siblings by specifying unique data sources ('live GDI and SMI data') and statistical methodology ('Granger-causal relationship'). It differentiates this from generic data retrieval tools like get_commodity_prices or get_manufacturing_index by emphasizing the predictive signal nature and validation criteria.

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 the constraint 'Paid tier only' which acts as a prerequisite, but does not explicitly compare this tool to siblings like get_disruption_alerts or get_supply_chain_risk. Usage must be inferred from the detailed explanation of what the tool returns (ACTIVE/WATCH/CLEAR statuses) and its statistical validation methodology.

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 empty annotations, the description carries the full disclosure burden. It compensates partially by detailing return values ('FAA ground delays, ground stops...disruption score') and noting 'real-time' data characteristics. However, it omits operational details like caching behavior, rate limits, permission requirements, or explicit safety classification that annotations would typically provide.

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 four-sentence structure is optimally organized: action definition, return payload specification, coverage scope, and target audience/use case. Each sentence delivers distinct information with zero redundancy, making it appropriately dense and front-loaded with the most critical selection criteria.

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 effectively compensates by enumerating specific return fields (ground delays, closure status, traffic collapse detection). It adequately covers the tool's domain for a simple read operation, though it could be improved with safety annotations or error behavior disclosure.

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 zero parameters, the baseline score applies. The description appropriately makes no mention of input parameters while implicitly defining the scope through enumerated coverage airports (Memphis, Louisville, etc.), effectively documenting the tool's fixed filtering behavior without requiring explicit parameters.

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 opens with a specific verb-resource combination ('Get real-time air cargo disruption status') and clearly distinguishes this tool from siblings like get_port_congestion_trends or get_rail_freight_status by specifying 'airports' and 'air cargo.' It further differentiates by listing specific hub airports (Memphis, Louisville, Anchorage) that this tool covers.

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 implied usage context through target user personas ('air freight forwarders, express carriers, and logistics planners') and the use case ('to reroute time-sensitive shipments'). However, it lacks explicit guidance on when to select this over similar sibling tools like supply_chain_disruption_alerts or get_intelligence_briefs, or when-not-to-use conditions.

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

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

With no annotations provided, the description carries the full disclosure burden. It effectively communicates the data source (US Customs and Border Protection), update frequency (every 30 minutes), and return structure (delay in minutes, lanes open, port status). It could be improved by mentioning rate limits or caching behavior, but covers the essential behavioral traits 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 consists of five tightly crafted sentences, each serving a distinct purpose: core function, return values, data provenance/freshness, geographic coverage, and use case. It is appropriately front-loaded with the action statement and contains no redundant or filler content.

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 compensates by explicitly documenting the return values (delay minutes, lane counts, status). For a simple read-only data retrieval tool with no parameters, the description provides complete coverage including data source, update cadence, geographic scope, and practical application context.

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 tool has zero input parameters with 100% schema coverage (empty object). As per the baseline rule for zero-parameter tools, this earns a 4. The description appropriately focuses on the output semantics since there are no input parameters requiring semantic clarification.

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 opens with a specific action verb ('Get') and clearly identifies the resource (real-time commercial border crossing wait times) and scope (US-Mexico and US-Canada). It effectively distinguishes itself from sibling tools like get_port_congestion_trends and get_air_cargo_disruptions by specifying land border ports of entry.

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 usage context in the final sentence, specifying the target audience (logistics companies, freight brokers, trucking operations) and the specific use case (routing cross-border shipments through fastest crossing points). However, it lacks explicit guidance on when NOT to use this tool or named alternatives like get_port_congestion_trends for sea freight.

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 and effectively discloses return values (vessel count, speed, congestion score) and business impact. However, it omits operational details like data refresh rates, coverage limitations, or latency that would be expected for a real-time monitoring tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three well-structured sentences with zero waste: (1) defines scope and geography, (2) specifies return data structure, (3) explains business value. Information is front-loaded with critical identifiers in the opening clause.

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?

Excellent completeness for a zero-parameter tool. Since no output schema exists, the description comprehensively documents return values (counts, speed, scores). It covers what is monitored, where, and why it matters, requiring no additional structured context.

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 tool has zero input parameters, warranting the baseline score of 4. No parameter documentation is required, and the description correctly focuses on behavior and outputs rather than inventing parameter context where none exists.

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 uses specific verbs ('Monitor') and resources ('real-time vessel traffic and congestion at critical maritime chokepoints'), listing exact locations (Suez Canal, Panama Canal, etc.). It clearly distinguishes from sibling tools like port_congestion_monitor by focusing on strategic waterways/canals rather than ports.

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 through the value proposition ('this data detects that signal in real time' regarding global shipping reroutes), but lacks explicit when-to-use guidance or named alternatives. It does not clarify when to choose this over port_congestion_monitor or get_air_cargo_disruptions.

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 successfully discloses the detection logic ('24-hour price change exceeds normal ranges') and return values ('current price, 24-hour change percentage, trend direction, and risk assessment'). Does not mention rate limits or caching, but covers the critical behavioral aspects for a read operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four well-structured sentences: purpose, detection logic, return values, and use cases. Every sentence adds distinct value. Front-loaded with the core action and efficiently 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?

Despite no output schema, the description fully compensates by detailing the return structure and risk assessment components. Given the zero-parameter input and lack of structured annotations, the description provides complete context for invocation and result interpretation.

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?

Input schema has zero parameters. Per scoring guidelines, 0 params = baseline 4. The description correctly does not invent parameters where none exist.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description uses specific verb 'Get alerts' with clear resource 'commodities experiencing abnormal price volatility'. The mention of '24-hour price change exceeds normal ranges' distinguishes it from the sibling 'commodity_price_monitor' which likely tracks general prices rather than volatility anomalies.

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 usage context through specific user personas (procurement teams, commodity traders, supply chain managers) and the exact question it answers ('which commodities are behaving unusually right now?'). Lacks explicit 'when not to use' guidance or direct sibling comparisons, but use cases are sharply 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 carries full burden. It adequately details what data is returned (Fed data categories, GSCPI, EIA forecasts) but omits operational characteristics like data frequency, freshness, caching behavior, or rate limits that would be critical for economic data.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two dense sentences with zero waste. First sentence covers function and return payload; second covers target audience. Information is front-loaded and every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite lacking an output schema, the description comprehensively lists the constituent datasets returned across multiple authoritative sources. Minor gap: does not specify data vintage, frequency, or response structure format.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has zero parameters, warranting the baseline score of 4 per evaluation rules. The description correctly implies no filtering is needed by listing all data categories returned.

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 uses specific verbs ('Get') and resources ('economic indicators') and explicitly distinguishes this from operational siblings by focusing on 'macro backdrop' data (Federal Reserve, PPI, GSCPI, EIA) versus port congestion or freight status.

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?

Clearly identifies target users ('supply chain strategists, procurement leaders') and use case ('macro backdrop for supply chain planning'), but lacks explicit when-not-to-use guidance or comparison to siblings like commodity_price_monitor that might overlap.

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 and comprehensively details return values (8+ specific data categories including WTI/Brent prices, Henry Hub rates, refinery utilization). It discloses the disaggregated nature and temporal aspects ('week-over-week changes'). Minor gap: lacks operational details like data freshness or caching 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?

Four sentences efficiently structured: purpose declaration, detailed return value specification, architectural context (GDI Energy pillar), and user persona targeting. Every sentence provides distinct value with no redundancy or filler content.

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 the absence of an output schema, the description comprehensively compensates by enumerating all major data categories returned (crude oil, natural gas, retail fuels, storage levels, refinery rates, petroleum stocks, trade flows). Sufficient for an agent to understand the tool's complete utility.

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 contains zero parameters (empty object), establishing a baseline of 4 per evaluation rules. The description appropriately does not invent parameter semantics where none exist, correctly indicating this is a parameterless snapshot retrieval.

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 uses specific verbs ('Get') and clearly identifies the resource ('comprehensive US energy market status') and scope ('supply chain cost analysis'). It effectively distinguishes from siblings by positioning itself as the 'disaggregated view behind the GDI Energy pillar' versus tools like risk_pillar_breakdown that provide aggregated risk numbers.

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 defines when to use this tool versus alternatives: it contrasts 'the full picture' with 'a single risk number,' clearly guiding users to alternatives like risk_pillar_breakdown for aggregated views. It also specifies target personas ('supply chain cost analysts, transportation managers') to clarify appropriate usage contexts.

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 carries full behavioral burden. Discloses key output structure details: distinguishes historical vs projected data using 'isActual flag' and lists specific energy metrics returned. Could improve by mentioning temporal scope of forecasts or caching 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?

Four well-structured sentences with zero waste: opens with source identification, details returned data types, establishes credibility ('most widely referenced'), explains key output flag (isActual), and closes with use cases. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, but description compensates effectively by detailing what gets returned (historical/forecast flag, specific energy categories) and identifying the authoritative source. Missing only temporal scope (how many months/years of projections).

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?

Zero parameters present per input schema. Description correctly omits parameter discussion rather than inventing constraints. Baseline 4 applies as there are no parameters requiring semantic clarification beyond the empty 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?

Specific verb-resource combination ('Get... Short-Term Energy Outlook') and explicit data source (US EIA STEO) clearly distinguishes this from logistics-focused siblings like get_air_cargo_disruptions or commodity_price_monitor. Lists specific energy data types (crude oil, natural gas, electricity, renewables, petroleum) to define scope precisely.

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 implied usage context through user personas ('Used by energy traders, logistics companies...'), indicating when this data is relevant. However, lacks explicit comparison to siblings like commodity_price_monitor or get_energy_breakdown, and provides no exclusions or '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 are provided, so the description carries full disclosure burden. It successfully identifies the data source (Bureau of Transportation Statistics) and comprehensively lists return values. However, it omits operational details such as data update frequency, historical range available, or rate limiting constraints that would help agents plan invocation strategy.

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?

Four sentences with zero waste: sentence 1 defines the action and source, sentence 2 inventories the specific data returned, sentence 3 provides analytical context, and sentence 4 identifies the target user. Information is front-loaded with the core retrieval 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 absence of an output schema, the description compensates effectively by enumerating the specific indices and metrics returned (TSI, inventory-to-sales ratio, industrial production index, etc.). For a zero-parameter retrieval tool, this provides sufficient context for invocation, though data format specifics would elevate it further.

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 contains zero parameters (empty properties object), establishing a baseline of 4. The description correctly does not invent parameter explanations, maintaining alignment with the schema. No additional parameter guidance is required or provided.

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 opens with a specific verb ('Get') and precise resource identification ('US freight transportation health index from the Bureau of Transportation Statistics'). It distinguishes from siblings like 'get_rail_freight_status' or 'get_economic_indicators' by enumerating the specific multimodal metrics returned (TSI, truck tonnage, rail carloadings, waterborne freight).

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?

Identifies the target audience and use case ('logistics companies, freight brokers, and economic analysts tracking US freight demand trends') and provides business context for interpretation ('Declining freight volumes are a leading indicator of economic slowdown'). Lacks explicit 'when not to use' guidance or direct sibling comparisons, though the content specificity serves as implicit 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 provided, the description carries full burden and effectively discloses what the tool returns: current GDI score, multi-day comparisons, directional velocity, and pillar-level momentum. It also explains interpretive value (accelerating vs. decelerating risk). Lacks only operational details like caching or rate limits, but successfully describes the analytical 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?

Four sentences efficiently cover: 1) core function, 2) specific return data points, 3) analytical insights provided, and 4) target users/use cases. No redundancy or wasted words; information density is high with the most critical action stated first.

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 compensates by detailing return values (current score, time-series comparisons, direction, velocity) and interpretive context ('Is supply chain risk getting better or worse'). With zero parameters to document, the description provides complete information necessary for tool selection and result interpretation.

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?

Input schema contains zero parameters, establishing a baseline of 4 per scoring rules. The description appropriately requires no parameter clarification since the tool appears to return a standardized analysis without user-configurable filters.

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 opens with a specific verb ('Get') and resource ('Global Disruption Index'), clearly defining the tool's function. It further distinguishes itself from siblings through specific metrics (7/14/30-day comparisons, velocity, pillar-level momentum) that signal this is a time-series trend tool rather than a static assessment.

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 contextual guidance by identifying specific user personas (supply chain executives, traders) and use cases (weekly status briefings, timing entry/exit decisions). While it doesn't explicitly name alternative tools to avoid, the specific temporal focus ('trend analysis over time') implicitly guides selection against static snapshot tools like risk_pillar_breakdown.

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 carries full burden. Discloses key behavioral traits: generation frequency ('every hour'), data provenance ('AI-generated from live data'), processing level ('synthesized' vs raw), and output format ('structured briefs'). Lacks details on caching, idempotency, or error 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?

Five sentences with zero waste. Front-loaded with core action and resource, followed by content details, behavioral characteristics, audience targeting, and output format. Every sentence adds distinct value beyond structured fields.

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 compensates adequately by explaining return content ('narrative analysis, key drivers, emerging risks'), format ('structured briefs'), and consumption patterns ('executive dashboards, email digests'). Covers the essential context for a zero-parameter retrieval 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?

Zero parameters per input schema, establishing baseline score of 4. Description correctly implies no filtering is needed by stating it retrieves briefs for 'each supply chain dimension,' confirming the empty schema is intentional.

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?

Specific verb ('Get') and resource ('AI-generated intelligence briefs') with clear scope covering all supply chain dimensions. Effectively distinguishes from sibling raw-data tools (e.g., commodity_price_monitor, get_economic_indicators) by emphasizing 'synthesized analytical summaries' versus 'raw data'.

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 usage context ('Designed for decision-makers who need a quick read') and implicitly contrasts with raw data alternatives ('These are not raw data'). However, does not explicitly name specific sibling tools to use for granular/raw data needs or mention the weekly brief alternative.

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

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

Since annotations are empty, the description carries full burden and adequately explains behavioral traits: it clarifies return format (SMI score + 7-day ranked anomalies), interprets signal meanings (drops=shutdowns, surges=ramp-ups), and discloses methodology (weather normalization). Missing operational details like rate limits or auth requirements prevent a perfect score.

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?

Four well-structured sentences with zero waste: sentence 1 establishes purpose, sentence 2 details scope and interpretation, sentence 3 specifies return values, and sentence 4 explains methodology and use cases. Information is front-loaded with the core value proposition.

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, so the description appropriately explains return values (SMI score, regional breakdown, 7-day anomaly history). It also defines the SMI acronym, lists all 8 monitored regions, and explains the patent-pending methodology—providing sufficient context for a complex data retrieval 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?

Input schema contains zero parameters, establishing a baseline of 4. The description appropriately requires no parameter explanation, though it implicitly confirms no filtering is available by specifying the fixed scope (8 regions, past 7 days).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description uses specific verbs (Detect, Monitors, Returns) and clearly identifies the unique resource (electricity demand patterns across 8 specific US power grid regions). It distinguishes from siblings like manufacturing_output_indicator or supply_chain_disruption_alerts by specifying the proprietary SMI methodology and weather-normalized electricity approach.

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 usage context by specifying the tool identifies disruptions 'before they appear in official reports' and names specific user personas (commodity traders, procurement teams). However, it lacks explicit 'when not to use' guidance or direct comparisons to sibling alternatives like get_energy_breakdown or manufacturing_output_indicator.

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 disclosure burden. It effectively explains behavioral traits: analysis against 'historical baselines', identification of 'accelerating' congestion, and flagging of 'critical thresholds'. It also discloses practical applications (rerouting before peaks, anticipating lead times) that inform the agent about the tool's analytical depth.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized at three sentences, front-loaded with the core purpose ('Get port congestion trend analysis'), followed by behavioral details, and closing with specific use cases. Every sentence adds distinct 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 the absence of an output schema and annotations, the description adequately compensates by explaining what the tool conceptually returns (historical comparisons, acceleration indicators, threshold flags). It covers the essential behavioral context needed to understand the trend analysis capability.

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 tool has 0 parameters and 100% schema description coverage, which per guidelines establishes a baseline of 4. No parameter explanation is required in the description, and none is provided, which is appropriate for this parameterless tool.

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 'Get port congestion trend analysis' with specific focus on 'direction and trajectory' and 'not just current congestion', clearly distinguishing it from the sibling tool 'port_congestion_monitor'. It uses specific verbs and resources that precisely define the scope.

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 usage context through the question 'Which ports are getting worse and how fast?' and specific use cases for 'logistics planners' and 'importers'. It implies differentiation from current-state monitoring via 'not just current congestion', though it doesn't explicitly name 'port_congestion_monitor' as the alternative for current snapshots.

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 behavioral burden and excels by disclosing statistical validation thresholds (p<=0.01, >=55% accuracy), prediction horizons, return status semantics (threshold crossed vs approaching), and signal structure (58 signals across 3 tiers). No contradictions with empty 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 consists of six information-dense sentences, each earning its place: methodology, validation thresholds, prediction targets, return values, signal organization, and use cases. No redundancy despite covering complex statistical concepts.

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 compensates by detailing return values (ACTIVE/WATCH/CLEAR with semantic meanings), signal cardinality (58 signals, 3 tiers), predictor categories (GDI pillars, SMI regions), and use cases. Complete for a complex predictive analytics 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 input schema contains zero parameters. Per evaluation rules, zero-parameter tools receive a baseline score of 4. The description implies fixed signal sets (58 signals organized by predictor group) but does not need to explain parameter semantics since none exist.

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 as providing 'statistically validated leading indicator signals' for supply chain data, distinguishing it from reactive monitoring tools through explicit methodology (Granger-causal, p<=0.01) and forward-looking scope (1 week to 6 months ahead). It specifies exact return values (ACTIVE/WATCH/CLEAR) and distinguishes from siblings via the predictive/leading indicator focus versus tools like commodity_price_monitor.

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 usage context by identifying specific personas (commodity traders, procurement teams, hedge funds) and use cases (forward-looking positioning, buy/defer timing). However, it lacks explicit 'when not to use' guidance or direct comparison to similar tools like get_action_signals or get_signal_narratives.

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 adds valuable context about data provenance (Surface Transportation Board, AAR, USDA) and business impact (early warning capabilities). However, it lacks operational details such as whether data is real-time vs. historical, caching behavior, or rate limits.

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?

Three well-structured sentences: (1) specific metrics retrieved, (2) authoritative data sources, (3) business value proposition. Every sentence earns its place with no redundant fluff. The metrics list is long but necessary for specificity.

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 comprehensively enumerates the returned data points in the first sentence. It adds data source transparency and business context. It could improve by indicating the temporal granularity or format of the returned data.

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 contains zero parameters. According to the scoring rubric, 0 params equals a baseline score of 4. The description appropriately does not invent parameter semantics where none exist.

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 'Get US freight rail performance metrics' followed by a comprehensive list of specific metrics (train speed, dwell time, carloadings, etc.). It clearly distinguishes itself from siblings like get_air_cargo_disruptions and get_port_congestion_trends by focusing specifically on US rail network data.

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 usage context in the final sentence: 'When rail slows down, inland supply chains back up within days — this data provides early warning of freight bottlenecks.' This signals when to use the tool (monitoring inland supply chain risks) but does not explicitly name sibling alternatives to avoid.

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 empty annotations, description carries full burden and successfully discloses return structure ('trigger context, predictor value, direction, and a narrative paragraph') and output format suitability ('reports and briefings'). Lacks explicit safety hints (read-only) but 'Get' implies safe read operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences, zero waste: sentence 1 defines action, sentence 2 explains content, sentence 3 identifies audience/differentiation, sentence 4 specifies returns. Front-loaded with core purpose and appropriately dense.

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 0 parameters and no output schema, description adequately compensates by detailing return components (trigger context, predictor value, narrative). Would benefit from mentioning if all active signals are returned or if there's a limit, but sufficient for invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has 0 parameters, warranting baseline score of 4. Description correctly omits parameter discussion since none exist, focusing instead on output semantics which compensates for missing 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?

Specific verb ('Get') + resource ('signal narratives') + scope ('plain-language explanations of active predictive signals'). Effectively distinguishes from sibling 'get_predictive_signals' by emphasizing 'non-quantitative' and 'without reading F-statistics'.

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?

Clearly identifies target audience ('non-quantitative users') and use case ('understand the why'). Implicitly contrasts with quantitative alternatives by mentioning 'F-statistics', though it doesn't explicitly name the sibling tool to use for raw data.

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, description carries full burden. It discloses content scope ('combines all SupplyMaven data sources') implying aggregation heaviness, but lacks explicit operational details: no mention of read-only safety, caching, rate limits, or performance characteristics relative to individual data source tools.

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?

Three sentences efficiently structured: purpose definition, content enumeration, and use case/audience. No redundant phrases; every clause adds distinct value about scope, contents, or consumption pattern.

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?

Compensates well for missing output schema by enumerating specific report components (GDI score, disruption events, manufacturing output, etc.). Lacks explicit output format structure or error condition handling, but adequately covers content given the tool's aggregation 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?

Input schema contains zero parameters. Per scoring rules, 0 params establishes baseline 4. No parameters require semantic 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?

Description explicitly states it creates a 'comprehensive weekly supply chain situation report' combining all data sources into an 'executive-level brief.' It clearly distinguishes itself from siblings (e.g., get_air_cargo_disruptions, commodity_price_monitor) by positioning as the unified aggregation tool versus specialized single-source 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?

Identifies specific use case ('answer what happened this week in supply chains', 'weekly risk reviews') and target audience (executives, procurement leaders). Implies temporal differentiation (weekly vs. real-time) but does not explicitly name sibling alternatives to avoid.

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 empty annotations, description carries full burden and successfully discloses key behaviors: policies persist while in effect (vs 72-hour expiration), they modify GDI risk scores, and returns include structured fields (GDI pillar, score modifier, effective date). Lacks minor details like caching or pagination behavior, but covers primary behavioral traits.

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?

Four sentences each earn their place: (1) defines scope, (2) differentiates from siblings, (3) describes output structure, (4) defines use cases. No redundancy or filler. Information is front-loaded with the action verb.

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, so description compensates by detailing return structure ('Each policy includes the affected GDI pillar, score modifier...'). Explains domain context (trade policy impacts), integration points (GDI risk scores), and target users comprehensively for a parameterless 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?

Tool has zero parameters (empty schema), establishing baseline 4. Description correctly implies no filtering is possible by omission, though it could explicitly state 'returns all active policies' to confirm no parameterization exists.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description opens with specific verb+resource ('Get active trade policy actions') and enumerates exact policy types (tariffs, sanctions, export controls, import restrictions, regulatory changes). It distinguishes from sibling alert tools by contrasting persistence with 'news alerts that expire after 72 hours' and connects to sibling GDI tools by mentioning risk score modification.

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 defines when to use vs alternatives ('Unlike news alerts that expire after 72 hours, policy adjustments persist'), guiding agents to choose this for persistent policy impacts rather than transient alerts. Provides clear personas ('procurement teams navigating tariff exposure, compliance officers tracking sanctions') that map to specific user intents.

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 and successfully discloses key behavioral traits: the content is regenerated 'every Monday,' is 'data-verified' with numbers tracing to live sources, and returns structured multi-platform content. It could be improved by explicitly stating the read-only/idempotent nature of the operation or mentioning caching 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 well-structured and front-loaded with the core purpose, followed by specific deliverables, data provenance, integration context, and detailed content breakdown. While longer than minimal examples, every sentence adds necessary value given the lack of an output schema, though it borders on verbose.

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 adequately compensates by detailing the return structure: specific word counts for Substack/LinkedIn content, tweet counts for Twitter/X, and the inclusion of data contexts (GDI, SMI). It lacks only the specific JSON field names or nesting structure that would make it a 5.

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 contains zero parameters, establishing a baseline score of 4 per the evaluation rules. No parameter explanation is required or provided, which is appropriate for a simple retrieval operation that returns the current week's standardized content package.

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 opens with a specific verb ('Get') and clearly identifies the resource as the 'Signal of the Week' content package. It effectively distinguishes itself from sibling data-monitoring tools (e.g., commodity_price_monitor, get_port_congestion_trends) by specifying this is a pre-written marketing bundle for content distribution rather than raw supply chain analytics.

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 contextual guidance by stating it is 'Designed for automated content distribution via Claude Desktop + platform MCP servers,' indicating the intended integration pattern. However, it does not explicitly state when NOT to use this tool or name specific alternatives like get_supply_chain_weekly_brief that might overlap in weekly cadence.

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 discloses critical behavioral traits: the "INVERTED scale" (lower = stronger), specific interpretation ranges (0-35 STRONG, 36-50 NORMAL, etc.), and methodology (isolating industrial activity from "seasonal heating and cooling noise"). Could improve by mentioning rate limits or data latency, but excellent coverage of interpretation semantics.

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?

Despite length, every sentence earns its place with zero redundancy. Structure is optimally front-loaded: leading indicator claim → methodology → output description → critical scale interpretation → use cases. Complex information (8 region names, scale ranges) is densely packed without fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so description must explain return values; it delivers by specifying "regional and national manufacturing activity scores, trend direction, and comparison to official Federal Reserve Industrial Production data." The inverted scale explanation is essential for correct usage and would be missing if relying on structured fields alone. Thorough for a parameter-less economic data 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?

Input schema contains zero parameters (empty object), triggering baseline score of 4 per rubric. Description appropriately focuses on output semantics and methodology rather than non-existent parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description opens with specific action ("Detect US manufacturing output changes") and unique methodology ("weather-normalized electricity demand across 8 US power grid regions"), clearly distinguishing it from sibling tools like get_economic_indicators or get_manufacturing_anomalies by specifying the proprietary SMI index and electricity-based approach.

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?

Positions the tool against alternatives by noting it provides data "up to 24 hours before official government reports" and compares to "official Federal Reserve Industrial Production (INDPRO) data." Identifies target users ("commodity traders, economic analysts, and hedge funds"). Lacks explicit negative guidance (when NOT to use) but provides clear contextual positioning.

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 and successfully discloses what the tool returns ('vessel counts at berth and at anchor, congestion score versus historical baseline, and port status'). It effectively compensates for the missing output schema by documenting the response 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 three-sentence structure is logical and front-loaded with the core action. The exhaustive port list, while lengthy, serves the necessary function of scope definition. The final sentence about user personas provides legitimate usage context without excessive bloat.

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 adequately explains return values (vessel counts, congestion scores, status). For a parameterless monitoring tool, the coverage of geographic scope, returned metrics, and use cases provides sufficient 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?

The input schema contains zero parameters, which establishes a baseline score of 4. The description correctly requires no additional parameter explanation since none exist to document.

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 monitors 'real-time port congestion and vessel traffic' and specifies the scope (26 major global ports with named examples). It implicitly distinguishes from sibling 'get_port_congestion_trends' by emphasizing 'real-time' versus historical analysis, though explicit differentiation is absent.

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 use cases ('monitor delays, plan routing, and anticipate lead time changes') and target users ('freight forwarders, logistics teams'), offering clear context. However, it lacks guidance on when to use the sibling tool 'get_port_congestion_trends' instead.

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 successfully discloses the return structure (individual scores, trend direction, specific data points driving readings) and enumerates the 31 commodity prices and Federal Reserve indicators composing the dataset. It does not mention caching, rate limits, or data freshness, but comprehensively explains the behavioral output given zero annotation coverage.

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?

Three sentences with zero waste: Sentence 1 establishes purpose, Sentence 2 details the four pillars and their specific components (high information density), Sentence 3 establishes the target user and value proposition. Front-loaded with the action verb and appropriately sized 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?

Given no output schema exists, the description compensates effectively by detailing the four GDI pillars and their sub-components (port congestion, 31 commodity prices, Federal Reserve indicators, etc.). It explains the diagnostic utility. Could improve by mentioning data latency or refresh frequency, but otherwise comprehensive for a zero-parameter 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?

Input schema contains zero parameters. According to calibration rules, zero-parameter tools baseline at 4. The description appropriately focuses on return value semantics rather than inventing parameter documentation, making this score automatic and correct.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description opens with specific verb 'Get' and resource 'detailed breakdown of supply chain disruption risk by category.' It explicitly distinguishes from siblings by defining its unique scope: returning GDI pillar scores (Transportation, Energy, Materials, Macro) with granular sub-components, positioning it as the categorical decomposition tool versus aggregate assessment tools like 'supply_chain_risk_assessment' or single-category tools like 'get_energy_breakdown'.

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 final sentence establishes clear context for when to use: 'Essential for supply chain managers who need to diagnose which risk category is elevated and why.' This implies the tool is for diagnostic/root-cause analysis rather than general monitoring. However, it lacks explicit 'when not to use' guidance or named alternatives for contrast with the 20+ 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, description carries full burden and discloses output structure (severity levels, supply chain stages, risk scores) and critical behavioral constraint (free vs paid tier filtering). Missing operational details like rate limits or data freshness guarantees, but tier disclosure is essential 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?

Four well-structured sentences with zero waste: core purpose front-loaded in sentence 1, return categories in sentence 2, output structure in sentence 3, and usage constraints in sentence 4. Every sentence provides distinct 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?

Despite missing output schema, description compensates effectively by detailing return structure (categorized alerts with severity, stage, risk score) and tier restrictions. Adequate for a zero-parameter retrieval tool, though explicit mention of return format (array vs object) would improve completeness further.

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?

Input schema contains zero parameters (empty object), establishing baseline score of 4. Description appropriately focuses on output behavior rather than parameters, requiring no additional parameter semantics since the schema unambiguously indicates no inputs are required.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description uses specific verb 'Get' with clear resource 'supply chain disruption alerts' and distinguishes from siblings by enumerating specific alert categories (port closures, trade policy, tariffs, etc.) that position it as a general/multi-category intelligence tool versus specific monitors like get_air_cargo_disruptions or get_port_congestion_trends.

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 implicit usage context by listing covered disruption types and explicit tier-based limitations ('Free tier returns critical-severity alerts only; paid tier returns all severities'), but lacks explicit when-to-use guidance comparing it to sibling alternatives like get_air_cargo_disruptions or commodity_price_monitor.

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 disclosure and succeeds in detailing the index composition (200+ live variables, specific data sources like 26 global ports and Federal Reserve indicators) and score interpretation (0-100 scale, higher indicates greater risk). It omits operational details like rate limits or caching behavior, but provides excellent data lineage 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 efficiently structured with four sentences covering purpose, output specification, data provenance, and use cases, with no redundant information; every sentence adds distinct value about the tool's function and output.

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 adequately explains the return value (GDI score, scale, meaning) and calculation methodology, providing sufficient context for a parameter-free assessment tool; it could be improved by describing the complete response structure (e.g., whether metadata or timestamps accompany the score).

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 contains zero parameters, establishing a baseline score of 4 per evaluation rules; the description appropriately requires no parameter explanation beyond implying the assessment requires no user inputs.

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 'Assess[es] current global supply chain disruption risk' and specifies it returns the Global Disruption Index (GDI), distinguishing it from siblings like `get_gdi_trend_analysis` or `risk_pillar_breakdown` by emphasizing it provides a real-time composite score rather than trends or component breakdowns. However, it lacks explicit guidance naming specific siblings to use alternatively.

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 contexts through words like 'current' and 'real-time' (suggesting use for immediate snapshots versus historical analysis) and lists target user personas (procurement teams, logistics planners), but does not explicitly state when to use this tool versus the numerous specialized siblings like `get_port_congestion_trends` or `commodity_price_monitor`.

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