Signed global shipping & commodity data: oil, LNG, grain, sanctions, fleet, emissions.
Scored across 16 tools
Most tools are clearly distinct and several descriptions explicitly cross-reference siblings (e.g. oil_trade vs chokepoint, port vs port_calls vs port_coverage). The main soft spot is shipping_status vs shipping_freshness, which both claim per-dataset freshness, creating real overlap in purpose.
Every tool carries the same shipping_ prefix and uses snake_case noun/verb phrasing consistently. Names are predictable and readable throughout.
16 tools is slightly heavy but each maps to a distinct maritime data domain (chokepoints, trade, emissions, fleet, ports, sanctions, prices). The set is well-scoped for a multi-domain data server, with the status/freshness duplication being the only redundancy.
The surface covers a broad lifecycle: throughput, flows, prices, emissions, fleet, ports, sanctions, and exporters, plus freshness/coverage meta-tools. Minor gaps like per-vessel detail retrieval or update operations are not expected for a read-only data service, so coverage is strong.
Maritime chokepoint intelligence for Hormuz, Suez, Malacca, or Bab el-Mandeb. Returns authoritative EIA baseline throughput (barrels/day, % of global), a live AIS snapshot (vessels/tankers/moving/stationary) for the chokepoint, sanctioned vessels currently detected there, and dark-fleet behavioural signals (loitering + AIS gaps). This is the tool for "how is Hormuz doing".
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Alias for chokepoint (free text) | |
| chokepoint | No | "Hormuz", "Suez", "Malacca", or "Bab el-Mandeb" |
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.
Trade partners for a specific country (who they export to / import from). Pass the country as country or query.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | Alias for country | |
| country | No | ||
| direction | No | exports |
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.
Query the shipping document intelligence layer: eBL platform adoption (12 platforms), MLETR country adoption (23 countries, 13 enacted), document fraud cases ($11.3B), DCSA standards (10), industry stats (26 metrics). The state of shipping document digitization.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | Topic: "platforms", "mletr", "fraud", "standards", "stats", or "overview" |
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.
Query EU MRV vessel emissions data — CO2, fuel consumption, time at sea for 22,543 vessels (2018-2024). Search by IMO, ship type, or year — or a free-text query (7-digit = IMO, else ship type/name).
| Name | Required | Description | Default |
|---|---|---|---|
| imo | No | IMO number (7 digits) | |
| year | No | Reporting period year (2018-2024) | |
| limit | No | ||
| query | No | Free-text: IMO number or ship type/name | |
| ship_type | No | Ship type filter (e.g., "Oil tanker", "LNG carrier") |
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.
Query tanker fleet database. Accepts structured filters OR a free-text query (matches vessel name, IMO, owner, or type).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | Free-text: vessel name, IMO, owner company, or type | |
| search | No | ||
| company | No | ||
| vessel_type | No |
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.
Per-dataset freshness only: pipeline refresh age vs expected cadence, newest record age, source, and status (ok / lagging / stale / empty / unknown). Use before relying on a figure that must be current.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
Get oil price benchmarks (WTI, Brent)
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| benchmark | No | all |
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.
Query bilateral oil trade flows (EIA US imports/exports + Eurostat). Accepts structured filters OR a free-text query (matches country/notes). NOTE: this is import/export flow data, NOT chokepoint throughput — for Hormuz transit volumes use shipping_chokepoint.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | Free-text: a country name or keyword | |
| period | No | ||
| partner | No | ||
| product | No | ||
| reporter | No |
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.
What this service holds about ONE port, and how good the evidence is. Returns NGA World Port Index identity (UN/LOCODE, coordinates, harbour class, channel/anchorage/pier depths), the evidence grade for our movement data (origin = the authority publishes its own board / custody = a third party publishes it / measured = AIS inference only, asserted by nobody / none), what we do NOT hold, and what happened the last time we fetched the port's own website. Pass a port name, UN/LOCODE, or WPI port number as query.
| Name | Required | Description | Default |
|---|---|---|---|
| port | No | Alias for query | |
| query | No | Port name, UN/LOCODE (e.g. NZTRG), or WPI port number | |
| unlocode | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does unusually well: it decodes the evidence-grade vocabulary (origin/custody/measured/none), warns that some data is explicitly not held, and reports the outcome of the last fetch of the port's own website. Remaining gaps are failure behavior — what happens when the query matches nothing or matches multiple ports — and confirmation that this is a read-only lookup.
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?
Purpose is front-loaded in the first clause and every subsequent clause adds substantive content about returns rather than filler. It is dense — compressed into essentially one long sentence with many parenthetical clauses — which costs some scannability but wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a lookup tool with no annotations and no output schema, the description adequately characterizes the return payload, including provenance and negative-space information an agent would otherwise have to discover by calling. It falls short only on the multi-parameter input model and on not-found/ambiguity 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?
Schema coverage is 67%; the description restates that `query` accepts a name, UN/LOCODE, or WPI number, which the schema already says. It says nothing about the undocumented `unlocode` parameter or how the `port` alias relates to `query`, leaving a genuine ambiguity (which field wins if both are supplied).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource (one port) and enumerates what is returned: WPI identity fields, evidence grade, coverage gaps, last website fetch. An agent can tell this is a per-port detail/lookup tool. It does not, however, distinguish itself from siblings like shipping_port_calls or shipping_port_coverage, which sound adjacent.
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 closest thing to guidance is the invocation instruction to pass a port name, UN/LOCODE, or WPI number as `query`. There is no explicit when-to-use, no named alternative for movement data (port_calls) or coverage gaps (port_coverage), and no exclusions. Usage is only implied by the enumeration of returned content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Berth-level vessel movements harvested from port authority movement boards: vessel, IMO, arrival/departure, berth, agent, declared last/next port. Each row carries its source and whether the channel was TLS-verified. This is TESTIMONY from the port, distinct from the AIS-inferred port_visits behind other tools. Pass a port name or an IMO as query.
| Name | Required | Description | Default |
|---|---|---|---|
| imo | No | ||
| port | No | ||
| limit | No | ||
| query | No | Port name or 7-digit IMO |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does real work: it discloses data provenance (port authority movement boards), per-row source attribution, TLS verification status, and the evidentiary nature of the data vs inference. It omits pagination/limit behavior, rate limits, and freshness caveats, which keeps it from a 5.
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 tight sentences, front-loaded with the resource and field list, then differentiation, then the call instruction. No filler, though the final sentence duplicates information the schema already carries for `query`.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description compensates by enumerating the returned row fields and provenance columns, plus disambiguating the data source. Missing pieces are the `limit`/pagination contract and how `imo`/`port` differ from `query`.
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 only 25%, and the description only addresses `query` (port name or 7-digit IMO). It leaves the separate `imo` and `port` properties undefined and their relationship to `query` ambiguous, and says nothing about `limit` — a real gap given how low coverage is.
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?
Opens with a specific verb+resource ("Berth-level vessel movements harvested from port authority movement boards") and enumerates the fields returned. It explicitly distinguishes itself from the AIS-inferred port_visits behind sibling tools, so an agent can route between them without opening a schema.
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?
States the lookup key ("Pass a port name or an IMO as `query`") and implicitly frames when to prefer this over AIS-inferred tools by calling the data "TESTIMONY from the port." It never names the concrete sibling alternatives (shipping_port, shipping_port_coverage) or states exclusions, so not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Coverage ledger across all 2,951 ports: how many we hold at each evidence grade, how many publish a machine-readable movement board, and what happened when we checked those that do not. Call this to find out what this service does NOT know about ports before relying on what it does.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Alias for country | |
| country | No | Optional ISO-2 or country name filter |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses that the tool reports evidence grades, board availability, and the result of checking ports without boards — which implies this is an aggregate audit rather than a data-returning query. However, it does not say whether the operation is read-only, whether a country filter narrows aggregates or returns rows, or how large the response is.
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, no filler, with the resource scope front-loaded and the usage instruction second. The phrase "what happened when we checked those that do not" is slightly oblique but still earns its place by describing the probe-outcome dimension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no annotations, so the description must convey what comes back — and it does so in terms of the three coverage dimensions. The remaining gap is the interaction between the optional country filter and the reported aggregates, which an agent would need to know before calling.
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 description coverage is 100% and both parameters are optional, so the schema already documents `query` as an alias for `country` and the ISO-2/name filter. The description adds nothing about parameters at all — notably it never clarifies that filtering by country changes the scope of the ledger. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource (a coverage ledger over 2,951 ports) and enumerates its contents: counts by evidence grade, counts of machine-readable movement boards, and probe outcomes for the rest. That is concrete enough to distinguish it from per-port siblings like shipping_port or shipping_port_calls, though it never names an alternative explicitly.
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?
"Call this to find out what this service does NOT know about ports before relying on what it does" gives a clear triggering condition: assess coverage gaps prior to trusting port data. It lacks an explicit when-not or a named alternative (e.g. shipping_freshness, shipping_status), so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find sanctioned vessels that called at EU/EEA ports. Cross-references OFAC sanctions with EU MRV emissions data (verifiable IMO-level identity). Filter by year or a free-text query (sanctions program e.g. "Iran"/"Russia", flag, or vessel name).
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Filter by year (2018-2024) | |
| limit | No | ||
| query | No | Program (e.g. "Iran"), flag state, or vessel name |
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.
Check vessel/entity against OFAC sanctions
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | ||
| query | Yes |
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.
Database statistics plus per-dataset freshness: how recently each dataset was refreshed by our pipeline, how old its newest record is, and whether it is ok / lagging / stale / empty. Call this to decide how much to trust anything else this server returns.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
Top oil exporting countries by value/volume (a ranking — no query needed). Optional product or query recognizes a product keyword (crude/refined/lng/coal/iron_ore).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | ||
| product | No | crude |
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.
Fleet breakdown by vessel type
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
shipping_portshipping_port_callsshipping_port_coverageshipping_freshnessshipping_chokepointshipping_country_flowsshipping_doc_intelshipping_emissionsshipping_fleetshipping_oil_pricesshipping_oil_tradeshipping_sanctioned_at_eushipping_sanctionsshipping_statusshipping_top_exportersshipping_vessel_typesMaritime intelligence: vessels, tracks, port calls, company fleets and sanctions screening, sourced.
Pay-per-call shipping evidence: canal queues, tanker flows, container and carbon exceptions.
Signed BTC and macro market intelligence for autonomous research, risk, and trading agents.
Live AIS ship positions, vessel history, port calls and events, plus sanctions flags. Read-only.
Add one secure layer between your agents and this server.
