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

With no annotations, the description carries the behavioral burden. It does disclose the output unit (km) and that inputs are Maidenhead locators, which is useful context, but it says nothing about determinism, error behavior on invalid locators, or that this is a pure stateless computation.

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?

A single front-loaded sentence with zero waste; the verb and resource lead immediately. Nothing is redundant or padded.

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?

An output schema exists, so return values need not be explained, and with only two simple required params the description is nearly sufficient. However, it omits any locator format detail or failure behavior, leaving a small but real gap for a computation tool.

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

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

Schema description coverage is 0%, so the description must compensate. It tells the agent both parameters are Maidenhead locator strings and implies a start/end direction, but it doesn't tie the names 'start' and 'end' to their semantics or give format examples.

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

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

States a specific verb (calculates) and a specific resource (distance) and clarifies the input format (Maidenhead locators) and output unit (km). It distinguishes itself from calculate_heading by being about distance rather than bearing, though it doesn't name that sibling explicitly.

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

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

There is no guidance on when to use this tool versus calculate_heading or any other sibling, and no prerequisites or conditions are stated. The purpose implies usage but the description offers no routing help.

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

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

With no annotations, the description carries the full burden, and it leaves key traits undisclosed: the unit and range of the returned azimuth, whether it is true or magnetic north, and whether start/end order affects the result. It does imply a pure deterministic computation, but that is inference rather than 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?

A single front-loaded sentence with zero filler; the verb, the computed quantity, and the input format all land in one clause.

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?

An output schema exists, so return-value explanation is not required, and the description names the input domain. The remaining gap is the convention behind the heading (units and reference direction), which an agent needs to interpret results 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% and neither 'start' nor 'end' is described in the schema, so the description must compensate. It partially does by stating the inputs are Maidenhead locators, which conveys the required string format, but it never says which endpoint is the origin or what a valid locator looks like.

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

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

States a specific verb+resource ('Calculates heading') and disambiguates the term with '(azimuth)', which distinguishes it from the sibling calculate_distance without naming it. Sibling differentiation is implied by the resource noun rather than stated explicitly.

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

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

No guidance on when to use this versus calculate_distance, no mention of prerequisites, and no exclusions. The only implicit signal is that inputs must be Maidenhead locators.

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

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

With no annotations, the description must carry the behavioral burden. It implies a read-only operation via 'Returns', but does not explicitly state that it has no side effects, requires no special permissions, or has any rate limits. For a simple version-info getter, this is adequate but not comprehensive.

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

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

The description is a single, front-loaded sentence with no wasted words. It delivers the essential information immediately and efficiently.

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 trivial complexity, the presence of an output schema, and the lack of required parameters, the description is complete enough. It does not need to explain return values because the output schema covers that, and no additional context is necessary to invoke it 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 tool takes zero parameters, so the baseline score is 4. There are no parameter semantics to describe, and the description does not need to compensate for any gaps in the input 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 states a specific verb 'Returns' and resource 'version of the ADIF-MCP server and spec', clearly conveying what the tool does. However, it does not distinguish itself from sibling tools, though that differentiation is largely unnecessary given the trivial and unique nature of the operation.

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

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

The description offers no guidance on when to use this tool versus alternatives. It simply states what is returned, leaving usage context to inference. No conditions, exclusions, 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 are provided, so the description carries the full burden. It usefully discloses the exact count (26), the ADIF-vs-derived composition, and that each entry carries a ``source`` discriminator — real behavioral context. It stops short of stating read-only/permission characteristics or how the list is ordered, though the presence of an output schema reduces the need to explain return shape.

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

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

Two tight sentences, front-loaded with the count and composition, followed by the one non-obvious semantic detail (the ``source`` field). 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?

For a no-argument enumeration list with an output schema already documenting the return shape, this is nearly complete: scope, count, and the meaning of the ``source`` field are all covered. The only gap is the unstated relationship to search_enumerations.

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

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

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate.

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

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

States a specific verb ('Lists') and resource ('the 26 enumerations') with exact scope (ADIF 3.1.7's 25 plus Country). It does not, however, differentiate itself from the sibling search_enumerations, leaving the agent to infer that this is the full-list variant.

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 clause 'so a consumer loading reference tables can tell them apart' implies the intended use case (bulk reference-table loading), but there is no explicit when-to-use vs. when-to-use-search_enumerations guidance and no exclusions.

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

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

With no annotations, the description carries the full behavioral disclosure burden. It usefully discloses streaming behavior, record seeking, and that the tool reads local filesystem paths with a security warning, but it omits return format, pagination effects of limit/start_at, and error 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 two sentences plus a security note, with the core purpose front-loaded. It is efficient and the security note earns its place, though the all-caps formatting is mildly distracting rather than harmful.

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 3-parameter parser with no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It adds a valuable security warning but leaves parameter semantics, return shape, and pagination behavior unexplained.

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 should explain file_path, limit, and start_at. It only hints at record seeking, which loosely relates to start_at and limit, but it never maps parameters to meanings or explains their defaults.

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

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

The description states a specific action and resource: parsing ADIF files, with the qualifiers 'streaming' and 'large' and the feature 'record seeking'. It is clearer than a bare restatement of the name, but it does not explicitly distinguish this tool from siblings such as validate_adif_record.

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 phrase 'for large ADIF files with record seeking' implies a use case, but the description never states when to choose this tool over alternatives like validate_adif_record, nor does it give explicit when-not conditions. The security note constrains accepted paths but not tool selection.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose one useful trait — that an unknown name returns an error listing the available names — and 'Reads' implies a read-only operation, but it omits output format and any confirmation that no state is mutated.

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

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

Two short sentences, front-loaded with the core action and followed by the one behavioral caveat. Nothing is redundant and every sentence carries 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?

An output schema exists, so return values need not be explained. For a single-parameter read tool this is close to sufficient, with the only real gap being the absence of a full list of valid resource names, which is partially mitigated by the documented error path.

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% and the single resource_name parameter has no enum, so the description must supply the value domain. It partially compensates by listing example values ('mode', 'fields', 'all') and noting the error-on-unknown behavior, but does not enumerate the full valid set.

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

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

The description states a specific verb and resource ('Reads an ADIF 3.1.7 specification resource') and gives concrete examples ('mode', 'fields', 'all'), so an agent knows exactly what it retrieves. It does not, however, differentiate itself from close siblings like list_enumerations or search_enumerations, which also surface ADIF metadata.

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?

There is no explicit guidance on when to prefer this tool over siblings such as list_enumerations or search_enumerations, nor any stated preconditions. The examples hint at resource names but do not constitute usage direction, so the agent must infer the selection criteria on its own.

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 behavioral burden. It does not disclose matching semantics, case sensitivity, pagination, or result ordering. The existence of an output schema covers return structure, but behavior beyond that remains undocumented.

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

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

Two short sentences, front-loaded with the core action, with no filler. It is efficient, though arguably too terse given the gaps in parameter and usage detail.

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 search tool with two parameters (one required and undocumented) and no annotations, the description is incomplete. It neither explains the required search_term semantics nor routes the agent between this and the similarly named list_enumerations sibling.

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 clarifies that 'enumeration' is an optional filter by name, adding some meaning, but it entirely omits the required 'search_term' parameter and its expected format or matching behavior.

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

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

The description states a specific verb and resource: 'Searches ADIF 3.1.7 enumerations.' This is clear and tells an agent what the tool does without opening the schema. However, it does not differentiate from the sibling list_enumerations, so it misses the top mark.

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?

There is no when-to-use guidance, no conditions for selecting this over list_enumerations or read_specification_resource, and no prerequisites. The clause 'Optionally filter by enumeration name' describes a parameter rather than usage context.

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

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

With no annotations, the description carries the full behavioral burden. It does add real substance by naming the ADIF spec version and the enum-membership dimension of validation, and validation implies a side-effect-free check, but it says nothing about error behavior on an invalid record or any constraints on input size/format.

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?

A single front-loaded sentence with no filler; the version number and the enum-membership qualifier are the only two details and both earn their place.

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

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

An output schema exists, so return values (validation results/errors) need not be explained, and the description covers scope, rule set, and check type for a simple one-parameter tool. It stops short of telling the agent what distinguishes it from parse_adif.

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% for the single parameter 'adif_string', so the description must compensate. It signals the input is an ADIF record string, which loosely maps to the parameter, but gives no syntax, format, or size expectations.

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

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

The description states a specific verb and resource ('Validates an ADIF record') plus the precise rule set (3.1.7) and the check performed (enum membership). It is clearly distinguishable from parse_adif in intent, though it never explicitly names or contrasts with that sibling.

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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as parse_adif or read_specification_resource, which the agent must disambiguate against. Usage can only be inferred tautologically from the name.

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