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

With no annotations, the description carries full burden. It explains the computation, filtering, aggregation, and output statistics (mean, median, std, CI). It does not explicitly state read-only behavior or prerequisites, but for an aggregation tool, transparency is good.

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 with a summary, parameter list, returns, and tips. Though lengthy, every sentence adds value given the number of parameters and zero schema coverage. It is front-loaded 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 17 parameters, no output schema, and no annotations, the description is very complete. It explains all parameters, the output format, and provides usage tips. It also references sibling tools for further analysis, covering the tool's capabilities fully.

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 lists all 17 parameters with explanations, allowed values, defaults, and constraints (e.g., group_by options, Beaufort range 0-12). This adds significant meaning beyond the 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?

The description clearly states it aggregates daily sailing speeds across CLIWOC tracks, computing haversine-based daily speeds and grouping by dimension. It mentions returns descriptive statistics per group, distinguishing it from siblings like maritime_compute_track_speeds or maritime_aggregate_track_tortuosity.

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?

It provides explicit tips for when to use specific parameters (e.g., lat_min/lat_max for Roaring Forties) and directs to sibling tools for significance testing and interaction effects, clearly guiding the agent on alternatives and context.

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

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

No annotations provided, so description must disclose behavior. It explains aggregation, hypothesis, and parameter effects. However, it does not explicitly state that it is a read-only operation, though it is implied by the analysis nature. Adequately transparent.

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-organized with sections (main description, Args, Returns, Tips). It is somewhat long but each sentence adds value. Minor redundancy could be trimmed (e.g., repeating period format in Args and Tips).

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 20 parameters and no output schema, the description covers purpose, parameters, and tips comprehensively. It lacks detailed return format beyond 'JSON or text', but the hypothesis context compensates. Mostly 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 0%, so the description fully explains each parameter, including defaults, constraints, and examples. The 'Args' section adds meaning beyond the schema, covering all 20 parameters.

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 that the tool aggregates route tortuosity across CLIWOC tracks to test the chronometer hypothesis. It distinguishes itself from sibling tools like 'maritime_track_tortuosity' (singular track) and 'maritime_did_speed_test' (speed decomposition) by specifying the aggregate and comparison functionality.

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 explains when to use: for testing chronometer hypothesis, comparing periods. Provides usage guidelines and tips, including combining with other tools like maritime_did_speed_test. Implicitly advises against using for individual track analysis.

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 adequately describes the outputs (quality score, uncertainty radius, recommendations) and mentions navigation era lookup. However, it does not clarify behavior with conflicting inputs (e.g., both voyage_id and lat/lon) or error handling, leaving some ambiguity.

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?

Description is well-structured with a one-line summary, explanatory paragraph, Args section, Returns, and Tips. It is front-loaded with purpose. While slightly verbose, it remains organized and easy to scan.

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 annotations or output schema, the description covers key aspects: inputs, outputs, navigation era details, and actionable tips. It misses some edge cases (e.g., param precedence) but is largely complete for practical 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?

All seven parameters are explained in detail despite 0% schema description coverage. Description includes units (decimal degrees), format (YYYY-MM-DD), default (output_mode), and tips for source_description keywords. This adds significant meaning beyond the raw 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?

The description clearly states it assesses the quality and uncertainty of a historical position, specifying inputs like voyage_id, wreck_id, or coordinates, and outputs like quality score and uncertainty radius. It distinguishes from siblings like maritime_estimate_position by focusing on assessment rather than estimation.

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 provides clear guidance on when to use the tool, mentioning options to provide voyage_id, wreck_id, or explicit lat/lon. It also offers tips for improving scoring via source_description keywords. However, it does not explicitly compare against sibling tools or state when not to use it.

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

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

Since no annotations are provided, the description carries full burden. It reveals that wreck links use exact matching (precision=1.0) and CLIWOC links use fuzzy matching. It also describes output format (JSON/text with metrics). No mention of destructive actions or permissions, but it implies read-only audit.

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?

Description is well-structured with a summary, details, and tips. Concise yet informative. One minor point: the 'Returns' section could be merged with the summary, but overall 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?

Covers return values (precision/recall, confidence distributions) despite no output schema. Includes example targets for LLM guidance. Single parameter fully explained. No gaps in context for usage.

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 only parameter (output_mode) is described in the Args section with default and valid values ('json' or 'text'), adding meaning beyond the schema which only shows a default. Schema coverage is 0%, so description 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 explicitly states the tool audits cross-archive link quality against known ground truth, with specific details on precision/recall evaluation for different link types (CLIWOC tracks, wrecks). It clearly distinguishes itself from sibling tools like search or aggregate functions.

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 tips for when to run (after data updates) and targets (200+ CLIWOC fuzzy matches, mean confidence > 0.7). Does not explicitly state when not to use, but context makes it clear this is a specific audit 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?

Discloses the comprehensive nature of the response, including archives, tools, ship types, and regions. Explains that output can be JSON or text based on the output_mode parameter. No annotations exist, so description carries full burden; it does so thoroughly.

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

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

Well-structured with sections (title, description, args, returns, tips). Each sentence adds value, and important information is front-loaded. No unnecessary repetition.

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?

As a capability-listing tool, the description covers what it returns, how to use it, and its role in a workflow. No output schema exists, but the description adequately details the output 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?

The only parameter, output_mode, has a default but no enum in schema. The description adds valid values ('json' or 'text') and explains its effect, which compensates for the 0% schema 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 that the tool lists full server capabilities (archives, tools, reference data) and instructs to 'Call this first to understand what the server can do.' This distinguishes it from sibling tools that perform searches or retrieve specific records.

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 call this first for workflow planning, provides a typical workflow sequence, and explains the contents of each section of the output. This gives clear when-to-use and how-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, the description carries full behavioral burden. It explains the computation steps (daily speeds, statistical test) and optional return of raw arrays, but does not explicitly declare read-only or non-destructive nature. Given the analytical context, it is adequately transparent but could be more explicit.

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: purpose, method, parameter list, returns, and tips. It is front-loaded with the main objective. While not extremely concise, each sentence adds value with 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?

Given 18 parameters and no output schema, the description covers the core functionality, parameter semantics, and return format. Tips address common use cases. Minor gaps: it doesn't mention data prerequisites (e.g., wind data required for wind_force filters) or edge cases like missing 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?

All 18 parameters are documented in the Args section with descriptions that add meaning beyond schema names. Some descriptions are brief (e.g., 'nationality' lacks code format), but overall they clarify usage significantly. The 0% schema coverage is fully compensated.

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: 'Compare sailing speed distributions between two time periods.' It specifies the statistical method (Mann-Whitney U test) and effect size (Cohen's d), and differentiates from sibling tool maritime_did_speed_test via tips.

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 usage context through a 'Tips' section, advising when to use aggregate_by='voyage' for independent samples, and mentions an alternative tool (maritime_did_speed_test). However, it does not explicitly state 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 bears full burden. It discloses that the tool calculates mean and median wage differences, uses two data sources with specific time ranges, and reports a percentage difference. It also mentions that the origin filter is only effective with MDB records. It does not describe error handling or data availability scenarios, but overall it covers key behaviors.

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 moderately sized with a clear front-loaded purpose. It uses bullet points for parameters and tips, making it scannable. A few sentences could be trimmed, but overall it is efficient 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?

Given 8 parameters, no output schema, and no annotations, the description covers the tool's functionality, parameters, return format, and usage tips. It explains the data sources and filter limitations. It lacks details on error cases or extreme inputs, but provides enough for typical 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 description coverage is 0%, so the description must describe each parameter. It does so by listing each argument with a brief explanation (e.g., 'group1_start: Start year for first comparison group'). It also provides defaults and tips for source and output_mode, adding meaning beyond the schema's type information.

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 that the tool compares crew wage distributions between two time periods, calculates mean and median wages, and reports percentage difference. It distinguishes itself from sibling tools like maritime_compare_speed_groups by focusing on wages. The verb 'compare' and resource 'wage distributions' are specific.

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 tips for LLMs on data source selection and filter constraints (e.g., origin only works with source='crews'). However, it does not explicitly state when to use this tool over alternatives like maritime_crew_demographics or search_crew. It gives clear context for usage but lacks exclusion criteria.

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?

Describes the algorithm (haversine distance, speed in km/day), default filters (min_speed=5, max_speed=400), and typical speed ranges for sailing ships. No annotations provided, but description adequately informs behavior, though could explicitly state 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?

Well-structured with clear sections: overview, Args, Returns, Tips. Informative but slightly lengthy; every sentence adds value, though some redundancy could be trimmed.

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 parameter semantics, algorithm, output format, and usage tips. Lacks explanation of error handling or edge cases, but sufficient for a computation tool with no output schema.

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%, but description includes a detailed 'Args' section explaining each parameter's meaning, defaults, and constraints (e.g., 'min_speed_km_day: filters out anchored/drifting'). Adds significant value beyond the bare 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?

Description clearly states it 'Compute daily sailing speeds for a single CLIWOC voyage' using haversine distance, distinguishing from sibling 'maritime_aggregate_track_speeds' for bulk analysis.

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 when-to-use guidance: 'Get voyage_id from maritime_search_tracks results', 'Use lat/lon bounds to focus on a specific ocean region', and mentions alternative 'maritime_aggregate_track_speeds for bulk analysis'.

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 full burden and explains the search, grouping, reconstruction process, output format options (json/text), and result fields (ranks_held, career_span_years, final_fate, voyage details). It does not mention rate limits or edge cases but is sufficiently transparent for safe use.

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 starting with purpose, then process, then parameters, then tips. Every sentence provides valuable information without redundancy. It is concise yet comprehensive.

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 3 parameters, no output schema, and no annotations, the description is remarkably complete: it explains the overall behavior, parameter details, return format, and practical usage tips. No important aspect is missing.

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, which it does thoroughly: name (substring, case-insensitive), origin (optional, exact match, disambiguate), output_mode (json default or text). This adds substantial meaning beyond the basic schema types.

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 reconstructs career history for crew members by name, which distinguishes it from sibling tools like maritime_search_crew (just search) and maritime_get_crew_member (single member). It specifies the action (reconstruct, searches, groups, reconstructs), resource (VOC Opvarenden dataset), and scope (chronological career).

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 tips on when to use origin to disambiguate and what fields to look at, but does not explicitly state when to use this tool versus alternatives like maritime_search_crew or maritime_get_crew_member. It implies usage context but lacks explicit when-not or alternative 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 are provided, so the description carries the full burden. It describes the tool as analyzing and showing distributions, implying a read-only operation. However, it does not explicitly state that no data is modified or disclose any potential side effects or limitations. The context makes the behavior clear, but there is room for explicit safety statements.

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 with a summary line, dataset context, detailed Args list, and tips. It is concise yet thorough, with no extraneous information. The Args list is slightly long but necessary for clarity, earning a high but not perfect score.

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 8 parameters and no output schema, the description explains the output as 'JSON or text with demographic breakdown' and mentions 'fate sub-distribution'. However, it does not specify the exact structure or edge cases, leaving some ambiguity for the agent. More details on output format would improve 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 description coverage is 0%, but the description provides detailed explanations for all 8 parameters in the Args section, including defaults and examples. It goes beyond schema by giving concrete usage tips and expected values, fully compensating for the lack of 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 begins with a clear verb ('Aggregate') and resource ('crew demographics'), and specifies the grouping dimensions (rank, origin, fate, decade, ship). This distinguishes it from sibling tools like maritime_crew_career or search_crew, which focus on individual records or different analyses.

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 'Tips for LLMs' section provides explicit guidance on when to use each group_by option and how to combine filters, e.g., using group_by='decade' for trends or combining rank and decade for sailor recruitment. While it does not explicitly mention when not to use the tool, the tips are clear and practical.

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 transparently explains that rates are computed from service_end_reason and defines survival/mortality/desertion rates. It also clarifies that rates are per 100 crew with known fate. No destructive behavior is implied, and the tool appears safe.

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 and well-structured: a clear main sentence, followed by Args, Returns, and Tips sections. Every sentence adds useful information without 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?

The description covers all key aspects: purpose, data source, parameters, output format, and interpretive tips. No output schema exists, but the returns section explains the format. It could mention error handling or edge cases, but overall it's sufficiently complete for a six-parameter, no-enum 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?

The input schema has 0% description coverage, but the 'Args' section fully describes each parameter, including allowed values for group_by, date_range format example, substring filtering for rank/origin, default for top_n, and output_mode options. This significantly exceeds the schema's value.

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 analyzes survival, mortality, and desertion rates for VOC crews from the Opvarenden dataset, with specific grouping options. This distinguishes it from sibling tools like maritime_crew_demographics or maritime_crew_career.

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 'Tips for LLMs' section provides concrete examples of when to use different group_by values (e.g., 'group_by='rank' reveals which ranks had highest mortality'), offering good usage guidance. However, it does not explicitly state when not to use this tool or compare it to alternatives.

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

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

Discloses DiD formula, bootstrap resampling, aggregation rationale, and default parameters. No annotations provided, so description carries behavioral burden well. No contradictions.

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

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

Well-structured with sections, formula, and LLM tips. Slightly verbose in parameter descriptions (some redundancy with schema defaults), but overall efficient and 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?

Fully covers purpose, methodology, all parameters, return format (4-cell summary, marginal diffs, DiD estimate, bootstrap CI, p-value), and interpretation. No output schema, but description compensates completely.

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 0% schema description coverage, description thoroughly explains all 17 parameters, including defaults, formats (e.g., 'YYYY/YYYY' range), examples (lat_min=-50 for Roaring Forties), and usage guidance (wind_force_min/max for Beaufort-stratified DiD).

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's a 'Formal 2x2 Difference-in-Differences test: direction x period' and explains what it measures (difference between eastbound and westbound speeds over two periods). Distinct from sibling tools like maritime_compare_speed_groups or maritime_wind_direction_by_year.

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 tips for LLMs on when to use (e.g., wind change analysis), how to interpret results (positive DiD = wind strengthened), and defaults (aggregate_by='voyage'). Doesn't explicitly mention alternatives, but 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 provided, but description explains interpolation method, typical sailing times, confidence levels, and limitations (weather, ship condition). Sufficiently transparent.

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 clear sections: description, Args, Returns, Tips. Every sentence adds value; no filler.

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?

Comprehensive for a tool with no output schema or annotations. Explains return values, confidence levels, and suggests related tools. Covers all necessary information 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 0%, but description includes an 'Args' section that explains every parameter in detail. Also provides tips for LLMs on how to choose route_id and get departure_date.

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 estimates a ship's position on a specific date using linear interpolation. Distinguishes from siblings like maritime_assess_position and maritime_get_track.

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 tips on when to use (investigating wreck locations) and how to get inputs (via maritime_get_voyage, maritime_list_routes). Mentions combining with maritime_assess_position, but does not explicitly state when not to use.

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

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

Given no annotations, the description carries full burden. It discloses that it creates a GeoJSON document with WGS84 coordinates, explains properties added by booleans, and notes output formats. It does not mention potential errors, rate limits, or performance implications, but for a read-only export tool, it provides sufficient 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 well-structured with sections, but includes a 'Tips for LLMs' section that partly repeats information from the Args. It is fairly concise for the level of detail, earning a slightly above-average score.

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?

Despite having 7 parameters and no output schema, the description covers all parameter functionality, explains the return format (GeoJSON FeatureCollection with count), and provides usage context. It is comprehensive enough for an agent to 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?

With schema description coverage at 0%, the description fully compensates by explaining each parameter's purpose and options (e.g., region list, status options, default values for booleans, output_mode choices). This adds significant meaning beyond the bare JSON 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?

The description clearly states it exports wreck positions as a GeoJSON FeatureCollection. This distinguishes it from sibling tools like search_wrecks (list/search) and get_wreck (single wreck details), as it specifically creates a GIS-ready format.

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 tips on using specific parameters (wreck_ids, region, status) and explains the benefits of include_uncertainty and include_voyage_data. However, it does not explicitly contrast with alternative tools like maritime_search_wrecks or maritime_get_wreck, leaving some ambiguity for when to use this export tool vs. other data retrieval methods.

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 that the tool returns raw speed records with full metadata, supports pagination (max_results, offset, next_offset), and offers different aggregation modes. It does not mention potential side effects (e.g., no destructive actions), but the non-destructive nature is clear. Some additional details like rate limits are missing, but overall transparency is high.

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 with clear sections (Args, Returns, Tips for LLMs) and front-loads the purpose. While it is lengthy due to comprehensive parameter explanations and usage tips, each sentence adds value. The structure aids readability, but some trimming of redundant tips (e.g., multiple examples of pagination) could improve 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?

Given the complexity (19 parameters, no output schema, no annotations), the description is remarkably complete. It covers all parameters, explains return formats (JSON, text, CSV), pagination mechanism, and provides concrete analysis examples. The absence of an output schema is compensated by a clear description of returned fields for each mode. The description leaves little ambiguity for an AI agent to select and 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?

The input schema has 0% parameter coverage (no descriptions), but the description provides extensive semantics for all 19 parameters. It explains each parameter's purpose, default values, and usage tips (e.g., 'aggregate_by: "voyage" (one mean speed per voyage, recommended for statistical independence)'). It also clarifies the 'fields' parameter with a detailed list of available fields for different aggregation modes. This adds significant meaning beyond the 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?

The description uses the verb 'export' and clearly identifies the resource as 'raw speed samples'. It explicitly distinguishes from the sibling tool 'maritime_aggregate_track_speeds', stating 'Unlike... which groups and summarises, this tool returns the underlying data.' This provides a specific verb+resource and differentiates from alternatives.

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 gives explicit usage context: 'Essential for analyses requiring non-contiguous year comparisons... ENJO phase classification, volcanic event detection'. It also provides 'Tips for LLMs' with concrete scenarios (e.g., tidal analysis, Laki 1783) and recommendations on output_mode, fields, and pagination. This fully guides when and how to use the 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?

Without annotations, the description carries the full burden. It discloses the return type (per-voyage transit days with summary statistics), data completeness (213 of 250 voyages have complete data), and typical values (mean and std). No destructive behavior is implied; it reads as read-only. No contradictions with annotations.

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 relatively long but well-structured with clear sections (description, args, returns, tips). Each sentence adds value, though some tips might be considered extra. It is front-loaded with the core 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 no annotations and no output schema, the description is fairly complete. It covers purpose, parameters, return format, and usage guidelines. It could mention error handling or output format details more, but it is sufficient 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?

The input schema has 0% description coverage, so the description fully compensates by explaining each parameter in the 'Args' block, including purpose, examples, and constraints (e.g., default values, direction-specific details). This adds significant meaning beyond the 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?

The description clearly states it computes transit times for Manila Galleon voyages, with a specific verb 'Compute' and resource 'transit times'. It distinguishes from siblings by focusing on galleon voyages and ENSO proxy, which is unique among the maritime tools listed.

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 guidance on when to use the tool (e.g., 'Use trade_direction="eastbound" for ENSO analysis') and offers tips for LLMs. However, it does not explicitly state when not to use the tool or name alternative sibling tools for similar tasks.

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 clearly states this is a read operation retrieving metadata, specifies the return format (JSON or text), and lists the content. No side effects are implied. A small gap is that it doesn't explicitly state that it does not modify data, but given the context it's clear.

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 and well-structured: a one-line purpose, bulleted list of returned info, parameter descriptions, return format, and a dedicated tips section. Every sentence adds value, and it is front-loaded with the key information.

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

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

Given no output schema, the description fully explains what is returned (organisation, coverage period, etc.). It also provides tips for usage and archive meanings, making it complete for an agent to invoke 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 input schema has no descriptions (0% coverage), so the description must compensate. It does so by explaining that archive_id takes values like das, voc_crew, voc_cargo, maarer, and that output_mode defaults to 'json'. This adds essential meaning beyond the raw 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?

The description explicitly states 'Get detailed metadata for a specific maritime archive' and lists the specific metadata fields returned (organisation, coverage period, record types, etc.), making the purpose clear and distinct from sibling tools like maritime_list_archives.

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 'Tips for LLMs' section provides explicit guidance: use maritime_list_archives first to see valid IDs, and explains the purpose of each archive. This helps the agent decide when to use this tool and what parameters to supply.

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?

Despite no annotations, the description discloses returns (fields like commodity, quantity, unit, value in guilders), output modes (json/text), currency denomination, archival date ranges, and the fact that not all voyages have records. This fully compensates for missing annotations.

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-organized with a concise summary, bullet-point return values, clear Args and Returns sections, and a separate Tips block. Every sentence adds value without being 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?

The description covers purpose, parameters, returns, usage workflow, and historical context. For a tool with no output schema and two parameters, it leaves no gaps in understanding how to use it.

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

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

With 0% schema coverage, the description adds essential meaning: voyage_id connects to search results or DAS ID, output_mode has default 'json' and alternative 'text'. This fully explains the parameters beyond the raw 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?

The description clearly states the action ('Get the full cargo manifest') and the resource ('for a specific voyage'), distinguishing it from sibling tools like maritime_get_wreck or maritime_get_voyage.

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 'Tips for LLMs' section explicitly advises to use maritime_search_voyages first and suggests combining with maritime_get_wreck, along with notes on archival coverage. This provides clear when-to-use and contextual 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, but the description compensates by listing returned fields (name, rank, origin, etc.), explaining pay units (guilders) and meaning of fate values (survived, died_voyage, etc.). It does not mention side effects, but as a read operation, it is adequately transparent.

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 with sections and front-loaded purpose, but includes some repetition (e.g., listing fields in both the initial sentence and the return explanation). Every sentence adds value, but could be slightly more compact.

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 2-parameter tool with no output schema, the description covers all aspects: parameters, return data fields, units, and cross-reference suggestions. It is fully self-contained for the agent to use 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 description coverage is 0%, yet the description adds full meaning: crew_id is 'Crew member identifier (from search results)' and output_mode options are explained ('json' or 'text'). It also provides domain knowledge about pay and fate constants, far exceeding 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 'Get full details for a specific crew member' with a specific verb and resource. It distinguishes itself from sibling tools like maritime_search_crew which is for finding IDs, and other 'get' tools by focusing on crew members.

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 use maritime_search_crew first to obtain crew_id, and suggests cross-referencing with maritime_get_voyage for full context. It also explains the output_mode parameter options, providing 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?

No annotations provided, but description explains it's a retrieval operation returning hull profile data. Does not explicitly state idempotent/read-only, but is implied. Adds context on returned fields and purpose, though could mention no side effects.

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

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

Well-structured with clear sections: description, args, returns, tips. No redundant sentences, front-loaded with key info, efficiently covers all needed aspects.

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?

Despite no output schema or annotations, description covers purpose, parameters, return content, and usage tips. Domain-specific advice makes it complete for the tool's 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?

Input schema has no enums and 0% coverage. Description adds full parameter details: lists allowed ship_type values and output_mode options (json/text), exceeding schema info.

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 'Get hydrodynamic hull profile for a VOC ship type' with specific fields listed. Distinguishes from sibling 'maritime_list_hull_profiles' which lists types, while this retrieves the profile.

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 tips: use with maritime_list_hull_profiles to see types, essential for drift modelling, notes retourschip as most common. Tells when to use and references sibling.

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. Describes returned data fields (ranks_summary, total_european, etc.) and output modes, but lacks error handling or prerequisite details. Overall good behavioral 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?

Description is well-organized with sections (summary, details, Args, Returns, Tips) but slightly verbose. Every sentence adds value, though 'Tips for LLMs' could be integrated into main 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 no output schema and sibling tools (search_musters, get_voyage, etc.), description covers what is returned, how to use, and related actions. Lacks mention of error handling or edge cases, but sufficient for a get-by-id 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 0%, but description adds meaning: gives an example for muster_id ('dss_muster:0001') and explains output_mode default. Compensates well for missing 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?

Description clearly states 'Get full details for a specific ship muster record.' and distinguishes from sibling tools like maritime_search_musters, which are used to find the muster_id first.

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 tips: use maritime_search_musters to find muster_id, compares with maritime_search_crew for related data, and suggests using maritime_get_voyage if das_voyage_id is set. Clearly tells when to use 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 carries the full burden. It discloses that the tool returns waypoints with coordinates, durations, hazards, and seasonal notes, and the tips add behavioral details about cumulative_days and stop_days. However, it does not mention potential side effects, permissions, or error scenarios, which for a read-only data retrieval tool is acceptable but not fully transparent.

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 into summary, return description, args, return specification, and tips. Each sentence adds value without redundancy. It is appropriately concise for the amount of information needed.

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 no output schema, so the description must explain the return format. It does so adequately, listing included fields. The tips provide additional context about waypoint structure. Minor omissions: no mention of error responses or handling invalid route_ids, but overall complete for typical usage.

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 0% schema description coverage, the description compensates excellently by listing all valid route_id values grouped by company and route, explaining the output_mode parameter with defaults. This adds significant meaning beyond the bare schema types.

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 full details of a historical sailing route, specifying verb+resource+scope. The description distinguishes it from siblings like maritime_list_routes (list only) and maritime_estimate_position (position estimation) by focusing on comprehensive route details including waypoints, hazards, and seasonal notes.

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 'Tips for LLMs' section provides explicit guidance on complementary tools (maritime_lookup_location, maritime_estimate_position) and how to use the output for further analysis. However, it does not explicitly state when not to use this tool or contrast it with all 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?

Without annotations, the description partially bears the burden. It discloses data source (CLIWOC) and output details but omits side effects, auth requirements, or rate limits. The description implies read-only behavior but doesn't confirm it.

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 with summary, Args, Returns, and Tips sections. It front-loads the core purpose. While comprehensive, it could be slightly more concise without losing clarity.

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 and three parameters, the description is fully complete: it explains output format (JSON/text), lists return fields (mean_km_day, std_dev, sample_count) in tips, and covers all inputs. No gaps remain.

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 fully compensates by detailing each parameter: route_id usage, departure_month as optional filter, output_mode with default and examples. It adds significant meaning beyond the schema types.

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 gets historical sailing speed statistics for a route, including specific metrics (mean, median, std dev) and optional seasonal filtering. It effectively distinguishes the tool from siblings by focusing on route-level speed profiles.

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 tips for LLMs on comparing months and using with other tools, implying appropriate use cases. However, it does not explicitly state when not to use this tool or contrast it with alternatives like maritime_aggregate_track_speeds.

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 takes on the full burden. It explains the tool computes summary statistics and lists the breakdowns in the response (losses_by_region, losses_by_cause, etc.), but does not disclose potential side effects, rate limits, or authentication needs. It accurately describes the read-only nature implicitly.

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 with a clear opening, bullet-like lists for computed statistics and parameters, and dedicated tips. Though somewhat lengthy, every section adds value and no information is redundant. It could be slightly shortened but remains 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's moderate complexity (4 parameters, no output schema), the description is complete. It covers what the tool does, what parameters mean, and what the response contains. Tips for LLMs provide actionable guidance (e.g., comparing decades or regions). No missing critical information.

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 provides detailed explanations for all 4 parameters: archive (default all), date_range (format YYYY/YYYY, default 1595-1795), group_by (reserved), output_mode (json or text, default json). Tips further illustrate usage (e.g., 'Use date_range to focus statistics'). This fully compensates for the schema gap.

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: 'Get aggregate statistics across maritime archives' and specifies it computes summary statistics for VOC shipping losses. This differentiates it from sibling tools that focus on individual records or specific aspects.

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 implies the tool is for aggregate summaries rather than detailed records, but it does not explicitly state when to use this tool versus alternatives like maritime_search_vessels or maritime_get_voyage. No exclusion criteria or alternative tools are mentioned.

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 reveals that events combine multiple archives, may have conflicting dates, that include_positions can add many events, and that output includes geojson LineString. Nearly comprehensive, though lacks mention of 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?

Well-structured with headings (first sentence, paragraph, Args, Returns, Tips for LLMs). Approximately 150 words, no redundancy. Could be slightly more compact, but is clear and 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?

Covers purpose, usage, parameters, output format, and data sources. Tips provide practical advice. Lacks error handling details or ordering criteria, but overall complete for a complex tool with no output schema.

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 0%, but description compensates fully with an Args section explaining each parameter: voyage_id with example, include_positions with default and effect, max_positions with default, output_mode with format options.

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 starts with 'Build a chronological timeline of events for a voyage.' which is a specific verb+resource. It distinguishes from sibling 'maritime_get_voyage_full' by stating it returns non-chronological linked 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?

Provides explicit when-to-use (chronological timeline) and when-not (non-chronological linked data). Tips for LLMs offer practical usage guidance: start with include_positions=False, then set True for detailed track.

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 explains return structure (dated lat/lon positions daily), data nature (logbook readings, gaps), and accuracy (±20-50km). Does not explicitly state read-only, but 'get' implies it.

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?

Description is well-structured with sections, concise yet informative. Every sentence adds value, including tips for LLMs.

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 2 parameters and no output schema, description covers return type, data frequency, and accuracy. Could mention if dates are included explicitly, but 'dated lat/lon positions' suffices.

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%, but description explains voyage_id as integer from search results and output_mode with default and options, adding meaning beyond the 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?

Description uses specific verb 'Get' and resource 'full position history for a CLIWOC voyage', clearly distinguishing from sibling tools like maritime_search_tracks and maritime_export_geojson.

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 clear usage context via tips: get voyage_id from search, positions are daily, gaps indicate missing entries, combine with export. Lacks explicit when-not-to-use but covers prerequisites and application.

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 were provided, so the description bears full responsibility. It clearly describes the tool as a retrieval operation returning vessel details, with no mention of side effects or destructive actions. While it doesn't explicitly state 'read-only', the description implies it. Additional context on rate limits or auth would improve 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 well-structured with sections for Args, Returns, and Tips. It is slightly verbose (e.g., 'Tips for LLMs' heading) but each sentence adds value. Could be tightened while retaining clarity.

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, so the description must explain return values. It lists the fields included in the full vessel record and mentions JSON or text formats. Tips help integrate with other tools. Some detail about the structure of the record would enhance completeness, but it's adequate.

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 provides detailed explanations for both parameters: vessel_id as an identifier from search results, and output_mode with 'json' (default) or 'text'. This adds significant meaning beyond the bare 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?

The description explicitly states it 'Get full details for a specific vessel' and lists the fields returned (name, type, tonnage, etc.), clearly distinguishing it from search tools like maritime_search_vessels.

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 includes specific guidance: use maritime_search_vessels first to find vessel_id, and provides cross-references to maritime_get_hull_profile and maritime_search_voyages with context on when to use them. It also explains tonnage units.

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

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

No annotations exist, so the description carries the full burden. It discloses that incident details are included if the voyage ended in shipwreck, adding useful behavioral context. However, it does not mention any potential side effects or authentication requirements, but for a read operation 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?

The description is brief, front-loaded with the main purpose, and structured with tips in a bullet-like list. Every sentence earns its place with 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?

Given the tool's simplicity (2 parameters, no output schema), the description fully covers what the tool does, what it returns, and how to use it. It also guides the agent to related tools, ensuring complete contextual guidance.

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 0% schema description coverage, the description fully explains both parameters: voyage_id's source (search results or DAS ID) and output_mode's values (json or text). This adds meaning far beyond the bare 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?

The description clearly states 'Get full details for a specific voyage' and enumerates what the response includes (ship info, captain, route, dates, fate, incident details), distinguishing it from sibling tools like maritime_search_voyages.

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 that the voyage must be found by a prior maritime_search_voyages call or specified by DAS identifier, and provides tips for further exploration with other tools. This gives clear when-to-use and how-to-chain instructions.

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

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

Without annotations, the description discloses behavioral traits: returns enriched data with confidence scores, optional crew inclusion, and output format choices. It does not mention mutability or safety, but read-only nature is implied by 'get'. Sufficient transparency for tool selection.

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 with Args, Returns, and Tips sections. It is informative but could be slightly more concise; for example, the Tips section repeats some info. Still efficient and 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 the complexity of a unified view with multiple linked records, the description covers key aspects: what is returned, how confidence works, and optional crew. Missing exact output structure but sufficient for an agent to understand capabilities.

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%, but the description fully explains each parameter: voyage_id with examples, include_crew with effect, output_mode with options. It adds context beyond schema (e.g., confidence interpretation, link fields). This compensates for missing 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 tool retrieves a unified voyage view with all linked records, distinguishing it from sibling tools like get_voyage, get_wreck, etc. It specifies what is included (wreck, vessel, hull profile, CLIWOC track, crew) and provides a specific action verb 'get unified view'.

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 gives explicit when-to-use guidance: start with maritime_search_voyages, and notes this tool replaces separate calls. It provides tips on include_crew and confidence scores, and mentions cross-referencing. This is comprehensive 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 full burden; it discloses that the tool returns a complete record and lists output fields. It could explicitly state it is read-only, but the 'Get' verb implies no side effects.

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

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

Description is well-structured with clear sections (purpose, content list, args, returns, tips) and front-loaded. Slightly verbose but 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 no output schema and 0% schema coverage, the description covers the return contents, parameters, prerequisites, and suggests follow-up actions. Could mention error handling or limits.

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 adds necessary meaning: it explains wreck_id comes from search results and output_mode determines format, compensating for the schema's lack of documentation.

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 'Get full details for a specific wreck record' and lists included fields, differentiating it from sibling tools like maritime_search_wrecks (which returns summaries) and other get 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 'Tips for LLMs' section explicitly advises using maritime_search_wrecks first to obtain the wreck_id, and suggests complementary tools (assess_position, export_geojson, get_voyage), providing a clear workflow.

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 fully discloses that the tool returns metadata without side effects. It provides tips for usage. However, it could mention any potential limitations (e.g., number of archives) or whether the output is always a list.

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, well-structured with a summary, arguments, returns, and tips. Every sentence adds value, and the key information 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 the simplicity of the tool (one optional parameter, no output schema, no annotations), the description is thoroughly complete. It covers purpose, parameters, return format, and practical usage advice.

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 coverage is 0%, so the description's 'Args' section is essential. It explains the output_mode parameter's meaning and default, adding value beyond the schema. The parameter is simple and well-described.

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 all available maritime archives, providing specific metadata fields and distinguishing it from many sibling tools. It includes a clear verb ('List') and resource ('archives').

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 advises to call this first and suggests using maritime_capabilities for an overview. It gives context on archive IDs and their contents, implicitly guiding when to use this tool. However, it lacks explicit 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?

Discloses return format options (JSON or text) and the nature of output (VOC ship type identifiers). With no annotations, this covers essential behavior for a simple list 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?

Well-structured with main purpose, args, returns, and tips. Front-loaded and efficient, though the Arg/Return sections could be slightly tighter.

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?

Complete for a simple list tool with one optional parameter: explains purpose, usage, return details, and provides common examples. Does not need output schema as return is self-explanatory.

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?

Despite 0% schema_description_coverage, the description explains the output_mode parameter's values and default, compensating fully for the missing schema documentation.

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 available ship types with hull profiles, using specific verbs ('List', 'Returns') and distinguishes itself from sibling maritime_get_hull_profile by explicitly recommending prior use.

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 instruction to use before calling maritime_get_hull_profile and lists common ship types. However, does not mention when not to use or alternative tools beyond the one get function.

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 discloses important behaviors: returns a list with coordinates and region classifications, uses case-insensitive substring match for query, supports JSON or text output. It also notes the default max_results. While it doesn't detail auth or performance, it sufficiently describes the core behavior.

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 with clear sections (overview, Args, Returns, Tips) and each sentence adds value. It is slightly longer but not wasteful, as the tips provide actionable guidance. Could be slightly more concise by integrating some tips into the main description.

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 5 parameters, no output schema, and no annotations, the description is comprehensive. It covers purpose, all parameters with options, return format, and usage strategies. The tips section further enhances completeness by showing the agent how to effectively use the tool in context with sibling tools.

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% description coverage, but the description compensates with a detailed 'Args' section, listing each parameter, its purpose, and options (e.g., region values, location_type options, defaults). This adds significant meaning beyond the schema structure.

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 or browses a VOC historical gazetteer, returns locations with coordinates and region classifications. It distinguishes itself from the sibling 'maritime_lookup_location', which is for full details on a specific place, by focusing on listing/browsing with filters.

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 this tool, including tips for LLMs such as calling without filters to see all locations, using region and location_type filters, and following up with maritime_lookup_location. However, it does not explicitly state when not to use it or compare to other siblings beyond the one mentioned.

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 full burden. It explains that the tool lists routes, covers specific historical types, and returns summaries with durations. It does not mention any side effects, rate limits, or permissions, but for a read-only listing tool, this is sufficient. The description does not contradict any annotations (none provided).

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 with a brief intro, parameter details in a clear bullet-like format, and a tips section. It is concise but contains all necessary information. Minor redundancy (route types listed twice) prevents a perfect score.

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 (list command, no output schema, 4 optional parameters), the description is complete. It explains what is returned, provides parameter usage examples, and suggests follow-up tools. The low schema coverage is fully compensated by the detailed parameter descriptions.

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 4 parameters with no descriptions (0% coverage). The description compensates fully by detailing each parameter: direction with possible values, departure_port and destination_port as substring matches, and output_mode with 'json' (default) or 'text'. This adds significant meaning beyond the 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?

The description clearly states the tool's purpose: 'List available historical sailing routes.' It specifies the types of routes covered (VOC, EIC, Carreira da India, etc.) and what is returned (summaries with typical durations). This distinguishes it from sibling tools that focus on tracks, vessels, or crew.

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 includes a 'Tips for LLMs' section that provides explicit usage guidance: use direction='outward' for Europe-to-Asia routes, use departure_port and destination_port to find specific routes, and suggests follow-ups with maritime_get_route and maritime_estimate_position. This helps the agent decide when to use this tool and what to do next.

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 automatic handling of historical spellings, approximate coordinates, and output formats. However, it does not mention side effects, rate limits, or authentication needs, which would push it to 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?

The description is well-structured with clear sections (Args, Returns, Tips). It is concise, every sentence adds value, and the tips section is particularly useful without being verbose. Front-loaded with the main 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 no output schema, the description explains the return format (JSON or text with coordinates, region, historical notes). It also contextualizes integration with other tools. For a lookup tool with two parameters, this is complete and falls within expected 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 description coverage is 0%, so the description must compensate. It explains the 'name' parameter with concrete examples ('Batavia', 'Texel') and notes historical Dutch support. The 'output_mode' parameter is described with default and two values. This adds significant meaning beyond the bare 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?

The description clearly states it looks up historical place names in the VOC gazetteer, returning coordinates, region, and historical context. It uses specific verbs and resources, and differentiates from sibling tools like maritime_list_locations and maritime_assess_position via the tips section.

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: after reading a voyage's 'particulars' field for geocoding. It also suggests alternatives (maritime_list_locations to browse places, maritime_assess_position for position accuracy evaluation), giving clear context and exclusions.

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