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 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 full burden but offers minimal disclosure. It does not state if the tool is read-only, has side effects, or requires special permissions.

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

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

Single sentence is concise and front-loaded, but it is underspecified rather than appropriately succinct. It fails to convey essential information.

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

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

Given no parameters and no output schema, the description should fully explain the tool's purpose and output. 'Database statistics and data freshness' is insufficient to understand what data is provided or how to interpret it.

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

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

The tool has zero parameters and schema coverage is 100%, so baseline is 4. However, the description adds minimal meaning ('database statistics and data freshness'), not fully clarifying what the no-parameter tool returns.

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 is vague: 'Database statistics and data freshness' does not specify what action the tool performs or what resource it acts on. It lacks a verb and clear object, making it difficult for an agent to understand its purpose compared to 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?

No guidance on when to use this tool versus alternatives. The description does not mention context, prerequisites, or exclusions, leaving the agent to guess.

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.