SupplyMaven API Pro

Official

by SupplyMaven-SCR

Overview Schema Related Servers Score Discussions

JavaScript

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.1.0
Disambiguation4/5
While most tools have distinct purposes, there is some overlap between tools like `commodity_price_monitor` and `get_commodity_volatility_alerts`, and between `get_disaster_events` and `get_natural_disaster_alerts`. However, descriptions clarify their different focuses, so ambiguity is minimal.
Naming Consistency3/5
Naming conventions are mixed: many tools follow a `get_` prefix pattern, but several others use noun-first names like `commodity_price_monitor` or `port_congestion_monitor`. This inconsistency could cause minor confusion, but the names are still descriptive enough.
Tool Count4/5
With 34 tools, the server is comprehensive but slightly heavy. Each tool justifies its existence by covering a specific data point or analysis, but the set could be streamlined without losing functionality. Still, the scope of supply chain monitoring warrants this many tools.
Completeness5/5
The toolset is remarkably complete for a supply chain risk monitoring API. It covers commodities, ports, borders, chokepoints, rail, air cargo, freight rates, economic indicators, manufacturing, disasters, policy, predictive signals, and synthesized briefs. No obvious gaps are apparent for the stated domain.
Average 4.2/5 across 34 of 34 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 3 commits in the last 12 weeks
- Last stable release on May 28, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose all behavioral traits. It explains the output and data sources, implying a read-only operation, but does not explicitly state that the tool is non-destructive or whether it requires authentication. The real-time nature is noted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is clear and front-loaded with the purpose. It is somewhat lengthy but each sentence adds valuable detail about pillars and data sources. Could be trimmed slightly without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no input parameters and no output schema, the description provides a good overview of output and data sources. However, it does not specify the return format (e.g., JSON structure), which would improve completeness for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so schema coverage is 100%. The description adds context about what the tool returns, which is sufficient. There is no need for further parameter explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool assesses global supply chain disruption risk and returns the Global Disruption Index. It distinguishes from many sibling tools that focus on specific components, but does not explicitly differentiate from 'get_gdi_trend_analysis' which covers similar ground.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists intended users (procurement, logistics, etc.) but provides no guidance on when to use this tool versus alternatives, or when it is not appropriate. Given many sibling tools, exclusions or criteria would help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so description must cover behavioral traits. It mentions free vs paid tier restrictions, which is valuable. However, it does not disclose rate limits, data freshness, side effects, or idempotency, leaving gaps for an AI agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single, well-structured paragraph that efficiently conveys key information. Every sentence adds value, and 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no parameters, the description must describe return values. It lists categories, severity, stage, and risk score. However, it lacks details like time window, pagination, or sorting, which would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has no parameters, so baseline is 3. Description adds context by explaining the categories and structure of the return data, but since there are no parameters, the added value is limited.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states tool returns real-time supply chain disruption alerts with listed categories, severity, stage, and risk score. However, it does not explicitly distinguish from sibling tools like get_disaster_events or get_trade_policy_impacts, leaving some ambiguity about unique scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description explains what the tool does but does not provide context for when it is appropriate or when other tools should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so description carries full burden. It describes the output (scores based on factors) but does not explicitly state it is read-only or disclose other behavioral aspects like data freshness or permissions. For a simple data retrieval tool with no side effects, this is adequate but not exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose and score range, followed by relevant details on factors and nodes. Every phrase adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 fully covers what the agent needs: it explains the concept, score interpretation, coverage factors, and port nodes. No significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has no parameters, so schema coverage is 100%. Description adds no parameter information beyond what the schema already implies (none), resulting in a baseline score of 3 as per rubric.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool provides Port Readiness scores measuring land-side logistics conditions at major US ports, with score range 0-100. It lists specific factors and 7 port nodes, making the resource specific. However, it does not explicitly differentiate from sibling tools like 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description only explains what the tool does, without suggesting appropriate contexts or exclusions. Sibling tools such as port_congestion_monitor or get_port_congestion_trends are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals the composite score calculation, optional country parameter breakdown, and 30-day history. However, it contradicts the input schema by claiming an optional country parameter that is not defined in the schema, creating confusion about the tool's expected inputs. Annotations are empty, so the description carries full burden, but this error undermines trust.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph of four sentences, efficiently conveying purpose, composition, coverage, and usage. No extraneous words are present, though it is slightly longer than necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the output format (composite score, optional breakdown with components and history) and intended use. Without an output schema, it provides sufficient understanding. However, it does not clarify the default behavior when no parameter is provided (e.g., returns all countries), which would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions an 'optional country parameter' but the input schema defines zero parameters (schema_description_coverage=100%). This is a contradiction: the description adds meaning that does not align with the actual schema, misleading the agent about how to invoke the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves composite customs friction baseline scores by country, detailing the score composition (55% port congestion + 45% trade policy), coverage of 21 countries across multiple regions, and the optional country parameter for detailed breakdown. This is specific and informative, although no explicit differentiation from sibling tools is provided.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description identifies target users (trade compliance teams, procurement managers, logistics planners) and the use case (assess customs clearance risk by country). It does not explicitly state when not to use or suggest alternatives among sibling tools, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that events auto-expire based on source TTL, which is useful. However, it does not mention whether the tool is read-only, rate limits, or any destructive behavior, leaving gaps in 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise at four sentences, but it repeats filtering capabilities and could be restructured for brevity. It front-loads the purpose effectively, but includes some redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lists return fields (event type, severity, location, coordinates, affected country) and mentions auto-expiry, which partially compensates for the lack of output schema. However, the mismatch between described filters and empty schema undermines completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, yet the description mentions filtering by event type, country, region, and lookback window. This mismatch is confusing and misleading. With 0 params, the description should clarify the lack of parameters or align with the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves active natural disaster events relevant to supply chain operations, names multiple data sources, and specifies return fields. It explicitly differentiates from the sibling tool 'get_natural_disaster_alerts' by highlighting 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description contextualizes usage by stating it complements a sibling tool with more filters, such as multi-day lookback and region-based filtering. It doesn't explicitly state when not to use, but the guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description implies read-only behavior and mentions the index is a leading indicator, but lacks details on update frequency, data freshness, or any limitations. Adequate but could be more transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured and informative, but slightly verbose. The first two sentences are clear, while the third adds context. Could be tightened without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 the return values by listing the indicators. It provides sufficient context about the tool's relevance and use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so baseline is 4. The description adds significant value by enumerating the specific indicators returned (TSI, truck tonnage, etc.), which is not present in the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool gets the US freight transportation health index from a specific source (Bureau of Transportation Statistics). Lists specific components (TSI, truck tonnage, etc.) and distinguishes it from sibling tools by focusing on freight health.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions target users (logistics companies, freight brokers, economic analysts) and context (tracking US freight demand trends), but does not explicitly state when to use this tool over alternatives like get_freight_rate_observations or get_rail_freight_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It details the outputs: current score, comparisons, direction, velocity, pillar momentum, and risk acceleration. It also frames the questions answered. However, it omits any mention of limitations, data freshness, or authentication requirements, which would make it more transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient and front-loaded. It starts with the core purpose, then expands on specific metrics, and ends with use case examples. Every sentence adds value with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has zero parameters and no output schema, the description provides a thorough overview of what the tool returns and its purpose. However, it could be more complete by specifying data range defaults or score interpretation, but overall it is sufficiently informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the description naturally cannot add parameter-level meaning. The schema coverage is 100%, so the baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides trend analysis of the Global Disruption Index over time, listing specific metrics (7-day, 14-day, 30-day comparisons, direction, velocity, pillar momentum). While it doesn't explicitly differentiate from siblings, the unique focus on GDI trend implicitly distinguishes it among the many sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for use ('supply chain executives for weekly briefings, traders for timing decisions') but does not explicitly contrast with sibling tools or state when not to use it. It lacks exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It details what data is returned (delays, stops, scores) but does not mention data source, update frequency, rate limits, or whether the tool is read-only. This partially informs behavior but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with a clear front-loaded purpose. It efficiently lists key data points and airports without redundancy, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers the main output elements (delays, stops, closure status, score) and lists covered airports. It lacks details like disruption score calculation or update frequency, but for a tool with no parameters and a clear domain, it does a good job.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (0 params), so baseline score is 4. The description adds value by specifying the types of disruption data returned and the covered airports, which is useful context beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool retrieves real-time air cargo disruption status at major freight hub airports, listing specific delay types and airports. It distinguishes from siblings by focusing on air cargo hubs rather than broader supply chain disruptions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states it is used by air freight forwarders and logistics planners for rerouting, implying usage context. However, it does not explicitly mention when not to use this tool or compare it to sibling tools like get_port_disruption_index or get_natural_disaster_alerts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully disclose behavior. It mentions paid tier and statistical methodology, but doesn't disclose side effects, rate limits, or what happens with no signals. Partial transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences that front-load the main purpose, then detail, then condition (paid tier). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description must explain returns. It mentions statuses and methodology but not exact output structure. Adequate but not complete for a statistical tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0 parameters (100% coverage), so baseline is 4. Description adds no param info, which is appropriate since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves statistically validated leading indicator signals for GDI and SMI, specifying Granger-causal relationships with p≤0.01, lag time, and directional accuracy, and returns statuses (ACTIVE, WATCH, CLEAR). This is a specific verb+resource and distinguishes from siblings like get_predictive_signals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when needing leading indicator signals for GDI and SMI, and mentions it's paid tier only. It lacks explicit when-not-to-use or alternative tools, but the specificity provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides moderate behavioral context: it extracts events from news intelligence and includes attributes (direction, confidence score). However, it omits details on update frequency, pagination, or limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that front-loads the purpose and then elaborates on content. It is relatively concise but could be more structured with bullet points or clearer separation of details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description covers what the tool returns: events with country, product, direction, US impact, and confidence. It is fairly complete but lacks explicit mention of the return format (e.g., list of events).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so the baseline is 4. The description does not need to add parameter details, and it appropriately avoids redundant information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the verb 'get' and resource 'customs_trade_events', clearly stating it retrieves policy events from news intelligence. It details coverage (tariff changes, sanctions, etc.) and differentiates from siblings by focusing on policy risk tracking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly guides usage by stating the tool is used by trade compliance teams and procurement managers to track policy risk. However, it does not explicitly state when to avoid it or contrast with alternatives like get_trade_policy_impacts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as data freshness, rate limits, authentication requirements, or read-only safety. While the tool appears to be a simple query, the absence of transparency about potential costs or side effects leaves gaps for an AI agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is extremely concise (three sentences) with the main action and coverage stated upfront. Every sentence adds value: first defines purpose, second details content, third identifies users. No redundant or vague statements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, no output schema, and no annotations, the description fully explains what the tool returns (labor events with specific fields) and its intended use case. An AI agent has sufficient information to understand when to invoke this tool for labor disruption analysis.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has zero parameters, so the baseline is 4. The description adds no parameter information, but none is needed since schema coverage is 100% and there are no inputs to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves labor actions from news intelligence, explicitly listing covered types (strikes, lockouts, slowdowns, contract negotiations, protests) and specific fields (union, employer, location, etc.). It distinguishes from sibling tools by focusing on labor-specific disruptions, contrasting with broader tools like get_disaster_events or get_action_signals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides clear context by identifying target users (logistics planners, procurement teams) and use case (assessing labor disruption risk at ports and manufacturing facilities). However, it lacks explicit guidance on when not to use this tool or how it compares to siblings beyond the implied domain specificity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the report content truthfully but does not disclose any behavioral traits like idempotency, data freshness, or potential side effects. For a read-only tool, this is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single coherent paragraph of about 100 words, efficiently listing the key components and audience without redundant phrases. Front-loaded with the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description provides sufficient context: the content, audience, and purpose. It explains exactly what the agent can expect. Leaves no major ambiguities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is empty. The description adds meaning by detailing what the output contains, compensating for the lack of structural guidance. Baseline 4 for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a comprehensive weekly supply chain situation report combining all data sources. It lists specific components (GDI score, disruption events, etc.) and positions it as an executive-level brief. This fully distinguishes it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states it is designed to answer 'what happened this week?' and targets executives and managers for weekly reviews. It implies this is the go-to high-level summary, though it does not explicitly say 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With empty annotations, the description carries full burden. It discloses return fields and real-time nature, but does not mention limitations, update frequency, or any side effects beyond being a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences: purpose, return contents, and significance. No wasted words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 purpose, data fields, and real-world relevance. It misses details like update frequency or data reliability, but is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so the description adds value by explaining that the tool returns data for all chokepoints without configuration. This compensates well for the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: monitoring real-time vessel traffic and congestion at critical maritime chokepoints. It lists specific locations and return fields, distinguishing it from sibling tools like port_congestion_monitor which focus on ports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for when to use the tool (e.g., to detect chokepoint congestion signals) but does not explicitly exclude alternatives or provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and explains key behavioral traits: scoring by weakest link, combining real-time port congestion and natural disaster proximity. It does not mention update frequency or auth requirements, but the core behavior is well-described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph but packs substantial information (corridors, methodology, use cases) in about 80 words. It is front-loaded with the main purpose. Minor improvement could be structuring with bullets or sub-sections, but overall it is concise and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains what the tool does and for whom, but it does not specify the output format (e.g., list of corridors with scores, data structure). Since there is no output schema, the agent must infer the return type. Adding a sentence about the output would complete the picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100%. By default, no parameter documentation is needed. The description adds no parameter info, but that is appropriate since no parameters exist. Baseline score of 4 is suitable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool monitors risk levels across 10 specific ocean freight corridors, explains the scoring methodology (weakest link), and lists corridors explicitly. It distinguishes itself from sibling tools that cover air cargo, border delays, etc., by being focused on ocean freight corridor risk.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly identifies three user groups (logistics planners, procurement teams, freight forwarders) and their specific use cases (route comparison, exposure assessment, early warning). It does not provide negative guidance or alternatives, but the context is sufficiently clear given the tool's specificity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries full burden. It explicitly states the tool returns data (crude oil prices, etc.), implying a read-only operation with no side effects. While it does not explicitly confirm read-only behavior or mention caching/rate limits, the list of outputs is sufficiently transparent for a data retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured paragraph with three sentences. It front-loads the main purpose, provides a detailed list of outputs, and ends with usage context. Every sentence adds value, though a slightly more concise enumeration might improve it marginally.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 moderate complexity, the description provides a thorough account of the data included and the business context (GDI Energy pillar). It covers all necessary information for an agent to understand what the tool returns and its relevance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters in the input schema, which is fully covered by the schema description (trivially 100%). The description adds no parameter meaning, but the baseline for no parameters is 4. It does not need to compensate for missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a comprehensive US energy market status for supply chain cost analysis. It specifies the exact data returned (crude oil, natural gas, etc.) and distinguishes itself from the sibling 'get_energy_forecast' by noting it is the disaggregated view behind the GDI Energy pillar, offering a full picture rather than 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description identifies target users (supply chain cost analysts, transportation managers, energy procurement teams), which implies usage context. However, it does not explicitly state when to use this tool versus alternatives like 'commodity_price_monitor' or 'get_energy_forecast', nor does it provide exclusions or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It discloses monitoring 8 regions, 7-day anomaly window, and weather normalization, but lacks details on data freshness, update frequency, or any limitations. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Five sentences with front-loaded purpose. Information-dense but clear. Could be slightly more structured with bullet points, but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description fully covers what the tool does, its inputs, outputs, and use cases. No critical information is missing for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and schema coverage is 100%. The description adds value by explaining what the output includes (SMI score, regional breakdown, anomalies), which compensates for no params. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('detect') and resource ('manufacturing disruptions via electricity demand anomalies'). It clearly distinguishes from sibling tools like 'get_port_congestion_trends' by focusing on manufacturing signals from power grid data across 8 US regions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
States the tool provides early signals before official reports and targets commodity traders and procurement teams, giving clear context. However, it does not explicitly state when not to use it or name alternative tools for similar purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description bears full burden. It reveals statistical validation methods, time horizons, and status categories, but does not mention side effects, authentication needs, data recency, or whether results are cached or real-time. Some transparency is provided, but gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-structured. The key information is front-loaded ('Statistically validated leading indicator signals evaluated against live supply chain data'). Every sentence adds unique value, covering statistical basis, output format, organization, and use cases without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 provides substantial context: statistical thresholds, output statuses, signal count and tiers, predictor groups, and target users. It could have described the exact return structure (e.g., JSON fields), but overall it is fairly complete for an agent to understand the tool's output and usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, and schema description coverage is 100% trivially. With 0 parameters, the baseline score is 4. The description does not need to add parameter semantics, and it correctly omits parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 specific statistical criteria (Granger-causal, p<=0.01, directional accuracy >=55%). It details output statuses (ACTIVE, WATCH, CLEAR) and organization across 58 signals and 3 tiers. This specificity goes beyond a simple verb+resource and adequately distinguishes from sibling monitoring tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists target users (commodity traders, procurement teams, hedge funds) and use cases (forward-looking positioning, buy/defer timing, alternative data). While it does not explicitly state when not to use or name alternatives, the context provided is strong enough to guide appropriate tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It describes the data and sources but does not disclose behavioral details such as update frequency, historical range, or any side effects. The description adds some context (sources and strategic use) but falls short of full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first lists metrics and sources, the second provides usage context and strategic value. It is efficient, front-loaded, and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 covers purpose, data sources, and usage context well. It could be improved by hinting at the return format (e.g., snapshot vs. time series), but overall it is sufficiently complete for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters and the input schema is empty (100% coverage). There are no parameters to describe, so the description adds no parameter info, but none is needed. Baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets US freight rail performance metrics and lists specific indicators (train speed, dwell time, etc.). It distinguishes this tool from siblings by focusing exclusively on rail freight, while siblings cover air cargo, port congestion, and other domains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for when to use the tool: 'When rail slows down, inland supply chains back up within days — this data provides early warning of freight bottlenecks.' It does not explicitly state when not to use or directly compare with sibling tools, but the context is clear enough for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It lists the types of data returned (Fed data, PPI, GSCPI, EIA forecasts), but does not disclose update frequency, data freshness, or limitations. The read-only nature is implied but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph of two sentences, concise and front-loaded. It efficiently states what the tool returns and its intended audience, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description fully explains the tool's output by listing specific data sources and the user context. It is complete for an agent to understand the tool's value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters. Schema description coverage is 100% (as there are no params). The description compensates by explaining what the tool returns, which is essential for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns key economic indicators affecting supply chain costs, listing specific data sources (Federal Reserve, PPI, GSCPI, EIA). It distinguishes from siblings by focusing on macro economic context, while siblings are more specific (e.g., commodity_price_monitor, 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies users (supply chain strategists, procurement leaders, economic analysts) and context (macro backdrop for supply chain planning). However, it does not explicitly state when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool returns both historical actuals and forward projections, distinguished by an isActual flag. It mentions the authoritative source (US government) and broad usage, but lacks details on data freshness, rate limits, or access constraints. Overall, it provides sufficient behavioral context for a 0-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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is informative but verbose, with multiple sentences listing specific data items. While it front-loads the main purpose, some details (e.g., the long list of commodities) could be omitted or moved to an output schema. Still, every sentence adds value, but it could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no parameters, the description provides all necessary context: what data is returned, its source, how actuals and projections are differentiated, and typical use cases. There is no missing critical information for an agent to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is 100%. The description does not need to add parameter-level meaning. The mention of an 'isActual flag' refers to the output, not input, so it does not affect this score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 EIA's Short-Term Energy Outlook (STEO) covering production, consumption, and pricing of multiple energy commodities. It names specific data types (crude oil, natural gas, etc.) and distinguishes itself from siblings like commodity_price_monitor and get_energy_breakdown by focusing on official government forecasts with a specific dataset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states target users (energy traders, logistics companies, macro analysts) and provides context on when this forecast is relevant. While it doesn't provide negative guidance (when not to use), the specificity of the STEO dataset makes its application clear relative to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses return contents: current values, week-over-week changes, z-score, trade corridor mapping, and scoring interpretation. Adds context beyond empty annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured, front-loaded with main function, followed by explanatory details. Each sentence contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately describes output for a 0-parameter tool without output schema. Could mention data refresh frequency for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters; schema coverage 100%. Description adds value by explaining indices and scoring beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it returns freight rate pressure scores for WCI and SCFI indices, defining indices and scoring scale. Distinguishes from siblings by focusing on container shipping pressure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use to assess freight cost pressure on specific trade lanes.' No alternatives mentioned, but purpose is clear given no parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that briefs are generated hourly from live data, are synthesized summaries (not raw data), and are suitable for dashboards. No annotations exist, so description carries the full burden, and it does so adequately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose. Some redundancy (e.g., 'synthesized analytical summaries' vs 'not raw data'), but overall clear and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description explains the content type (narrative analysis, key drivers, etc.) and use. Could mention the return structure or format, but sufficient for a zero-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in input schema. Baseline score of 4 applies as per guidelines; description adds no further parameter info but is unnecessary.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it returns AI-generated intelligence briefs covering multiple supply chain dimensions (energy, materials, transportation, macro, manufacturing). Distinguishes from sibling tools that focus on single dimensions or raw data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Specifies the tool is designed for decision-makers needing a quick read. Implicitly suggests high-level overview use case, but does not explicitly contrast with more detailed sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full disclosure burden. It reveals the content is generated weekly (every Monday) and uses verified data, but doesn't detail potential limitations like update cadence or error handling. It is sufficiently transparent for a read-only content retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is comprehensive but slightly verbose. It front-loads the core purpose and adds context, but some details (e.g., 'every number traces back to a live data source') could be inferred. Still, it remains clear and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 the return content and frequency. It lacks details on error conditions or empty results, but for a straightforward retrieval tool with no parameters, this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 description adds meaning by explaining what the tool returns, which compensates fully for the lack of parameters. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool retrieves a weekly 'Signal of the Week' content package, detailing its components (Substack article, LinkedIn post, Twitter/X thread) and data source. This clearly differentiates it from sibling tools that return raw data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes the tool is designed for automated content distribution via Claude Desktop, implying when to use it. However, it does not explicitly state when not to use it or provide alternatives among siblings, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It discloses the output data but lacks details on update frequency, latency, or auth requirements. However, as a read-only monitor, the description 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with clear structure: first sentence states purpose, second lists output, third lists ports and use cases. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description fully covers return values and scope. Lists vessel counts, congestion score, port status, and specifically names 26 ports across regions. Sufficient for an agent to understand the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters (schema coverage 100%), so description doesn't need to explain parameters. It enriches the context by listing covered ports and output fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it monitors real-time port congestion and vessel traffic at 26 major global ports, specifying the returned data (vessel counts, congestion score, port status). It distinguishes from siblings like get_port_congestion_trends by focusing on real-time snapshot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Identifies target users and use cases (monitor delays, plan routing, anticipate lead time changes), but does not explicitly mention when to avoid this tool or contrast with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of transparency. It discloses that the tool returns 'active and recent events with magnitude, severity, coordinates, and affected country.' This sufficiently communicates read-only behavior and output structure without needing extra details like rate limits or authentication needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the tool's function in the first sentence and then providing practical usage and returned fields in the second. Every part adds value without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, no output schema, and no parameters, the description is fairly complete. It covers sources, event types, return fields, and target users. A minor improvement would be to specify the update frequency or definition of 'active and recent' (e.g., last 24 hours).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so schema description coverage is 100%. The description does not need to add parameter details, and the baseline score of 4 is appropriate because it adds no confusion or missing information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: retrieving real-time natural disaster alerts from specific authoritative sources (USGS, NOAA, GDACS) and lists the types of events covered (earthquakes, hurricanes, tropical storms, cyclones, floods, volcanoes). This distinguishes it from sibling tools like 'get_disaster_events' by specifying sources and scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage context by stating it is 'used by logistics planners and procurement teams to reroute shipments and activate contingency plans.' While it gives clear scenarios, it does not explicitly state when not to use it or compare it to similar siblings like 'get_disaster_events', which is a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states policies persist and modify GDI risk scores, and each includes GDI pillar, score modifier, effective date, and source event. It implies read-only behavior via 'get' but does not detail authentication, rate limits, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured paragraph of three sentences. It front-loads the core purpose, adds behavioral context, and identifies use cases. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters or output schema, the description is quite complete, covering content, persistence, use cases, and differentiation from news alerts. It could optionally mention data freshness or pagination, but the current detail suffices for effective tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so schema coverage is trivially 100%. The description adds meaning beyond the empty schema by explaining the output includes affected GDI pillar, score modifier, effective date, and source event, earning a baseline 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves active trade policy actions impacting supply chain risk, listing specific types (tariffs, sanctions, export controls, etc.) and distinguishes itself from news alerts by noting persistence as long as the policy is in effect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies target users (procurement teams, compliance officers, supply chain strategists) and contexts (tariff exposure, sanctions tracking, sourcing adaptation). It contrasts with news alerts that expire, but does not explicitly list when not to use this tool versus the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses return data ('current price and 24-hour change percentage'), tier limitations (free: 5 key commodities, paid: all 31), and real-time nature. No annotations, so description carries full burden and does so thoroughly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Efficient two-sentence structure: first sentence states purpose and scope, second details return data and tiers. No filler, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, input (none), output (price and change), limitations (tiers), and list of commodities. No output schema, but description sufficiently explains returns. Complete for a zero-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in schema, so baseline 4. Description adds no param info, which is appropriate since none exist. Schema coverage 100% (empty), so description not required to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Monitor real-time commodity prices and price volatility for supply chain cost management' with specific verb 'monitor' and resource 'commodity prices'. Lists categories and 31 commodities, distinguishing it from disruption-focused sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage for cost management, but no explicit when-to-use or when-not-to-use compared to sibling 'get_commodity_volatility_alerts', which overlaps in volatility tracking. No guidance on free vs paid tier usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the data source (US Customs and Border Protection), update frequency (every 30 minutes), and coverage (all major commercial crossings). It implies a read-only operation. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at four sentences, front-loaded with the core purpose, and each sentence adds useful context (data, frequency, coverage, use). No waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description fully covers what the tool does, what data it returns, how often it updates, and its typical users. Complete for a no-input tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema coverage is 100% (empty). The description adds value by explaining the output structure (delay, lanes, status) and geographic coverage. Baseline for zero params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves real-time commercial border crossing wait times at US-Mexico and US-Canada ports, with specific data points (delay in minutes, lanes open, port status). It names major crossings and is distinct from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case (routing cross-border shipments by logistics companies) but lacks explicit when-not-to-use or alternative tool guidance. The context is sufficient for most scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since annotations are empty, the description bears full responsibility. It discloses key behaviors: flags commodities based on 24-hour price change exceeding normal ranges or extreme levels, and outputs price, change percentage, trend, and risk assessment. This is transparent for a simple get tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact at four sentences, each providing distinct information: purpose, behavior, user question, and use cases. It is front-loaded with the core action and returns. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no inputs, no output schema), the description fully covers what the tool does, what it returns, and why it would be used. There are no gaps in information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the input schema is trivial (100% coverage). According to guidelines, baseline is 4 when no params exist. The description adds value by explaining the output fields and logic, which further clarifies the tool's behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get alerts') and resource ('commodities experiencing abnormal price volatility'). It clearly distinguishes from siblings like commodity_price_monitor by focusing on volatility alerts rather than general price monitoring. The tool's purpose is unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool (procurement timing, trader opportunities, supply chain cost changes) and indirectly implies it is for abnormal volatility events. However, it does not mention alternatives or when not to use it, which would strengthen guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With empty annotations, the description fully explains the tool's behavior: it returns changes relative to historical baselines, identifies accelerating ports, and flags thresholds. It clarifies it does not just give current congestion, so the agent understands the non-destructive, read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four well-structured sentences with no fluff. It front-loads the purpose, then adds detail and use cases. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and empty annotations, the description provides sufficient context for an agent to understand the tool's capability and use cases. However, it could optionally hint at the return format or data structure to be fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero parameters with 100% coverage trivially. The description adds significant context about the output semantics (trends, acceleration, thresholds), exceeding the baseline of 4 for no-param tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns trend analysis ('direction and trajectory') rather than current congestion, distinguishing it from siblings like port_congestion_monitor. The verb 'get' and noun phrase 'port congestion trend analysis' are specific and informative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases: logistics planners rerouting shipments and importers anticipating lead time extensions. It implies when to use (when needing trends over current state) but does not explicitly name alternative tools or state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. Describes what is returned: trigger context, predictor value, direction, narrative paragraph. No mention of side effects, but since it's a read-only tool with no parameters, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each adding value. Front-loaded with main purpose, then details on content and target audience. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description fully covers what the tool does and for whom. It explains what each narrative includes, meeting all needs for effective invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema coverage 100% (empty schema). Baseline is 4 as description does not need to add parameter info. Description correctly implies no inputs needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it provides plain-language explanations of active predictive signals. The verb 'Get' and resource 'signal narratives' are specific. Distinguishes from siblings like get_predictive_signals by emphasizing narrative over raw data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states it is for non-quantitative users wanting the 'why' behind signals, which implies when to use. Does not explicitly mention when not to use, but context is clear. No alternatives named, but purpose is targeted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description discloses key behavioral aspects: it returns individual pillar scores, trend direction, and specific data points. This sufficiently communicates what the tool does for a read-only operation, though it omits details like data freshness or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with no extraneous information. It front-loads the purpose, then provides relevant detail in a well-structured manner. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description comprehensively covers what the tool returns and its use. It fully addresses the need of the target user without requiring additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the description adds meaning beyond the empty schema by detailing the output structure (pillars, scores, trends, data points). According to guidelines, baseline for zero params is 4, and the description compensates well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a detailed breakdown of supply chain disruption risk by category, listing the four GDI pillars and their components. This distinguishes it from sibling tools that focus on individual categories or aggregate indices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies it is 'essential for supply chain managers who need to diagnose which risk category is elevated and why,' providing a clear use case. However, it does not explicitly advise against use when alternatives like get_energy_breakdown or commodity_price_monitor are more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and reasonably discloses the data source (news intelligence), included metrics (confidence score, source URL, direction, magnitude, trade lane, rate values). It lacks details on update frequency or if results are paginated, but given zero parameters, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences: a clear action-oriented first sentence, a detail expansion in the second, and a use-case sentence. No unnecessary words, well-structured, and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description provides sufficient context: source (news intelligence), specific indexes covered, data fields included, and intended use. It is complete for a simple read-only tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (100% coverage vacuously). The description adds value by explaining what the tool returns without needing to describe parameters. It fully covers the output fields, making it clear what data is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool retrieves freight rate index observations from news intelligence, listing major indexes (BDI, SCFI, WCI, CCFI, HARPEX) and data fields (direction, magnitude, trade lane, rate values). It effectively distinguishes itself from siblings like get_freight_rate_pressure by focusing on observational data with source URLs and confidence scores.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the tool is used by logistics planners to track rate trends and cost pressure signals, giving clear context. However, it does not explicitly indicate when not to use this tool versus alternatives such as get_freight_rate_pressure or get_freight_transportation_index.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It comprehensively discloses methodology (electricity demand data, regional grids), output (scores, trend, comparison), and the inverted scale. It is a read-only tool with no hidden 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, front-loading the key benefit (detection ahead of reports). Every sentence adds value, and 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description fully explains what the tool returns: regional and national scores, trend direction, INDPRO comparison, and the scale. It is complete for a parameterless tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 100%. The description does not need to add parameter meaning but compensates by thoroughly explaining the output and scale.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool detects US manufacturing output changes ahead of official reports using the SMI. It provides specific details on methodology and output, distinguishing it from sibling tools like get_manufacturing_anomalies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates it is used by commodity traders and analysts as a leading indicator, implying usage context. However, it does not explicitly state when not to use or compare to alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![supplymaven-mcp-server MCP server](https://glama.ai/mcp/servers/SupplyMaven-SCR/supplymaven-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/SupplyMaven-SCR/supplymaven-mcp-server)

Score Badge

Copy to your README.md:

[![supplymaven-mcp-server MCP server](https://glama.ai/mcp/servers/SupplyMaven-SCR/supplymaven-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/SupplyMaven-SCR/supplymaven-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/SupplyMaven-SCR/supplymaven-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server