Datalastic Vessel Tracking & Maritime Intelligence

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

No annotations, but description discloses it's an estimate, explains calculation method, and warns when extrapolation fails. Full transparency on behavioral traits.

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?

Well-structured with purpose first, then usage, then behavioral notes. Dense with useful info but slightly lengthy.

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?

Output schema exists, so return values not needed. Covers use case, alternatives, error cases, and user presentation. Very complete.

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 clear descriptions of each parameter. Description does not add new parameter info but baseline is appropriate for high coverage.

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 estimates a vessel's current position when last AIS is stale, distinguishing it from siblings like get_vessel (live position) and get_vessel_pro (ETA/destination).

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 advises to use this LAST after get_vessel and get_vessel_pro, only when both conditions hold, and suggests offering to user first. Also provides guidance on interpreting the result.

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 discloses that the tool always returns a list, even for a single match, and lists return fields. However, it does not explicitly state that the tool is read-only or safe, which is a minor gap. Overall, good transparency for a search tool.

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

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

Three sentences, each packed with information: first states function and output, second lists search options, third clarifies always-returns-list and distinguishes sibling. No redundant words, front-loaded with key details.

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 9 parameters, 0 required, and an output schema, the description covers main use cases, search capabilities, and return behavior. It provides a fallback to get_port. Lacks mention of pagination or maximum results, but schema covers radius limit. Very good completeness for agent to understand tool scope.

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%, so baseline is 3. The description provides a higher-level summary of search methods but does not significantly add meaning beyond the schema. The always-returns-list behavior is context, not parameter-specific. Score remains at baseline.

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 searches the port registry and returns matching ports with specific fields. It distinguishes from the sibling tool get_port by noting that get_port is for full detail on a known port.

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

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

Explicitly states when to use: to discover ports or resolve a name to UN/LOCODE/uuid. Also specifies when not to use: for full detail on one known port, use get_port. Provides clear context for agent decision-making.

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 fully bears the burden. It discloses that the tool returns static specification records (reference data, not live position), pagination limits, and credits per vessel. It lacks explicit mention of read-only nature, but it is implied by the 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 about 4 sentences, front-loaded with the main purpose, and concisely covers key details. Every sentence adds value, with no wasted words.

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

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

Given the tool's complexity (17 parameters) and the presence of an output schema, the description is complete. It covers the type of data returned, pagination, credits, and usage prerequisites. An output schema exists, so return values are handled there.

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%, so baseline is 3. The description adds context like 'no MMSI or IMO needed' and 'at least one search criterion', but the schema already documents each parameter. The added value is marginal but sufficient.

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

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

The description clearly states the tool's purpose: searching the vessel registry by multiple criteria. It specifies the verb 'search' and the resource 'vessel registry', and distinguishes from siblings like get_vessel (live position) and get_vessels_in_radius (area search).

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 when to use this tool (for reference data), when not to use it (for live positions or area vessels), and provides alternatives like get_vessel and get_vessels_in_radius. It also gives requirements like needing at least one search criterion and pagination guidance using 'next' token.

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 describes the operation as returning detailed info, implying read-only, and lists output fields. It does not explicitly declare idempotency or absence of side effects, but for a get operation this is sufficient. A 4 reflects good transparency without being exhaustive.

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 the return value list, followed by lookup method and alternative. No wasted words; every sentence earns its place. Very concise and well-structured.

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

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

For a simple get tool with full schema coverage and an output schema, the description adequately covers what is returned, how to query, and when to use an alternative. No additional context (error handling, auth) is necessary for this straightforward operation.

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 already has descriptions for both parameters with 100% coverage, including the mutual exclusivity hint. The description restates this ('exactly one') but adds no new semantic value beyond what the schema provides. Hence a baseline 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 returns detailed information for a single port, listing specific fields (identity, country, UN/LOCODE, etc.). It explicitly distinguishes from find_ports, which is for search by name or location, leaving no ambiguity about this tool's purpose.

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 exactly when to use this tool (when you have a Datalastic uuid or UN/LOCODE) and when not to (for name/location search, use find_ports). This provides clear context against siblings and gives an alternative.

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 carries full burden. It discloses what data is returned (coordinates, speed, etc.) and the identification requirement. Lacks discussion of error handling or rate limits, but for a simple read tool this is acceptable.

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

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

Two sentences, no excess. Key purpose and usage immediately front-loaded. Every sentence adds distinct 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 an output schema exists, the description adequately covers return fields, identification method, and differentiation from sibling tools. No gaps for a tool of this complexity.

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

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

Schema coverage is 100%, so baseline is 3. Description repeats schema info (e.g., 'exactly 7 digits') and adds no novel semantic value beyond what the schema already provides.

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

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

The description clearly states the verb 'return', the resource 'current position and basic information for a single vessel', and lists specific fields. It distinguishes from sibling tool get_vessel_pro by contrasting the data provided.

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

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

Explicitly states 'This is the default tool for vessel lookups' and provides clear guidance on when to use get_vessel_pro instead. Also specifies the identification constraint: exactly one of MMSI, IMO, or UUID.

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

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

With no annotations provided, the description fully carries the burden of behavioral transparency. It discloses data availability since 2021-08-10, that only position changes are stored (stationary gaps possible), and the constraint that 'to' must be within 30 days of 'from'. This provides essential behavioral context beyond the schema.

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, efficiently front-loaded with the purpose, then details. Every sentence adds value without redundancy. It is well-structured and easy to parse.

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 complexity of the tool (multiple identification methods, time range options, data constraints) and the presence of an output schema, the description is complete. It covers all essential aspects: identification, time range specification, data availability, and behavioral notes on gaps. No gaps in context.

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%, but the description adds significant meaning by explaining the mutual exclusivity of identifiers (exactly one of mmsi, imo, uuid), the relationship between days and from/to (mutually exclusive), and the data availability date. This goes beyond the schema descriptions, providing critical usage logic.

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 'Return the historical track (ordered position records) for a single vessel', specifying a specific verb and resource. It distinguishes from sibling tools by detailing unique identification methods (MMSI, IMO, UUID) and time range options (days or from/to), making it clear that this tool is for historical track retrieval.

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 context for when to use the tool (historical track of a single vessel) and outlines specific constraints (exactly one identifier, use either days or from/to, not both, max 30-day range). While it does not explicitly state when not to use it versus siblings, the context is clear and helpful for correct invocation.

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 discloses that the tool returns static reference data, not live positions, and lists the types of fields returned. It does not describe error behavior for missing identifiers or multiple identifiers, but given the read-only nature, this is mostly sufficient.

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

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

Three sentences: first states purpose and identification requirement, second lists returned fields, third clarifies not live position. No redundant information, well front-loaded, every sentence earned.

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

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

Given the tool's simplicity (3 params, output schema present), the description explains how to identify the vessel, what data is returned, and how it differs from siblings. No gaps remain for an agent to misuse this 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 100% with descriptions for each parameter. The description adds value by clarifying mutual exclusivity ('exactly one of') and providing digit count examples, which aids correct invocation beyond schema basics.

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

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

The description clearly states the tool returns static specifications for a single vessel, using verb 'Return' and resource 'static specifications'. It explicitly distinguishes from siblings by mentioning get_vessel for live position and find_vessels for registry search.

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 when-not guidance: 'This is reference data, NOT live position — use get_vessel for the current position, or find_vessels to search the registry by attributes.' It also states the identification requirement: 'identified by exactly one of: MMSI, IMO, or Datalastic UUID.'

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 notes the tool is 'heavier on the backend' and mentions staleness condition. Could explicitly state read-only nature, but overall discloses behavioral traits well.

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 efficiently written sentences, front-loading purpose, then guidelines, then a behavioral note. 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 complexity (multiple identifiers, enriched output, sibling tools), the description fully covers use case, return fields, and when to consider alternatives. Output schema exists but description explains return values sufficiently.

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 100% with descriptions for each parameter. Description reinforces mutual exclusivity and format constraints (9-digit MMSI, 7-digit IMO, UUID). Adds value by explaining the identification requirement beyond schema.

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

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

Clearly states the tool is a richer variant of get_vessel for a single vessel, enumerating the additional fields (destination port, origin port, ATD, ETA, draught). Distinguishes from sibling get_vessel by specifying the enriched data.

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 recommends get_vessel for ordinary lookups and get_vessel_pro only when specific enriched fields are needed. Also suggests estimated_vessel_position for stale positions, providing clear when-to-use and when-not-to-use guidance.

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

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

No annotations provided. Description mentions only found vessels are returned and includes count, but lacks details on limit enforcement, error handling, or data freshness. 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?

Two sentences, no redundant words, front-loaded with core purpose. Highly 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?

Given output schema exists and schema covers params, description provides sufficient context. References comparable fields to get_vessel and clarifies result structure.

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

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

Schema has 100% coverage with descriptions. Description adds the ability to mix identifier types and notes the 100 total limit, adding value beyond schema.

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

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

Clearly states it returns current position and basic info for many vessels by supplying MMSI, IMO, UUID lists. Distinguishes from get_vessel by specifying bulk vs single.

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 use this instead of many get_vessel calls for a known set, and for a single vessel use get_vessel. Provides clear when-to-use guidance.

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

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

With no annotations provided, the description carries the full burden. It discloses key behaviors: charges credits per vessel found, returns up to 500 per page, pagination via 'next' token, and enforces exclusive center specification. It lacks details on rate limits or authentication, but for a read-only scan, it is sufficient.

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

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

The description is very concise while covering all essential aspects. It uses front-loaded sentences and a clear structure, with no wasted words. Every sentence adds necessary 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 the 14 parameters, 100% schema coverage, and existence of an output schema, the description is complete. It covers the core operation, center specification options, filters, pagination, and cost implications, leaving no major gaps.

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%, so baseline is 3. The description adds meaningful context beyond the schema: explains scan concept, center exclusivity, pagination output structure, and credit charging. It helps agents understand parameter purpose beyond type/constraint.

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

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

The description clearly states the tool's purpose: scan a circular area and return all vessels within a given radius. It uses specific verbs (scan, return) and resource (vessels), distinguishing it from siblings like get_vessel (single vessel) or find_vessels (search 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?

The description provides explicit instructions on when to use the tool (area scan) and how to specify the center (lat+lon, port, or vessel). It also explains optional filters and pagination. However, it does not explicitly mention when not to use it or compare to alternatives, though the context is clear.

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

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

No annotations are provided, so the description bears full responsibility. It lists return fields and the units object but omits any behavioral details like error handling, rate limits, or prerequisites. It does not contradict annotations (none exist).

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

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

The description is three sentences: first sentence states purpose and scope, second covers location input, third covers mode and units. Every sentence adds essential information; 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 8 parameters, 100% schema coverage, and presence of output schema, the description fully explains what weather data is available, how to specify location (with multiple options), and how to request different modes. It is comprehensive for an agent to use 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 100%, so baseline is 3. The description adds context: location must be exactly one of coordinates, vessel, or port; explains mode combinations; and mentions units objects. This provides meaning beyond parameter descriptions.

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 returns weather for one location, listing marine and atmospheric conditions. It differentiates from sibling tools by focusing on weather data, while siblings like find_ports or get_vessel serve different purposes.

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 specifies location input options (coordinates, vessel, port) and mode (current, forecast). It is clear when to use, though it does not explicitly exclude scenarios where alternatives like sea_route might be better.

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 burden. It clearly states it retrieves incidents with date, category, and narrative, and mentions it is part of an add-on, implying subscription requirements. No contradictions or hidden effects.

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

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

The description is three sentences, front-loaded with the main action and examples, 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?

With an output schema present, the description doesn't need to detail return values beyond mentioning date, category, narrative. It covers usage and hints at access control, though could mention error handling for missing vessels.

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%, so baseline is 3. The description adds context by noting that imo and name are alternative identifiers and from/to bound the period, adding marginal value beyond the schema descriptions.

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

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

The description clearly states the verb 'Retrieve', the resource 'vessel's recorded maritime incidents', and provides specific examples like groundings, collisions, fires. It distinguishes itself from sibling tools like intel_inspections by focusing on casualties and incidents.

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

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

The description states 'Useful for risk and condition assessment' and explains how to identify the vessel, but does not explicitly mention when not to use this tool or provide comparisons to alternative sibling tools like intel_inspections or intel_engine.

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 implies a read operation but does not explicitly state it is read-only, mention authentication needs, rate limits, or any side effects. The 'Part of the Maritime Reports add-on' hint about prerequisites could be clearer.

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 states what the tool returns, the second explains identification methods and add-on context. It is front-loaded, concise, and every sentence adds value.

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

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

Given the 8 parameters and existence of an output schema, the description covers the main purpose and parameter usage. It lists the returned data fields, which is helpful. It lacks details about behavior on multiple matches or error scenarios, but with output schema present, it is still fairly complete.

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%, so baseline is 3. The description adds meaning by explaining the 'fuzzy' parameter for loose name matching and grouping usage into identification vs. filtering. It omits the 'updated_from' date parameter but overall compensates well.

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 returns a vessel's classification society and principal technical particulars, listing specific items like tonnage, dimensions, propulsion, etc. It distinguishes itself from sibling tools like intel_info or intel_ownership by focusing on classification and technical details.

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 how to identify a vessel (by imo, name, or fuzzy matching) and how to filter by owner/manager. However, it does not explicitly state when to use this tool versus alternatives like intel_info, nor does it provide when-not scenarios.

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

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

No annotations provided. Description implies read-only lookup and describes returned fields, but does not explicitly state no side effects or authentication requirements. Still, behavioral context is sufficient for a directory tool.

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

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

Two concise sentences with no redundancy. Information is front-loaded and every sentence adds value.

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

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

With output schema present, description sufficiently covers purpose, usage, parameters, and distinctions from siblings. No missing details for effective tool selection and invocation.

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

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

Schema coverage 100%, baseline 3. Description adds value by explaining company_imo is not a vessel IMO and must be exactly 7 digits, and clarifies updated_from filters by update date, going beyond schema descriptions.

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?

Clear verb 'look up' and resource 'maritime company profile'. Explicitly distinguishes from sibling intel_ownership by stating it searches by company IMO or name, while intel_ownership finds companies behind a ship.

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 search methods (IMO or name) and includes a clear when-not statement: 'to find the companies behind a specific ship use intel_ownership', offering an alternative tool.

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. It discloses that the tool is 'Part of the Maritime Reports add-on,' implying a subscription requirement. It lists the types of data returned (dry-dock dates, survey dates, IOPP dates, contact details) and explains the scanning feature. It does not elaborate on error handling, rate limits, or data freshness, but covers the core behavioral aspects adequately for 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?

The description consists of two succinct sentences plus a one-phrase add-on note. It is front-loaded with the primary purpose and efficiently covers both single-vessel and fleet-scan modes. No redundant or vague language; every sentence serves a distinct purpose.

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 that an output schema exists (so return values are defined there), the description sufficiently covers usage context: the two query modes, the types of data returned, and the add-on dependency. It does not discuss pagination or ordering, but these are often implicit in JSON array outputs. The description is complete enough for an agent to understand when and how to invoke the tool correctly.

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

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

The schema already describes all four parameters (100% coverage). The description adds meaning by explaining the alternative usage of imo vs name for single-vessel lookup, and how dry_dock_from/dry_dock_to define a date range for fleet scans. This clarifies parameter relationships and intended use beyond the schema's individual descriptions.

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 'looks up planned and past dry-dock dates, special-survey dates, and IOPP certificate dates for a vessel, along with its technical manager's contact details.' It specifies distinct use cases: single vessel by IMO/name or fleet scan by date range. The unique subject (drydock/survey) distinguishes it from sibling intel_* tools that cover casualties, class, companies, 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 outlines two usage modes: target a single vessel by imo or name, or scan a forward window across the fleet using dry_dock_from/dry_dock_to. This gives clear guidance on when to use each set of parameters. However, it does not state when not to use this tool or mention alternatives among sibling tools for similar purposes.

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

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

No annotations are provided, so the description must carry the full burden. It discloses the return fields and the add-on context but does not mention potential failure modes, authentication requirements, or rate limits. For a read-only lookup tool, this is minimally acceptable.

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

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

The description is exceptionally concise with two sentences. The first sentence front-loads the core function and outputs, and the second covers identification and the add-on. Every word adds value with no wasted text.

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 that an output schema exists, the description need not detail return values. The tool has four parameters all fully described in the schema. The description could be more complete by differentiating from sibling tools, but it adequately covers the essential context for an engine-specific lookup 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 description coverage is 100%, so the schema already documents each parameter. The description adds context about using fuzzy for loose matching but does not elaborate on the 'updated_from' parameter or provide additional detail beyond the schema. Baseline score of 3 is appropriate.

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

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

The description clearly states the tool returns main-engine specifications including specific fields like engine designation, builder, propulsion type, and MCO. It distinguishes itself from sibling tools like intel_class or intel_info by focusing on engine specs.

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 how to identify vessels by IMO or name, and mentions fuzzy matching for loose name matching. However, it does not explicitly advise when not to use this tool or list alternatives among siblings, leaving some ambiguity.

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

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

No annotations are provided, so the description must carry the full burden. It describes the tool as a status check and lists offerings, implying it is read-only and non-destructive. However, it does not explicitly state side effects or authorization needs, but for a simple query tool this is adequate.

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

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

The description is informative and front-loaded with the core purpose, but it lists many offerings in a long sentence. While not overly verbose, it could be slightly more concise. Still effective.

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

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

Given the tool has no parameters, and there is an output schema, the description covers purpose and usage completely. It answers what the tool does and when to use it, leaving no gaps.

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

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

The tool has zero parameters, and the schema coverage is 100%. The description does not need to add parameter details; the baseline score of 4 is appropriate.

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

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

The description clearly states the tool checks whether the Maritime Reports add-on is active and lists what it offers. It distinguishes from sibling intel_* tools by specifying when to use it (e.g., when another tool reports the add-on is missing).

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 provides three scenarios for use: when the user asks about the add-on, when an intel_* tool reports it missing, or after a subscription update. This is clear guidance.

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

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

With no annotations, the description carries the full burden. It clearly indicates a read operation ('Retrieve') and lists the data returned. No mention of side effects, auth, or rate limits, but the read-only nature is implied. The description is transparent enough 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 concise (three sentences), front-loaded with the main purpose, and every sentence adds value. No redundant or extraneous 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 the moderate complexity (4 params, output schema present), the description covers the purpose, key parameters, and return fields adequately. The existence of an output schema reduces the need to detail return structure. Could mention prerequisites, but not essential.

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%, so the schema already documents each parameter. The description restates that 'imo' and 'name' identify the vessel, and 'from'/'to' bound the period, but adds minimal new meaning. Baseline 3 is appropriate.

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

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

The description specifies the exact resource ('vessel's Port State Control inspection record'), the action ('Retrieve'), and the key data fields (authority, port, type, date, detention, deficiencies). It clearly distinguishes from sibling tools that cover different maritime data (e.g., casualties, class, engine).

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

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

The description provides clear context on when to use the tool (to get PSC inspections) and how to specify the vessel (by imo or name) with optional date bounds. While it doesn't explicitly list alternatives or when not to use, the sibling tool names imply distinct purposes, making the usage sufficiently clear.

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 discloses the tool returns ownership details and can list vessels, implying read-only behavior. However, it omits details on rate limits, authorization requirements, or behavior when no results are found.

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-loading the main purpose and covering key functionality without unnecessary words. Every sentence earns its place.

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

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

Given the presence of an output schema, return values are covered. The description covers primary functionality and parameters. Lacks mention of pagination or limits when listing vessels by company, but overall complete for the tool's purpose.

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%, so baseline is 3. The description adds context by explaining the reverse lookup capability, but does not significantly extend meaning beyond the schema descriptions.

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 reveals the commercial control behind a vessel, listing specific entities (beneficial owner, operator, manager, P&I club, flag). It distinguishes itself by offering both vessel lookup and reverse company lookup, differentiating from sibling tools like intel_companies.

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 provides two usage modes: lookup by vessel (IMO or name) or by company name to list vessels. It implies context by stating 'Part of the Maritime Reports add-on,' but lacks explicit when-not-to-use guidance or 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 fully bears the burden. It discloses async nature, returns _PENDING_ status, polling requirement, and that the server never downloads the file. It could further mention typical completion time or report_id format, but is already strong.

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 plus a brief note, front-loading the action and result. Every sentence adds value with no redundancy. Clear 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 output schema exists, the description effectively covers return values (report_id, status, polling, result_url). It also explains the async flow and dataset scope. No gaps remain for agent understanding.

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

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

The sole parameter 'report_type' is fully described in the schema (100% coverage). The description adds meaning by explaining that selecting a type returns the entire dataset for that report, contrasting with single-vessel tools. This goes beyond the schema's enum listing.

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 submits an async job to export a full bulk dataset for Maritime Reports add-on datasets. It distinguishes from sibling tools for single vessel lookups (e.g., intel_ownership, intel_inspections).

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 guides when to use this tool (for bulk dataset) vs. alternatives (single vessel lookup tools). Provides step-by-step async workflow: submit once, poll report_status, hand result_url to user. Notes it is part of the Maritime Reports add-on.

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

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

With no annotations, the description must carry the full burden of behavioral disclosure. It explains that the tool retrieves data (read-only) and lists the types of transactions and data fields. However, it does not mention any side effects, authentication requirements, rate limits, or data freshness, which would enhance transparency.

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

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

The description is a single paragraph of three sentences, each carrying useful information. It is front-loaded with the core purpose, followed by use case and parameter guidance, with no unnecessary 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 that an output schema exists, the description does not need to detail return values. It covers the main parameters, use case, and the add-on context. However, it could mention that the tool returns a list of transactions and any pagination or result limits for full completeness.

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 100% coverage, with clear descriptions for all four parameters. The description reiterates that the vessel can be identified by IMO or name and that from/to can bound the period, but it adds minimal extra meaning beyond the schema definitions.

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 ship sale-and-purchase transactions, including specific types (second-hand, newbuilding, demolition) and data fields (seller, buyer, price, etc.). It distinguishes itself from sibling intel tools that focus on casualties, class, companies, etc., by focusing on commercial transactions.

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 notes the tool is useful for 'asset valuation and market tracking,' providing context for when to use it. It also explains that the vessel can be identified by IMO or name with optional date bounds. However, it does not explicitly compare with sibling tools or indicate when not to use this tool.

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 the output includes statuses and result_url, but does not disclose whether the operation is read-only, any rate limits, or what 'recent' means. This is adequate for a simple list tool but lacks some 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?

Two sentences, no wasted words, action is front-loaded. Efficient and clear.

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 an output schema exists, the description provides sufficient high-level context. It mentions statuses and result_url, but does not define 'recent' or explain pagination. However, for a list tool with output schema, this is largely complete.

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

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

There are no parameters, so the baseline is 4. The description does not need to add parameter details, and the schema coverage is 100% implicitly.

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 lists the caller's recent async report jobs with statuses and result_url. The verb 'list' and resource 'async report jobs' are specific, and the tool is distinguished from siblings like report_request (which submits) and report_status (which might check specific ones).

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 says to use this to recover a report_id or check finished reports, with a concrete example. However, it does not contrast with sibling tool report_status or mention when not to use this tool, which slightly limits guidance.

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

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

No annotations provided, so the description carries full burden. It fully discloses async nature, return value, polling requirement, credit consumption for some types, and that the server never downloads files. Detailed behavioral context is given.

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

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

The description is well-structured and concise. It front-loads the main purpose and flow, then lists report types in a clear bullet-like format. Every sentence adds value, with no wasted words.

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

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

Given the tool's complexity (async, multiple report types with different parameters), the description covers all necessary aspects: submission, polling, resubmission prohibition, credit consumption, and sibling tool differentiation. The presence of an output schema further supports completeness.

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%, but the description adds significant value by explaining supported report_type values and their specific parameter requirements (e.g., optional for request_usage, required for inradius_history) and constraints like radius max 50 NM and date ranges. This goes beyond the schema's parameter descriptions.

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 submits an async report job, returns a report_id and initial status, and explains the async flow. It distinguishes from sibling tools like intel_report_request for add-on datasets and report_status for polling.

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 instructs to submit once, then poll until done, and not to resubmit while running. Advises informing the user about credit consumption before submitting certain report types. Also directs users to intel_report_request for add-on datasets.

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, description fully discloses behavior: returns status values, result_url on DONE, time-limited links, server never downloads file. No contradiction.

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?

Five sentences, front-loaded with purpose, no unnecessary words. Each sentence adds 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 output schema exists and simple polling pattern, description covers all needed behavioral context: status meanings, URL handling, expiration. No gaps.

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 already covers parameter with full description. Description adds value by context hint 'from report_request or report_list', but schema already says it's the report_id.

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 checks an async report job by report_id, with specific resource and action. Distinguishes from siblings report_request (submit) and report_list (list reports) by context.

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 tells when to use: after report_request or report_list. Provides guidance for each status: wait for PENDING/IN_PROGRESS, hand URL to user when DONE, re-run if link expired.

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?

Without annotations, the description carries full burden and warns about schematic nature, hazards, and limitations. Lacks details on authentication or rate limits, but provides honest caution.

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?

Concise multi-sentence description with front-loaded main action, clear warning, and use cases, no redundancy.

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

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

Covers key aspects: purpose, inputs, limitations, use cases. Minor gap: doesn't clarify behavior when multiple input options are provided (e.g., both coordinates and port UUID). Output schema exists to detail return values.

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 clear parameter descriptions. The description adds grouping of input methods but doesn't resolve potential conflicts (e.g., multiple input types for same endpoint). Baseline 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 calculates a schematic sea route, returns GeoJSON LineString with distance, and distinguishes from sibling maritime tools by emphasizing it is not for real-world sailing.

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

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

Explicitly states when to use (estimating distance/time, visualization) and when not to use (not for navigation), and describes three input methods, providing clear guidance.

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