maritime

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

No annotations provided, so description carries the burden. It discloses the types of data returned (throughput, AIS snapshot, sanctions, dark-fleet signals) but does not mention behavioral aspects like rate limits, data freshness, or pagination. Adequate but not comprehensive.

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

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

Three sentences pack all necessary info: chokepoint list, return data types, and usage example. No fluff. Front-loaded with key action.

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

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

Given no output schema, the description provides a good list of return components with specific metrics. Lacks exact structure or handling of invalid inputs, but sufficient for most use cases.

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

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

Schema coverage is 100% with both parameters documented. Description adds value by explaining the alias covers free text and listing the exact chokepoint options. Also ties parameter usage to the rich set of return data.

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

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

Description clearly states it returns chokepoint intelligence for four specified chokepoints, listing specific data types (EIA throughput, AIS snapshot, sanctioned vessels, dark-fleet signals). No sibling tool overlaps, making purpose distinct.

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

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

Provides explicit usage example ('how is Hormuz doing') and context for chokepoint queries. Does not explicitly list when not to use, but the scope is clear from the description and sibling tool names.

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

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

No annotations are provided, so the description carries full burden. It mentions 'Trade partners' implying a read operation, but does not disclose side effects, authentication needs, rate limits, or whether it is idempotent. Minimal behavioral context.

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

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

The description is a single sentence with no wasted words. It front-loads the core purpose. Could be slightly more structured, but it's efficient.

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

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

The tool has 4 parameters, no output schema, and no annotations. The description does not explain the output format, the effect of 'limit', or the possible values for 'direction'. More documentation is needed for an agent to use it confidently.

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

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

The description clarifies that 'country' and 'query' are aliases, and mentions direction defaults to 'exports'. However, it does not explain the 'limit' parameter or provide details for 'country' beyond the alias. Schema coverage is low (25%), so description adds some value but not enough.

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

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

The description clearly states the tool retrieves trade partners (exports/imports) for a specific country, using a specific verb and resource. It distinguishes from sibling tools which cover different shipping topics like chokepoints, emissions, etc.

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

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

The description explicitly tells how to pass the country via 'country' or 'query' parameters. It implies usage for trade flow analysis but does not mention when to avoid this tool or alternatives among siblings.

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

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

No annotations provided, and the description does not disclose behavioral traits such as read-only nature, authentication requirements, or limitations. It merely lists available topics without explaining side effects or preconditions.

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

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

The description is a single sentence that packs substantial detail without being overly verbose, though it could benefit from breaking the list into a clearer structure.

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

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

Given the simple input schema (one enum) and no output schema, the description adequately elaborates on each topic's content, though it does not specify response format or data freshness.

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

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

The single parameter 'topic' has a clear enum with schema description, and the tool description adds rich context (e.g., number of platforms, countries, fraud amount) that goes beyond the schema, aiding correct selection.

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

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

The description clearly states it queries a 'shipping document intelligence layer' and lists specific topics (platforms, mletr, fraud, etc.) with concrete numbers, distinguishing it from sibling tools that address different shipping domains.

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

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

No explicit guidance on when to use vs alternatives, but sibling tools are sufficiently different in scope (e.g., chokepoints, emissions) that this tool's purpose is implied; still lacks explicit usage instructions.

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

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

With no annotations, the description carries the full burden. It discloses the data source, metrics, years, and vessel count. The tool is clearly read-only (query), and no contradictory statements exist. It could add details like pagination or rate limits, but it is adequate.

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

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

The description is two sentences. The first introduces the tool's purpose and scope; the second details search parameters. No superfluous words, and information is front-loaded. Excellent conciseness.

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

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

In the absence of an output schema, the description hints at return fields (CO2, fuel consumption, time at sea). It mentions vessel count and year range. It does not specify pagination or limit behavior, but overall it is fairly complete for a query tool.

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

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

Schema coverage is 80%, and the description adds value by explaining the free-text query behavior (IMO vs type/name), clarifying the IMO parameter is 7 digits, and providing examples for ship_type. This goes beyond the schema descriptions, justifying a score above the baseline of 3.

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

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

The description clearly states the tool queries EU MRV vessel emissions data, specifying the metrics (CO2, fuel consumption, time at sea) and scope (22,543 vessels, 2018-2024). It distinguishes from siblings by focusing on emissions, which is unique among the listed sibling tools.

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

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

The description explicitly explains how to search (by IMO, ship type, year, or free-text query) and clarifies the free-text logic (7-digit = IMO, else type/name). It provides clear context but does not explicitly state when not to use or compare to alternatives.

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

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

No annotations are provided, so the description must fully disclose behavior. It only states query acceptance modes but omits critical details: what happens when both modes are used simultaneously, pagination behavior (only limit param hints at it), performance implications, or the fact that it is a read-only operation (not explicitly stated).

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

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

The description is two sentences, front-loaded with the primary action, and contains no extraneous information. Every word earns its place.

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

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

Given the 5 parameters, no output schema, and no annotations, the description is too sparse. It fails to describe return format, pagination handling, parameter dependencies, or combination rules for structured vs. free-text queries. This leaves the AI agent with significant ambiguity.

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

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

With only 20% schema description coverage (only 'query' has a description), the description adds some value by explaining free-text matching targets (vessel name, IMO, owner, type). However, it does not clarify structured filter parameters (search, company, vessel_type) or their interaction, leaving significant gaps.

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

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

The description explicitly states 'Query tanker fleet database' with a specific verb and resource, and mentions two modes (structured filters OR free-text query). It is clearly distinguishable from sibling tools like shipping_chokepoint and shipping_emissions.

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

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

The description explains the two input modes (structured filters or free-text query) but does not provide guidance on when to use this tool vs. alternatives, nor does it mention prerequisites or exclusions. This is adequate but lacks essential usage context.

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

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

No annotations are provided, so the description carries the full burden. It clearly states the tool is read-only (checking freshness) and describes the output statuses, but does not disclose any edge cases, rate limits, or potential delays in freshness reporting. A score of 3 is appropriate given the sufficient but not exhaustive disclosure.

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

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

The description is extremely concise with two efficient sentences. The first sentence gives the complete purpose and output format, and the second provides a clear usage guideline. No wasted words.

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

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

Given the tool has zero parameters, no output schema, and simple return structure, the description is nearly complete. It explains the output and when to use it. A minor gap is that it does not explicitly state the scope (e.g., which datasets are covered) or any prerequisites, but for a parameterless tool the information provided is largely sufficient.

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

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

The input schema has 0 parameters and the description adds full context on what the tool returns without parameter detail needed. Schema coverage is 100% (no parameters). The description adds meaningful value by explaining the returned fields and status values, which is more than adequate for a parameterless tool.

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

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

The description explicitly states the tool's purpose: checking per-dataset freshness metrics such as pipeline age, cadence, newest record age, source, and status (with enumerated statuses). It clearly distinguishes itself from the many sibling tools by focusing on data freshness rather than chokepoints, flows, emissions, or other topics.

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

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

The description provides explicit guidance on when to use the tool: 'Use before relying on a figure that must be current.' This tells the agent exactly the context in which this tool should be invoked, and there are no alternatives to exclude.

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

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

No annotations exist, so the description must disclose behavior. It only states 'Get oil price benchmarks' without revealing whether it's read-only, rate limits, or data freshness constraints.

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

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

Extremely concise at one sentence, but it sacrifices critical information about parameters and usage, making it under-specified rather than efficiently concise.

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

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

With no output schema, no annotation, and no parameter descriptions, the description fails to provide a complete picture. It leaves significant gaps for an agent to use the tool correctly.

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

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

Schema coverage is 0%, yet the description does not mention the parameters 'days' or 'benchmark' or explain their meaning. The agent has no clue what these parameters do.

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

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

Clearly states the tool retrieves oil price benchmarks and names specific examples (WTI, Brent). The sibling tools cover different aspects of shipping, so this tool is well-distinguished.

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

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

No guidance on when to use this tool versus alternatives, no prerequisites or when-not-to-use context provided.

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

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

No annotations provided; description clarifies this is import/export flow data, not chokepoint throughput, but does not disclose other behavioral traits like response format or data freshness.

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

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

Two concise sentences front-load the purpose and include critical usage guidance with no wasted words.

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

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

Handles 6 parameters with no output schema or annotations; description covers core purpose and key sibling differentiation but lacks details on output format, required context, or additional constraints.

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

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

Adds meaning for 'query' parameter (free-text matching country/notes) but does not describe limit, period, partner, product, or reporter parameters, despite low schema coverage (17%).

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

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

Clearly states it queries bilateral oil trade flows from specific sources (EIA, Eurostat) and explicitly distinguishes from chokepoint data by name.

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

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

Explicitly says when to use (bilateral oil trade) and when not to (use shipping_chokepoint for Hormuz transit volumes), and mentions it accepts structured filters or free-text query.

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

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

No annotations provided, so description carries full burden. It states cross-referencing data sources and verifiable IMO identity, but no mention of side effects, auth needs, or rate limits. Adequate but not explicit about read-only nature.

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

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

Two sentences, front-loaded with main action, no fluff. First sentence states core function, second adds filtering options. Efficient.

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

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

Covers purpose and filtering but omits output description. No output schema, so agent relies on description for return format. Missing detail on what results look like.

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

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

Schema coverage is 67% with 'limit' missing description. Description adds meaning to 'query' parameter (program, flag, vessel name) and restates 'year' purpose. Adds value beyond schema but 'limit' unaddressed.

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

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

Description explicitly states the tool finds sanctioned vessels that called at EU/EEA ports, cross-referencing OFAC sanctions with EU MRV emissions data. It clearly distinguishes from sibling tool 'shipping_sanctions' which is likely broader.

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

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

Description implies when to use (for EU port call sanctions) but does not explicitly state when not to use or mention alternatives. Clear context but lacks exclusions.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. It only states 'check' (a read operation) but does not describe what the check returns, any potential side effects, or required permissions, which is insufficient for safe invocation.

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

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

The description is extremely short (one sentence), which is concise, but at the cost of omitting critical information. It earns its place, but does not fully utilize the available space to add value.

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

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

Given the absence of an output schema and annotations, the description is incomplete. It does not explain return format, pagination, or limitations, making it insufficient for an agent to trust or use the tool effectively.

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

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

Schema coverage is 0%, yet the description adds no meaning to either parameter (type, query). It fails to explain what 'query' expects (e.g., vessel name, IMO number) or how 'type' filters results, leaving the agent to guess based solely on the schema enums.

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

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

The description 'Check vessel/entity against OFAC sanctions' clearly specifies the action (check) and the resource type (vessel/entity) against a specific sanctions list (OFAC), distinguishing it from the sibling 'shipping_sanctioned_at_eu' which targets EU sanctions.

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

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

The description offers no guidance on when to use this tool versus alternatives like 'shipping_sanctioned_at_eu'. There is no mention of prerequisites, use cases, or exclusions, leaving the agent without decision-making context.

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

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

With no annotations provided, the description carries the full burden. It discloses that the tool returns freshness information and status categories (ok/lagging/stale/empty), implying a read-only query. However, it does not mention performance characteristics, rate limits, or whether the tool might affect server state, though for a tool with zero parameters, the disclosure is adequate.

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

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

The description is two sentences: the first describes the output in detail, and the second gives a clear usage directive. Every word adds value, there is no repetition or fluff, and the most important information (what it returns and when to call it) is front-loaded.

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

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

Given zero parameters and no output schema, the description adequately covers what the tool returns (per-dataset freshness and status) and why to use it. It could be more explicit about the return structure (e.g., whether it returns a list or dict), but the mention of specific fields like 'how recently refreshed' and 'status categories' provides sufficient context for an agent to call and interpret results.

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

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

The tool has 0 parameters, and schema coverage is trivially 100%. The description doesn't need to explain parameters, and it does not attempt to describe non-existent ones. According to the rubric, zero parameters earns a baseline of 4, which is appropriate here.

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

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

The description clearly states it provides 'database statistics plus per-dataset freshness' and lists specific outputs (refresh recency, record age, status categories). It distinguishes itself from sibling tools by positioning itself as a diagnostic tool for assessing data trustworthiness, whereas siblings like shipping_fleet or shipping_oil_prices focus on specific data domains.

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

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

The description explicitly instructs the agent to 'Call this to decide how much to trust anything else this server returns,' providing a clear use case. It does not explicitly list when not to use it or name alternatives, but with 0 parameters and a distinct purpose, the guidance is sufficient.

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

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

No annotations are provided, so the description bears full responsibility. It hints at safe, read-only behavior ('ranking — no query needed') and parameter usage, but does not disclose sorting order, caching, rate limits, or what happens with invalid product keywords. Behavioral details are insufficient.

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

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

The description is two sentences and to the point, but lacks structure (e.g., not front-loading the most critical info). No unnecessary words, but it could be more efficiently organized.

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

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

Given no output schema, no annotations, and 0% schema description coverage, the description leaves many gaps: output format (ranking list with countries and values?), error handling, default behavior when neither query nor product is provided. It is insufficient for full autonomous use.

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

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

Schema coverage is 0%, so the description must compensate. It explains that `product` and `query` accept product keywords (crude/refined/lng/coal/iron_ore), but it is ambiguous whether they are alternatives or override each other. The `limit` parameter is not described at all. Added meaning is minimal.

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

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

The description states it returns 'Top oil exporting countries by value/volume (a ranking — no query needed)', which clearly identifies the verb (lists/returns) and resource (top oil exporters). It distinguishes from sibling tools by implying a quick, queryless ranking, but does not explicitly contrast with tools like shipping_oil_trade or shipping_country_flows.

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

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

The description mentions 'no query needed' and optional product/query parameters, implying it is for simple rankings. However, it provides no explicit guidance on when to use this tool versus alternatives (e.g., shipping_oil_trade for detailed trade), nor does it state prerequisites or exclusions.

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

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

No annotations are provided, so the description carries full burden for behavioral disclosure. It does not state whether the tool is read-only, what data it returns, or any side effects. The brief phrase reveals no behavioral traits beyond the basic function.

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

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

The description is extremely concise at four words, which is efficient. However, it lacks structure and may be too brief to provide sufficient context. It earns its place by being clear but could benefit from additional detail without becoming verbose.

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

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

With no output schema and no annotations, the description must provide complete context. It only states the basic function, omitting return format, data source, or how it differs from similar tools (e.g., shipping_fleet). The description is insufficient for an agent to fully understand the tool's behavior.

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

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

The tool has zero parameters, so the input schema is fully covered. Per guidelines, the baseline is 4. The description does not add parameter-specific meaning, but none is needed. No contradictions with schema exist.

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

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

The description 'Fleet breakdown by vessel type' clearly indicates the tool returns a breakdown of a fleet categorized by vessel type. It specifies the resource (fleet) and the dimension (vessel type), making the purpose apparent despite lacking a verb.

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

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

No guidance is provided on when to use this tool versus its siblings (e.g., shipping_fleet, shipping_country_flows). The description does not differentiate its purpose or recommend contexts for use, leaving the agent without decision support.

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