SupplyMaven MCP Server

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 discloses the output (current price and 24-hour change percentage) and important tier limitations. This is sufficient for a read-only monitoring tool, though it omits details like update frequency or authentication requirements, which are not critical for basic usage.

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 concise, starting with the core purpose and then providing a structured list of covered commodities. While the commodity list is lengthy, it is essential for scope clarification and not redundant. The front-loading is effective, and every sentence adds value.

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

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

For a simple tool with no parameters and no output schema, the description is fairly complete: it explains the purpose, the tracked commodities, the return values, and tier limitations. The only notable gap is that the exact set of 5 free-tier commodities is not specified, but this is not essential for initial invocation.

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

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

The tool has zero parameters, and the schema is empty. Per the rubric, 0 params sets a baseline of 4. The description adds no parameter semantics because there are none to explain, but it does clarify that the commodity set is determined by the user's tier, which is useful 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 the tool monitors real-time commodity prices and price volatility for supply chain cost management. It enumerates the specific categories and commodities covered, and explicitly states the return format (current price and 24-hour change percentage). This distinguishes it from sibling tools like get_commodity_volatility_alerts, which focus on alerts rather than price levels.

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 for when to use the tool ('for supply chain cost management') and notes tier restrictions (free vs paid). However, it does not explicitly contrast with alternatives or mention that volatility alerts are handled by get_commodity_volatility_alerts. The use case is clear, but exclusions are implicit rather than stated.

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

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

With no annotations, the description carries the transparency burden. It discloses the statistical basis (Granger causality, p-value), the specific data inputs (live GDI and SMI data), and the output format (statuses). It also notes the paid-tier access restriction, which is a meaningful behavioral constraint. However, it does not mention whether the tool has any side effects, rate limits, or response structure details, but for a read-only data retrieval, this is adequate.

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 exactly three sentences, each contributing distinct value: purpose/data, statistical definition, and output/access. It is front-loaded with the main action and resource, and every sentence earns its place without redundancy. This is model 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 no output schema, the description adequately explains what the tool returns: 'ACTIVE, WATCH, or CLEAR status for each signal.' It also explains the signal's characteristics (lag time, directional accuracy, p-value), giving the agent enough context to anticipate the response. With zero parameters and no output schema, the description fully covers the required information.

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 parameters, so the baseline score is 4. The description adds no parameter-specific information, but none is needed since the input schema is empty. The description's context about data sources and signals indirectly explains what the tool expects (no manual input 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?

The description clearly specifies the tool's function: 'Get statistically validated leading indicator signals evaluated against live GDI and SMI data.' It distinguishes from sibling tools by referencing specific data sources (GDI/SMI) and the statistical methodology (Granger-causal, p≤0.01). The return statuses (ACTIVE, WATCH, CLEAR) further clarify the exact output.

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: when needing statistically validated signals from GDI and SMI data with lag time and directional accuracy. It implies a specialized use case without explicitly naming alternatives, which fits the 'clear context, no exclusions' level. The 'Paid tier only' note adds a usage restriction.

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 what the tool returns: FAA ground delays, ground stops, delay minutes, closure status, disruption score, and traffic collapse detection. This gives strong insight into the tool's behavior without overexplaining. It doesn't mention potential limitations like update frequency, but that's not a major gap.

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

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

The description is three focused sentences: purpose, data returned, and use case. No redundant or vague wording. Every sentence adds value, and it is front-loaded with the core verb and resource.

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 moderate complexity and absence of output schema, the description covers return fields, airport coverage, and target users. It is slightly overbroad in claiming 'international' airports while listing only US hubs, but overall it is sufficiently complete for a 0-parameter 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 tool has zero parameters, so there are no parameter semantics to clarify. Per rubric, the baseline is 4 for no-parameter tools. The description adds context about scope and content, though it doesn't need to explain params.

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') with a clear resource: real-time air cargo disruption status at major freight hub airports. It names specific airports and distinguishes itself from sibling tools focused on other transport modes (rail, border, port).

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: it is used by air freight forwarders, express carriers, and logistics planners to reroute shipments around airport disruptions. It does not explicitly name alternatives or exclusions, but the specialized scope makes the intended use obvious.

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 and does well: it discloses update frequency ('Updated every 30 minutes from US Customs and Border Protection') and return fields (delay minutes, lanes open, port status). It does not explicitly state read-only behavior or limitations, but the nature of the tool makes it 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 concise and well-structured, with four sentences each adding value: purpose, return data, update frequency/source, and coverage/use case. No unnecessary filler.

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 zero-parameter tool with no output schema, the description is entirely sufficient. It explains what data is returned, how fresh it is, where it comes from, and which ports are covered, making it complete for a user to decide 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 input schema has zero parameters, so the baseline is 4. The description adds no parameter-specific details because none are needed, but it does mention that it covers all major commercial crossings, which implies no filtering.

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 with a specific verb and resource: 'Get real-time commercial border crossing wait times at US-Mexico and US-Canada ports of entry.' It distinguishes itself from siblings by focusing on border crossings and listing specific ports, making it 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 provides clear usage context ('Used by logistics companies, freight brokers, and trucking operations to route cross-border shipments through the fastest crossing points'), but it does not explicitly mention when not to use this tool or name alternative sibling tools for comparison.

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 burden. It transparently states the tool monitors and returns data, listing output fields (vessel count, average speed, slow/stationary count, congestion score). It also adds the behavioral context of detecting rerouting signals. However, it does not explicitly mention whether the operation is read-only, but 'monitor' and 'returns' imply it. No side effects are suggested, and the real-time aspect is disclosed.

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

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

The description is three sentences: the first states the core purpose and scope, the second lists the return fields, and the third provides the rationale. It is front-loaded with the key idea, contains no redundant words, and is well-structured.

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 no parameters, no output schema, and no annotations, the description is quite complete. It names the specific chokepoints, lists the return metrics, and explains the signal it detects. It could add details about the time window or data units, but these are minor gaps for a real-time monitor.

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?

There are 0 parameters, so the baseline is 4. The description does not need to explain parameter semantics because there are none. It instead focuses on the tool's output and purpose, which 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 uses the specific verb 'monitor' and clearly identifies the resource: 'real-time vessel traffic and congestion at critical maritime chokepoints'. It lists concrete examples (Suez Canal, Panama Canal, etc.), which distinguishes it from sibling tools like 'port_congestion_monitor' that focus on ports. The return fields are also named, making the purpose unmistakable.

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 for when to use the tool: 'When chokepoints congest or close, global shipping routes reroute within days — this data detects that signal in real time.' This implies a use case but does not explicitly contrast with alternatives or state when not to use it. It gives enough guidance without explicit exclusions.

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

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

With no annotations, the description carries the full burden. It discloses the flag logic (24-hour price change threshold and extreme levels) and return fields (current price, change percentage, trend, risk assessment). It lacks explicit read-only assurance or data freshness caveats, but for a get-style alert tool this is decent 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?

The description is well-structured and front-loaded with the core purpose. Every sentence adds value—purpose, behavior, return fields, and target users. It is concise at around 70 words without redundant repetition of the tool name or schema.

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 no parameters, no output schema, and no annotations, the description covers all essential aspects: what it does, what data it returns, the question it answers, and who uses it. This is sufficient for an agent to select and 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?

The tool has zero parameters, so the schema is trivially 100% covered. No parameter descriptions are needed, and the description doesn't attempt to explain any. Baseline for 0 params is 4, which is appropriate here.

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

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

Description clearly identifies the tool as 'Get alerts for commodities experiencing abnormal price volatility' and specifies the abnormality criteria (24-hour change beyond normal ranges or extreme levels). This distinguishes it from sibling tools like commodity_price_monitor, which likely monitors general price levels rather than volatility alerts.

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 on who should use it (procurement teams, commodity traders, supply chain managers) and the specific question it answers, but does not explicitly state when to avoid it or compare with alternatives. Since the audience and purpose are well-defined but exclusions are missing, it earns a 4 rather than a 5.

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 burden of explaining behavior. It does so by revealing the scoring methodology: 'Each corridor chains origin ports, chokepoints, and destination ports into a single lane scored by its weakest link (highest risk waypoint). Scores combine real-time port congestion data with active natural disaster proximity.' This is meaningful beyond the tool name, though it omits response format and update cadence.

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 and then provides methodological and usage detail in compact sentences. It is slightly dense with the long corridor list, and it claims '10 major corridors' but names only 9, which is a minor structural/conciseness blemish. Overall, 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?

For a parameterless tool without an output schema, the description gives substantial context: the list of corridors, the weakest-link scoring mechanism, the data sources, and the target users. The main gap is that it does not state the output format (e.g., scores, levels, rankings) or update frequency, and the '10 corridors' versus nine listed creates a small completeness gap.

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

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

The tool has zero parameters, and the schema coverage is 100% (vacuously). The description correctly adds context about the fixed set of corridors and the scoring logic, which is all that is needed. No parameter details 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?

The description opens with a specific verb and resource: 'Monitor risk levels across 10 major ocean freight trade corridors.' It names the exact corridors and clearly differentiates this tool from sibling tools like get_chokepoint_traffic or get_port_congestion_trends by focusing on corridor-level risk scoring.

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 user contexts: 'Used by logistics planners for route risk comparison, procurement teams for supply chain exposure assessment, and freight forwarders for disruption early warning.' However, it does not explicitly mention when not to use this tool or name alternative tools for different 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, so description carries burden. It discloses scoring weights, country coverage, score direction, and optional parameter behavior. However, it mentions an optional country parameter not present in the input schema, which could mislead an agent about tool capabilities.

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 concise, well-front-loaded sentences. Each provides distinct value: purpose, data composition, and use audience. No 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?

Covers what is returned (composite score, components, history), coverage scope (21 countries/regions), and intended users. Lacks explicit output format for multi-country queries and parameter syntax for the claimed optional country filter, but sufficient for a high-level 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 has zero parameters, baseline 4, but description claims an optional country parameter. This is a schema contradiction. The description adds misleading information about a parameter that does not exist in the schema, so it fails to provide accurate semantic guidance.

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?

States clearly it retrieves customs friction baseline scores by country, with explicit composite scoring methodology (55% port congestion, 45% policy events), distinguishing it from related tools like get_customs_trade_events and 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?

Targets trade compliance, procurement, and logistics audiences and explains the score's meaning (higher = more friction), implying use cases. Does not explicitly contrast with alternatives or state when not to use, but provides sufficient 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 burden of disclosing behavior. It states the data source (news intelligence), the categories covered, and the exact fields within each event (countries, products, direction, US impact, confidence). It does not mention limitations like pagination or date ranges, but for a simple no-parameter tool, this is adequate.

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 concise, three sentences, with the primary verb and resource in the first sentence. Every sentence adds value: scope, event contents, and target users. No filler or 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 there is no output schema, the description fully explains what the tool returns: event categories, specific fields, and the business context. It is comprehensive for a no-parameter tool and leaves no major questions about what the agent will receive.

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 parameters, so the baseline is 4. The description does not need to elaborate on parameters, and it doesn't attempt to invent any. It focuses on the output content.

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 retrieves customs and trade policy events, enumerates specific coverage areas (tariff changes, sanctions, export controls, etc.), and details the event fields. This specific verb+resource combination distinguishes it from sibling tools by focusing on customs and trade policy events with rich event metadata.

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 clear context for use: 'Used by trade compliance teams and procurement managers to track policy risk.' This makes the intended scenario obvious, though it does not explicitly mention alternatives or when not to use the tool. The context is sufficient for most 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?

With no annotations, the description carries the full burden. It usefully discloses data sources (USGS, NOAA, GDACS), return fields, and auto-expiration based on source TTL. However, it claims 'Supports filtering by event type, country, region, and lookback window' while the input schema has zero properties, creating ambiguity about how filtering is actually performed.

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

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

The description is three sentences, front-loaded with purpose and scope, and every sentence adds value: sources, return data, expiry, and differentiation from the sibling. 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?

The description covers sources, return fields, and TTL, which is helpful given no output schema. However, the unresolved filtering contradiction with the empty schema leaves a significant gap in how the tool is actually invoked, making the description less complete than it appears.

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

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

The schema has 0 parameters, giving a baseline of 4, but the description mentions multiple filtering options that are not reflected in the schema. This adds no useful parameter semantics and instead misleads the agent into thinking filters can be passed as arguments. The description should clarify how filtering works or align with 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?

The description uses a specific verb ('Get') with a clear resource ('active natural disaster events') and states the supply chain context. It distinguishes the tool from the sibling get_natural_disaster_alerts by explicitly saying it complements it with additional filtering options.

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 clearly names the alternative get_natural_disaster_alerts and differentiates this tool by its extra filtering capabilities (multi-day lookback, region-based geography). While it doesn't explicitly state 'when not to use', the context is sufficient for an agent to choose between the two.

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 explicitly lists the return content (Federal Reserve data, PPI by category, GSCPI, EIA forecasts), making clear this is a read-only data retrieval operation with no side effects. It does not address rate limits or output format, but the disclosed scope is sufficient for this simple zero-parameter tool.

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

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

The description is concise, using three sentences that each add value: the first defines the purpose, the second details the data contents, and the third gives usage context. It is front-loaded with the core purpose and avoids fluff or repetition.

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

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

Given the tool's simplicity (zero parameters, no output schema), the description is fully complete. It explains what data the tool returns and the intended user base, which is all the context an agent needs to invoke it correctly. No missing return-value documentation is required since there is no output 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 tool has zero parameters, so the baseline is 4 per the rubric. The description appropriately does not need to explain parameters since there are none, and the 100% schema coverage (empty schema) means no parameter info is missing.

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 with a specific verb ('Get') and resource ('key economic indicators affecting supply chain costs and conditions'). It enumerates the exact data types returned (Federal Reserve data, PPI, GSCPI, EIA forecasts), which distinguishes it from sibling tools that focus on narrower topics like energy or 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?

The description provides clear context for when to use the tool by naming the audience ('supply chain strategists, procurement leaders, economic analysts') and the scenario ('macro backdrop for supply chain planning'). However, it does not explicitly state when not to use it or mention alternative tools, so it misses the top tier of 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 the full burden of behavioral disclosure. It describes what data is returned but does not explicitly state read-only behavior, side effects, or limitations. The 'Get' prefix implies a safe read operation, but it is not stated.

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 structured with a clear main purpose, a detailed list of return data, and contextual framing. Every sentence contributes information without redundancy, and the most important information is front-loaded.

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

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

The description comprehensively lists the data categories and provides context about its use in supply chain analysis. It lacks explicit units or freshness information, but with no parameters and standard energy metrics, it is sufficiently complete for an agent to understand what it will receive.

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 parameters, so the baseline is 4. The description does not discuss parameters because there are none, and the schema coverage is trivially 100%.

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 ('comprehensive US energy market status') and clearly lists the data components, distinguishing it from siblings like get_energy_forecast or risk_pillar_breakdown by framing it as the 'disaggregated view' instead of a single risk number.

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 ('for supply chain cost analysis') and mentions target users, but it does not explicitly state when not to use it or name alternative tools. The 'instead of a single risk number' hint partially addresses this.

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

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

With no annotations, the description carries the full burden. It discloses that it returns both historical actuals and projections, and explains the isActual flag that distinguishes them. It also explicitly states the data content (crude oil, natural gas, electricity, renewables, petroleum). Missing are details like update frequency or data ordering, but the key behavioral aspects are covered.

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

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

The description is three sentences, front-loaded with the primary purpose. The sentence about being 'the most widely referenced energy forecast' adds credibility but is somewhat promotional. The final sentence about users is helpful for context. Overall, every sentence has purpose with minimal 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?

For a tool with no parameters and no output schema, the description is fairly complete. It explains the data source, the types of data, the distinction between actuals and forecasts, and the target audience. It lacks specifics like the forecast time horizon (e.g., 18 months) or update cadence, but these are minor given the STEO is a known product.

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

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

The input schema has zero parameters, so the baseline is 4. The description does not need to explain parameter semantics, but it provides valuable context about what data is returned, which indirectly explains that the tool requires no inputs and returns a fixed dataset.

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 a well-defined resource ('US Energy Information Administration's Short-Term Energy Outlook'), listing detailed contents (crude oil prices, natural gas prices, electricity generation, etc.). It clearly distinguishes this from siblings like commodity_price_monitor or get_energy_breakdown by emphasizing the forecast nature and the isActual flag.

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 states the tool returns official government forecasts and historical actuals, giving clear context for when to use it (e.g., for energy outlook data). It mentions target users (energy traders, logistics companies, macro analysts), which implies use cases. However, it does not explicitly compare alternatives or say when not to use it, but the content is sufficient for basic 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 provided, the description carries the full burden. It discloses that observations include confidence score and source URL, and mentions data origin ('extracted from news intelligence'). However, it does not disclose update frequency, data freshness, pagination, or any limitations. The behavioral traits are partially transparent but not comprehensive.

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

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

The description is three sentences, each adding value: the primary function, the specific indexes and fields, and the target user/use case. It is concise, front-loaded with the verb, and contains no filler. 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?

Given the absence of an output schema, the description does explain return values (direction, magnitude, trade lane, rate values, confidence score, source URL). However, it omits any mention of the time range or history covered, which is relevant for a data retrieval tool. Otherwise, it is complete for a no-parameter 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 has zero parameters, so schema coverage is trivially 100%. Per guidelines, a 0-parameter tool gets a baseline of 4. The description adds no parameter-specific semantics, but none are needed. It suffices that the tool returns a fixed dataset.

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 'Get' and the resource 'freight rate index observations', and lists specific major ocean freight indexes (BDI, SCFI, WCI, CCFI, HARPEX). This specificity distinguishes it from sibling tools like commodity_price_monitor and get_air_cargo_disruptions, though it does not explicitly contrast with get_freight_rate_pressure.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a use case: 'Used by logistics planners to track rate trends and identify cost pressure signals.' However, it lacks explicit guidance on when to use this tool versus alternatives like get_freight_rate_pressure or get_freight_transportation_index. It implies usage context but does not offer exclusions or alternative 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?

With no annotations, the description carries the burden of behavioral disclosure. It specifies the output components (current values, week-over-week changes, z-scores, corridor mapping) and defines the pressure scoring bands. It does not mention auth, rate limits, or failure modes, but provides solid context about the returned 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?

The description is front-loaded with the core function, followed by helpful index definitions and scoring thresholds. Slightly long but every sentence contributes value.

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

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

For a no-input tool with no output schema, the description adequately explains what data is returned and how to interpret pressure scores. It lacks exact response field names but is complete enough for an agent to understand the tool's purpose and output.

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 parameters, so schema coverage is effectively 100% and the baseline is 4. The description adds no parameter-specific information but none is needed.

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 freight rate pressure scores for specific indices (WCI, SCFI, BDI, CRB), with a specific verb and resource. It distinguishes itself from sibling tools by naming the indices and the focus on pressure scores rather than raw observations.

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 freight rate pressure analysis via its specific scope, but does not explicitly state when to use this tool over alternatives like get_freight_rate_observations or get_freight_transportation_index. No exclusions or alternative comparisons are 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, the description carries the behavioral disclosure burden. It states that the tool returns a list of specific metrics, but does not disclose data frequency, time range, or any limitations. The read-only nature is implied by 'Get' and 'Returns,' but additional context could improve 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 three well-structured sentences: the first states the purpose, the second enumerates the returned data series, and the third adds context about the index's economic significance. Every sentence earns its place with no 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 simple no-parameter tool with no output schema, the description is fairly complete: it explains what the tool returns and why it matters. It could mention data granularity (e.g., monthly) or temporal coverage, but overall it covers the essential aspects for typical use.

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?

There are zero parameters, so the description does not need to explain parameter semantics. The baseline of 4 applies because there is nothing missing in terms of parameter guidance, and the description focuses appropriately on output.

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 retrieves the US freight transportation health index from the Bureau of Transportation Statistics, with a specific list of returned series (TSI, truck tonnage, rail carloadings, etc.). This highly specific resource and verb distinguish it from sibling tools such as get_economic_indicators or get_rail_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?

The description indicates the tool is used by logistics companies, freight brokers, and economic analysts tracking US freight demand trends, providing some context for when to use it. However, it does not explicitly mention alternatives or when not to use it, making the guidance implicit rather than explicit.

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

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

With no annotations, the description carries the full burden. It thoroughly explains what the tool returns, including current GDI score, directional trends, velocity, pillar-level momentum, and acceleration/deceleration. It doesn't mention side effects or limitations, but for a read-only analytical tool with no parameters, there is little to disclose beyond these output details.

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 concise and front-loaded, with the core purpose in the first sentence. Each subsequent sentence adds meaningful detail about outputs, interpretation, and use cases without repetition or fluff. It is well-structured for quick comprehension.

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?

There is no output schema, so the description must explain return values. It does so comprehensively, covering the GDI score, comparison periods, direction, velocity, pillar momentum, and acceleration. It also includes target audience and use cases, making it sufficiently complete for an agent to understand what the tool provides.

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 parameters, so the schema is trivially 100% covered. Per scoring guidance, a baseline of 4 applies. The description adds no parameter-specific information, but none is needed since no inputs 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 opens with a specific verb and resource: 'Get trend analysis of the Global Disruption Index over time.' It further details the specific outputs (current score, 7/14/30-day comparisons, direction, velocity, pillar momentum), which clearly distinguishes it from sibling tools by focusing on the GDI trend over time.

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 identifies use cases: 'Used by supply chain executives for weekly status briefings and by traders to time entry/exit decisions around supply chain volatility.' It also frames the tool as answering a specific question (better/worse, how fast, why). However, it doesn't explicitly mention when not to use it or alternative tools, so it lacks an explicit exclusion.

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 and does well by disclosing that briefs are AI-generated, synthesized from live data on an hourly cadence, and contain narrative analysis with key drivers, risks, and watch items. It does not mention potential limitations, such as possible AI inaccuracies or how many briefs are returned, but the core behavioral nature is clearly conveyed.

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 five sentences and is front-loaded with the core purpose. Each sentence adds useful context—content type, cadence, target audience, and output suitability—but it is slightly verbose compared to truly concise examples. All sentences earn their place, but the description could be tightened without losing value.

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

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

Given no parameters, no annotations, and no output schema, the description is quite complete: it explains what the briefs contain, their cadence, target users, and expected output format. It lacks explicit comparison to closely related siblings like get_supply_chain_weekly_brief, but the hourly cadence and dimension-specific focus provide enough context for an agent to select and 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?

There are zero parameters, and the schema is empty, so the parameter semantics are inherently fully covered by the schema. The description adds useful context about the five dimensions covered but does not need to explain parameters since none exist. The baseline score of 4 for a no-parameter tool is appropriate.

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

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

The description clearly states the tool returns AI-generated intelligence briefs for specific supply chain dimensions (energy, materials, transportation, macro, manufacturing), using a specific verb and resource. It further distinguishes itself from raw-data tools by emphasizing these are synthesized analytical summaries, which helps differentiate it from siblings like commodity_price_monitor or get_freight_rate_observations.

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: it is designed for decision-makers needing a quick synthesized read on each supply chain dimension and explicitly notes these are not raw data. However, it does not name alternative tools or state when not to use this tool, so it falls short of an explicit when/when-not 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 the transparency burden. It discloses the source (news intelligence) and the specific fields returned for each event, making the tool's behavior predictable. It does not cover limitations like refresh rate or geographic scope, but for a get tool with no parameters this is adequate.

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

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

The description is four sentences, each adding value: the action, the scope, the data contents, and the use case. It is front-loaded with the main verb and avoids redundancy or filler.

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 simple tool with no schema parameters and no output schema, the description covers the essential aspects: what it does, what data events contain, and who should use it. It lacks minor details like geographic coverage or data recency, but is otherwise complete for an agent to select 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 tool has zero parameters, so parameter explanation is unnecessary. Per the rubric, 0 params earns a baseline of 4; the description adds no param info but none is needed.

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 with a specific verb and resource: it retrieves labor actions affecting supply chains. It enumerates the types of labor actions (strikes, lockouts, slowdowns, etc.) and distinguishes itself from sibling tools that cover other disruption types.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description identifies the intended audience (logistics planners, procurement teams) and use case (assessing labor disruption risk at ports and facilities), giving clear context. However, it does not explicitly mention alternatives or exclusionary scenarios, so it stops short of a full usage guideline.

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

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

With no annotations, the description carries the full burden. It discloses key behaviors: monitoring 8 regions, returning SMI score with regional breakdown and 7-day anomalies, and using weather normalization to isolate industrial demand. This goes beyond basic expectations, though it does not mention limitations, error handling, or data freshness.

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 5 sentences, each earning its place: purpose, regional coverage, output, methodology, and use case. It is comprehensive but not verbose. The front-loaded first sentence immediately conveys the core function.

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 and no annotations, the description is remarkably complete. It explains what data is returned, the geographic scope, the time window, the ranking by severity, and the underlying methodology (SMI). It provides enough information for an agent to invoke the tool correctly and interpret results, making it fully complete for its complexity.

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

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

The tool has 0 parameters and the input schema is empty, so there is nothing to explain. The description adds value by detailing what the tool returns, which compensates for the lack of parameters. The baseline of 4 for zero-parameter tools applies, and the description does not introduce confusion.

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 (detect) and resource (unusual electricity demand patterns signaling manufacturing disruptions), with specific scope (8 US power grid regions) and output (SMI score, regional breakdown, past 7 days anomalies). It distinguishes itself from sibling tools like get_energy_forecast by focusing on manufacturing anomaly detection with a unique index.

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 target users (commodity traders, procurement teams) and the benefit (early manufacturing signals, supply change anticipation). It does not explicitly name alternatives or define when not to use, but the context is strong enough to guide selection.

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?

Annotations are empty, so the description bears the full burden. It discloses information sources, event thresholds (M5.0+), and return fields (magnitude, severity, coordinates, affected country). Yet it does not mention limitations such as update frequency, number of events returned, or output structure. This is adequate but not deeply 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 two concise, front-loaded sentences. The first sentence states the action and sources; the second covers return fields and target users. No redundant or filler content, earning a high score.

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 zero-parameter tool with no output schema, the description covers the essential context: data sources, what events are included, what data is returned, and who benefits. It is slightly incomplete because it does not clarify how this differs from get_disaster_events or describe the output format, but it is sufficient for most agents.

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 parameters, so schema coverage is trivially 100% and the baseline is 4. The description adds value by explaining what the returned data contains and its business relevance, even though there are no parameter details to elaborate.

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

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

The description clearly identifies a specific verb ('Get') and resource ('natural disaster alerts') with explicit data sources (USGS, NOAA, GDACS) and event types (earthquakes M5.0+, hurricanes, etc.). This distinguishes it from generic siblings like get_disaster_events by naming individual agencies and thresholds.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a clear use case: 'Used by logistics planners and procurement teams to reroute shipments and activate contingency plans'. This gives context for when the tool is appropriate. However, it does not explicitly mention when to avoid using it or list alternative sibling tools, so it stops short of full 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?

Given no annotations, the description carries the full burden and does well by disclosing concrete behavioral aspects: comparison to historical baselines, detection of accelerating congestion, and flagging of critical thresholds. It doesn't mention data freshness or limitations, but for a read-only analysis tool this is acceptable.

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 concise and front-loaded with the core purpose. Every sentence earns its place: the first establishes the focus, the second details the outputs, the third answers a clarifying question, and the fourth lists use cases. 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?

For a zero-param, no-output-schema tool, the description gives a complete picture of what the tool returns and who should use it. It lacks specifics like time horizon or update cadence, but these are not essential for selection among siblings, and the differentiation from current congestion tools is clear.

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 parameters, so the input schema provides no semantic information. The description adds meaning about the analysis dimensions (trend, trajectory, historical baseline) without needing to explain inputs. Baseline for 0 params is 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 uses a specific verb 'Get' and resource 'port congestion trend analysis', and clearly differentiates from sibling tools by emphasizing 'not just current congestion, but direction and trajectory.' It answers a concrete question ('Which ports are getting worse and how fast?') and describes the unique analytical value.

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 clear use cases for logistics planners and importers, and implicitly contrasts with current-congestion monitoring ('not just current congestion'). However, it does not explicitly name an alternative tool or state when not to use it, so it stops short of full 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 the full burden. It discloses the return statuses, live data evaluation, and statistical validation, effectively communicating that this is a read-only data retrieval tool 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 efficiently written and front-loaded with the core value proposition. Each sentence adds meaningful detail, though the density could be slightly improved with structured bullet points for 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?

With no output schema, the description explains the key return values (statuses) and provides a broad overview of the content. It doesn't enumerate every field but is sufficiently complete for an agent to understand what the tool offers.

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 parameters, so the baseline is 4 per the rubric. The description adds context about the full dataset (58 signals, 3 tiers, predictor groups) without needing to explain parameter syntax.

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 statistically validated leading indicator signals with ACTIVE/WATCH/CLEAR statuses. It distinguishes from siblings like get_action_signals by emphasizing Granger-causal relationships and specific accuracy thresholds.

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 user context (commodity traders, procurement teams, hedge funds) and use cases, implying when this tool is appropriate. It doesn't explicitly name alternatives or exclusions, but the context is unambiguous.

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 must disclose behavior itself. It names authoritative data sources (STB, AAR, USDA) and explains the tool's early-warning value, which is helpful. However, it does not mention return format, update frequency, or any limitations (e.g., no real-time data, geographic scope). For a simple read-only getter, this is adequate but not rich.

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: the first lists key metrics, the second gives data provenance, the third provides contextual value. It is front-loaded with the action and resource, though the metric list runs long. No wasted words, but slightly 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?

For a zero-parameter tool with no output schema, the description covers what, sources, and why it matters. It is sufficiently complete for an agent to select it appropriately, though it could add a bit more on how the output is structured or when data updates.

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 parameters, so there is nothing to explain. The baseline of 4 applies because the description does not need to add parameter-level detail 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?

The description opens with 'Get US freight rail performance metrics' and enumerates specific metrics (train speed, dwell time, carloadings, etc.), making the tool's purpose unmistakable. The detailed list distinguishes it clearly from the many sibling freight/transportation 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 phrase 'when rail slows down, inland supply chains back up within days' implies a monitoring/early-warning use case, but it does not explicitly state when to prefer this tool over alternatives like get_freight_transportation_index or get_supply_chain_disruption_alerts. Context is present, but exclusions/alternatives are missing.

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 compensates well by disclosing the exact output components ('trigger context, predictor value, direction, narrative paragraph') and the intended use for reports and briefings. It doesn't cover potential limitations or data freshness, but the absence of side effects for a read-only tool is implicitly 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 four sentences, each adding meaningful detail: what it does, what narratives include, target audience, and output components. It is front-loaded with the primary verb and remains focused without unnecessary 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?

Given the tool's simplicity (no parameters, no output schema), the description sufficiently explains the return values and audience. It clearly states that it produces a narrative paragraph with specific fields, which is adequate for a no-arg read tool. Minor gaps like how 'active' is determined or whether results are sortable are not critical for basic usage.

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 parameters, so the baseline is 4. The description adds contextual meaning by mentioning 'active predictive signals' which implies the scope of the data returned, even though there is no input schema to elaborate.

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') with a clear resource ('plain-language explanations of active predictive signals'). It explicitly describes what each narrative contains (mechanism, economic logic, current reading) and distinguishes from sibling tools like get_predictive_signals by emphasizing the non-technical, explanatory nature.

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 clearly targets non-quantitative users and explains the purpose ('understand the why... without reading F-statistics'). This gives clear context for when to use the tool, though it does not explicitly name 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 are provided, so the description carries the full burden. It thoroughly discloses the tool's behavior by enumerating the included data elements and indicating it aggregates all data sources. This gives the agent a clear picture of the report's coverage and tone without hiding any side effects.

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

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

The description is concise yet informative, using four sentences to convey the tool's essence, contents, purpose, and audience. Every sentence adds value, and the most critical information ('comprehensive weekly brief') is front-loaded.

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

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

Given no parameters, no output schema, and no annotations, the description is remarkably complete. It lists the major report sections, explains the intended use case, and identifies the audience, providing sufficient information for an agent to understand what the tool returns and when 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?

The tool has zero parameters, so parameter semantics are not applicable. The description adds context about what the report contains, but since there are no inputs, a baseline of 4 is appropriate for not needing to explain 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 clearly states the tool's purpose: a comprehensive weekly supply chain situation report combining all data sources into an executive-level brief. It lists specific content areas (GDI score, disruptions, manufacturing, commodities, etc.) and names the target audience, distinguishing it from specialized 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 states when to use: 'Designed to answer what happened this week in supply chains? in a single call.' It also mentions the intended users and use cases (weekly risk reviews, stakeholder briefings), providing clear context without needing to exclude 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 carries the full transparency burden. It explains the persistence behavior ('persist as long as the policy is in effect') and the impact on GDI risk scores, plus what each policy includes (pillar, score modifier, effective date, source event). This goes beyond a simple read-only hint, though it omits any mention of response format or potential 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 three sentences, each adding value: purpose, persistence distinction, and output details plus user personas. It is front-loaded and free of 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 no output schema, the description compensates by describing what each policy includes (affected GDI pillar, score modifier, effective date, source event). It also clarifies the persistence behavior that distinguishes it from other signal types, making it sufficiently complete for a no-parameter read 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 tool has zero parameters, and the input schema is empty. The baseline for no parameters is 4, and the description adds no parameter syntax but does not need to. It clearly describes the output content, which satisfies the spirit of parameter semantics.

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 'Get active trade policy actions currently impacting supply chain risk' — a specific verb, resource, and scope. It enumerates the policy types (tariffs, sanctions, export controls) and explicitly distinguishes itself from news alerts that expire, making it clear this tool covers persistent policy adjustments.

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 directly contrasts with news alerts: 'Unlike news alerts that expire after 72 hours, policy adjustments persist as long as the policy is in effect.' It also names primary user personas (procurement teams, compliance officers, supply chain strategists) and their use cases, effectively communicating when to choose this tool over 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 carries the burden of behavioral disclosure. It explains that the package is pre-written, data-verified, and generated from live SupplyMaven data, and that every number traces back to a live source. It does not mention rate limits or side effects, but the described behavior is non-destructive and well-documented.

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 composed of four sentences, each adding meaningful detail: purpose, contents, data verification, and usage context. It is appropriately sized and front-loaded with the verb+resource, though slightly verbose in enumerating every data context element.

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 must explain return values. It does so comprehensively, covering the article formats, word counts, tweet count, and the inclusion of signal headline and data context. It is complete enough for an agent to know what to expect, though it could specify whether return is raw text or file paths.

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 parameters, so the schema is trivially covered at 100%. The description goes beyond schema by detailing exactly what the returned content includes (headline, data context, platform-specific formats), adding value for a 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 opens with a specific verb ('Get') and identifies the resource as the weekly 'Signal of the Week' content package. It clearly differentiates from sibling data-retrieval tools by specifying that it returns a marketing bundle (Substack, LinkedIn, Twitter/X) rather than raw data, making its purpose unmistakable.

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: it is generated every Monday and is designed for automated content distribution via Claude Desktop + platform MCP servers. This implies when to use it, but it does not explicitly name alternatives or exclusion criteria, stopping short of a full 5.

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 behavioral disclosure. It thoroughly explains the methodology (weather-normalization, 8 grid regions), the inverted scale (lower = stronger), the numeric thresholds (0-35 STRONG, etc.), and the output contents (regional/national scores, trend, INDPRO comparison). This goes far beyond a simple 'returns data,' providing rich context for interpreting the tool's output. No contradictions with annotations exist since there are none.

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 in the first sentence, then expands on methodology and output. Each sentence adds value, such as the region list, interpretation scale, and use case. However, it is somewhat verbose—'patent-pending' is marketing fluff and the region enumeration could be shortened without loss. Still, it is well-structured and not overly long for a complex data tool, earning a 4.

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 has no parameters, no output schema, and no annotations, the description must stand alone. It covers what the tool does, how it works, output content, and scale interpretation. It stops short of specifying the exact return format (e.g., JSON field names or data types), which would be helpful without an output schema. But it provides enough context for an agent to know what to expect semantically. Completeness is high but not perfect, so a 4 is appropriate.

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

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

The input schema has zero parameters, so schema coverage is trivially 100%. The baseline for 0 parameters is 4 per the rubric. The description does not need to add parameter semantics, and it doesn't. It focuses on output and interpretation, which is appropriate. There is no parameter information missing because there are none.

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: 'Detect US manufacturing output changes up to 24 hours before official government reports.' It specifies a unique methodology (weather-normalized electricity demand across 8 power grid regions) and output (scores, trend direction, INDPRO comparison), which distinguishes it from sibling tools like get_manufacturing_anomalies or get_economic_indicators. The verb 'Detect' and resource 'US manufacturing output changes' make the function 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 implies when to use the tool: for early detection of manufacturing output changes before official reports. It even names the target users: 'commodity traders, economic analysts, and hedge funds.' However, it does not explicitly contrast with sibling tools or state when not to use it, so it lacks exclusion guidance. This gives clear context but no alternatives, matching a 4.

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 responsibility for behavioral disclosure. It explicitly lists the returned metrics (vessel counts, congestion score, port status) and the full list of covered ports, which informs the agent about the fixed scope. It does not explicitly state 'read-only,' but the verb 'monitor' and the absence of side-effect language imply a safe read operation. It also discloses the real-time nature and historical baseline comparison, providing useful 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 concise at two sentences, yet it packs in purpose, output details, port coverage, and target users. Every sentence adds meaningful information, and the structure flows logically from function to output to use cases.

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 zero parameters, no output schema, and no annotations, the description is remarkably complete. It explains the tool's purpose, the exact data points returned, the geographic coverage, and the intended audience. No critical information appears missing for an agent to decide when and how 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?

The tool has zero parameters, so schema coverage is trivially 100% and the description need not explain parameter syntax. The description adds value by specifying the fixed set of 26 ports and the return fields, which helps the agent understand what the tool will retrieve without any 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's function with a specific verb ('Monitor real-time port congestion and vessel traffic') and resource (26 major global ports). It also specifies the exact outputs: vessel counts at berth and anchor, congestion score vs historical baseline, and port status. This makes the purpose unambiguous and distinct from the generic sibling names.

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 use context: 'Used by freight forwarders, logistics teams, and importers to monitor delays, plan routing, and anticipate lead time changes.' However, it does not explicitly mention when not to use this tool or compare it to alternatives like get_port_congestion_trends, so it lacks explicit exclusions but still gives a strong sense of when it applies.

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 discloses the output structure: for each pillar, the tool returns a score, trend direction, and specific data points driving the reading. It also lists what each pillar covers. This gives a clear picture of behavior without revealing any side effects (which are unlikely for a read-only reporting tool). However, it does not mention data recency, update frequency, or any limitations beyond the listed categories.

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

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

The description is three sentences, each earning its place. The first sentence states the main purpose; the second details the pillars and their components; the third explains the value and target user. There is no fluff, and the most important information is front-loaded. It is appropriately sized for 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?

Given the tool has no parameters and no output schema, the description fully covers what the tool does and what it returns. It explains the categories, the subcomponents within each, and the per-pillar output (score, trend, driving data points). This is complete for a reporting tool, as there are no side effects, prerequisites, or complex parameter interactions to disclose. The only slight gap is the acronym 'GDI' not being expanded, but it is used as a known term in the context of sibling 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?

The tool has zero parameters, so schema coverage is 100% vacuously. The rule sets a baseline of 4 for 0 parameters. The description adds no parameter-specific information because none exist, and it doesn't need to. The absence of params is consistent with a tool that returns a comprehensive breakdown without requiring 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's function with a specific verb ('Get detailed breakdown') and resource ('supply chain disruption risk by category'). It explicitly enumerates the GDI pillars (Transportation, Energy, Materials, Macro) and their subcomponents, distinguishing it from sibling tools that focus on individual pillars (e.g., get_energy_breakdown, 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?

The description provides a clear use case: 'Essential for supply chain managers who need to diagnose which risk category is elevated and why.' This implies when to use the tool (when a high-level diagnosis is needed) but does not explicitly mention alternatives or when NOT to use it. Given the sibling tools are granular, this tool's role as an aggregate breakdown is evident, but the description stops short of direct comparisons.

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 transparently explains what data is returned (categorized alerts, severity, stage, risk score) and highlights the tiered behavior: 'Free tier returns critical-severity alerts only; paid tier returns all severities.' This goes beyond a simple 'get' and is useful for setting expectations. It does not mention rate limits or auth, but for a no-parameter read-only style tool, this is sufficient.

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 uses three sentences with no wasted words. It front-loads the core purpose ('Get real-time supply chain disruption alerts'), then details the output categories and fields, and finally explains tier limitations. Each sentence contributes meaningful information, making it highly concise and well-structured.

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 no parameters and no output schema, the description is remarkably complete. It names the source (news intelligence and event detection), enumerates all alert categories, describes the per-alert structure (severity, stage, risk score), and clarifies tier-based content. There is no obvious missing context that would hinder correct invocation or interpretation of 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?

The input schema is an empty object (0 parameters), so the baseline is 4. The description adds no parameter-specific semantics because there are none to describe. It does mention the tier behavior which could be seen as a contextual option, but not a parameter. Given the zero-parameter schema, the description sufficiently covers the tool's invocation 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 it 'Get real-time supply chain disruption alerts from global news intelligence and event detection.' It lists specific categories (port closures, trade policy, etc.) and return fields (severity, stage, risk score), distinguishing itself from sibling tools that focus on individual categories. The verb 'Get' plus the comprehensive resource makes the 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 implies usage by showing it covers multiple disruption categories, but it does not explicitly say when to use this tool versus alternatives. There is no mention of exclusions or guidance like 'for a specific category use get_disaster_events'. The tier behavior (free vs paid) is a usage nuance but does not clarify tool selection. Thus, only implied usage 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, the description carries a significant burden and explains the score range (0-100), directionality (higher = greater risk), and data sources (200+ variables including ports, commodities, border delays, manufacturing, and Fed indicators). It does not mention potential limitations like data latency or update frequency, which would add further 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 three sentences long and front-loaded with the core purpose ('Assess current global supply chain disruption risk. Returns the GDI...'). Each sentence adds meaningful detail (score scale, data sources, audience), though it could be slightly more concise by trimming the user list.

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 zero-parameter tool returning a summary index, the description is highly complete: it explains what the tool does, how to interpret the score, what data underpins it, and who it is for. The absence of an output schema is mitigated by the clear explanation of the GDI scale and components.

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 accepts zero parameters, and the schema confirms this. The description adds no parameter-specific information because none is needed; the baseline score of 4 applies.

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 ('assess', 'returns') and clearly identifies the Global Disruption Index (GDI) as the resource, explaining its scale and composite pillars. This distinguishes it from sibling tools that focus on narrow metrics like port congestion or commodity prices.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides context by listing target users and use cases ('procurement teams, logistics planners... for real-time supply chain visibility and risk monitoring'). However, it does not explicitly state when to prefer this aggregate tool over the more specific sibling tools or when not to use it, so exclusions are missing.

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