oeradio-mcp

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

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions considering 'Effizienz und Entladetiefe' (efficiency and discharge depth), which hints at calculation factors, but doesn't disclose whether this is a read-only calculation, what format the output takes, error conditions, or any rate limits. For a calculation tool with 5 parameters, this leaves significant behavioral gaps.

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 appropriately concise with two sentences that directly state the tool's purpose and key considerations. It's front-loaded with the main calculation, though it could be slightly more structured by explicitly listing all considered factors. There's no wasted verbiage.

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 calculation tool with 5 parameters and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., runtime in hours, formatted string, JSON object), error handling, or unit expectations beyond what's in the schema. With no annotations and missing output information, users lack sufficient context for reliable 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 100%, so the schema already documents all parameters thoroughly with descriptions, ranges, and defaults. The description adds minimal value beyond the schema by mentioning efficiency and discharge depth as factors, but doesn't provide additional syntax, format, or interaction details. This meets the baseline for high 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 the tool's purpose with specific verbs and resources: 'Berechnet die Akkulaufzeit' (calculates battery runtime) based on 'Kapazität und durchschnittlichem Stromverbrauch' (capacity and average power consumption). It distinguishes from siblings by focusing on battery runtime calculation rather than cable loss, frequency checking, or other radio-related calculations.

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 no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, constraints, or comparison with sibling tools like 'convert_power' or 'calculate_cable_loss' that might be relevant in power calculation contexts. The user must infer usage from the purpose alone.

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 of behavioral disclosure. While it states what the tool does (calculates cable attenuation), it doesn't describe what the calculation returns (e.g., loss in dB), whether it's a pure calculation or involves database lookups, error handling for invalid inputs, or any performance characteristics. The description is minimal and lacks behavioral context.

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

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

The description is a single, efficient sentence in German that directly states the tool's function. It's appropriately sized for this calculation tool with no wasted words or unnecessary elaboration. The structure is straightforward and 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?

For a calculation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the output represents (e.g., attenuation in dB), the calculation methodology, precision, units of the result, or error conditions. While the input schema is complete, the overall context for proper tool usage is incomplete.

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

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

Schema description coverage is 100%, with all parameters well-documented in the schema (cable_type with enum values, frequency_mhz with range, length_meters with range). The description adds no additional parameter semantics beyond what's already in the schema - it mentions the same three parameters but provides no extra context about their meaning, relationships, or calculation methodology.

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: 'Berechnet die Kabeldämpfung für verschiedene Koaxialkabeltypen bei einer bestimmten Frequenz und Länge' (Calculates cable attenuation for various coaxial cable types at a specific frequency and length). It specifies the verb ('berechnet' - calculates) and resource ('Kabeldämpfung' - cable attenuation), but doesn't explicitly distinguish it from sibling tools like 'compare_cables' or 'calculate_swr_loss'.

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 no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'compare_cables' (which might compare cable performance) or 'calculate_swr_loss' (which calculates different types of loss), nor does it specify any prerequisites or contextual constraints for usage.

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 of behavioral disclosure. While it states what the tool calculates, it doesn't disclose important behavioral aspects like whether this is a pure calculation (no side effects), error handling, precision of results, or what format the output takes. The description is functional but lacks operational 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 perfectly concise with two sentences that each earn their place. The first sentence states the core function with all parameters, and the second sentence provides valuable usage context. No wasted words or redundant 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?

For a calculation tool with 3 parameters and 100% schema coverage but no output schema, the description is adequate but has gaps. It explains what's calculated and why, but doesn't describe the output format or any calculation nuances. The lack of output schema means the description should ideally explain what the tool returns, but it doesn't.

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

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

The input schema has 100% description coverage with clear parameter documentation in German. The description mentions the three parameters but doesn't add meaningful semantic context beyond what's already in the schema. The baseline score of 3 is appropriate since the schema does the heavy lifting for parameter 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's purpose with specific verb ('Berechnet' - calculates) and resource (EIRP), listing the three input parameters. It distinguishes from siblings by focusing on EIRP calculation rather than battery runtime, cable loss, wavelength, or other radio-related calculations.

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

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

The description provides clear context for when to use this tool ('Nützlich für Sicherheitsabstands-Berechnungen nach ÖNORM' - useful for safety distance calculations according to ÖNORM standard). However, it doesn't explicitly state when NOT to use it or mention specific alternatives among the sibling tools.

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 of behavioral disclosure. It only states what the tool calculates, without mentioning any behavioral traits such as error handling, performance characteristics, or output format. For a calculation tool with zero annotation coverage, this is a significant gap in transparency.

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

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

The description is a single, efficient sentence in German that directly states the tool's purpose without any unnecessary words. It's appropriately sized and front-loaded, making every word count.

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

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

Given the tool's complexity (a calculation with one parameter) and the absence of both annotations and an output schema, the description is incomplete. It doesn't explain what the calculation returns (e.g., percentage loss, dB loss), nor does it provide context about the calculation method or limitations. For a tool with no structured output information, the description should do more.

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 description coverage is 100%, with the single parameter 'swr' well-documented in the schema (type, range, example). The description doesn't add any parameter semantics beyond what the schema provides, so it meets the baseline score of 3 for adequate coverage without additional 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 the tool's purpose: 'Berechnet den Leistungsverlust durch Fehlanpassung (SWR/VSWR)' which translates to 'Calculates the power loss due to mismatch (SWR/VSWR)'. It specifies the verb (calculates) and resource (power loss from SWR/VSWR mismatch), but doesn't explicitly differentiate from sibling tools like 'calculate_cable_loss' or 'convert_power' which are related but distinct calculations.

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 no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'calculate_cattery_runtime' or 'calculate_cable_loss', nor does it specify prerequisites or contexts where this calculation is appropriate versus other loss calculations.

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 of behavioral disclosure. It mentions calculating wavelength and optional antenna wire lengths, but doesn't describe what the tool returns (e.g., wavelength value, units), whether it's a pure calculation or has side effects, or any constraints like rate limits. For a calculation tool with zero annotation coverage, this leaves significant gaps in understanding its 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 a single, efficient sentence in German that directly states the tool's purpose. It's appropriately sized and front-loaded with the core functionality. However, it could be slightly more structured by separating the main calculation from the optional antenna context.

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

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

Given the tool's complexity (a calculation with three parameters) and lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., wavelength in meters), how the optional parameters affect the result, or any error conditions. For a calculation tool without output schema, this leaves the agent guessing about the result format.

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

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

Schema description coverage is 100%, so the schema fully documents all three parameters (unit, frequency, velocity_factor). The description adds minimal value beyond the schema: it mentions 'optional Drahtlängen für Antennen' (optional wire lengths for antennas), which loosely relates to velocity_factor but doesn't provide additional semantic context. With high schema coverage, the baseline score of 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Berechnet die Wellenlänge für eine gegebene Frequenz' (calculates wavelength for a given frequency). It specifies the verb (calculates) and resource (wavelength) with the required input (frequency). However, it doesn't explicitly differentiate from sibling tools like 'check_frequency' or 'list_all_bands' beyond mentioning optional antenna wire lengths.

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 minimal usage guidance. It mentions optional wire lengths for antennas, suggesting some context for antenna calculations, but doesn't specify when to use this tool versus alternatives like 'check_frequency' or 'get_band_plan'. No explicit when/when-not instructions or prerequisite information is provided.

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

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

No annotations are provided, so the description carries full burden. It mentions checking availability and showing state-level status, but doesn't disclose behavioral traits like whether this is a read-only operation, if it requires authentication, rate limits, or what the output format looks like. For a tool with no annotations, this leaves critical gaps.

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 in two sentences. The first sentence states the core function, and the second adds important detail about federal state results. There's no wasted language, though it could be slightly more front-loaded with the most critical 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 annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., format of the state availability results), error conditions, or behavioral constraints. For a tool that presumably queries a database and returns structured results, this leaves too much unspecified.

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

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

Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema (e.g., it doesn't explain the relationship between suffix and district parameters). Baseline 3 is appropriate when the schema does the heavy lifting.

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: checking suffix availability in Austria and showing which federal states have it free or occupied. It uses specific verbs ('prüft', 'zeigt') and identifies the resource (suffix). However, it doesn't explicitly differentiate from sibling tools like callsign_lookup or callsign_validate, which likely serve different purposes.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or exclusions. With sibling tools like callsign_lookup and callsign_validate available, the lack of comparative guidance is a significant gap.

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 of behavioral disclosure. It states the tool shows database information, implying a read-only operation, but doesn't specify if it requires authentication, has rate limits, or what format the statistics are returned in. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior and constraints.

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

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

The description is a single, efficient sentence in German that directly states the tool's function without any fluff. It is appropriately sized and front-loaded, with every word contributing to understanding what the tool does. No waste or redundancy is present.

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 0 parameters, no annotations, and no output schema, the description is minimally adequate. It explains the purpose but lacks details on behavioral traits, output format, or usage context. For a simple read operation, this might suffice, but it doesn't provide enough information for an agent to fully anticipate results or handle errors.

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

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

The tool has 0 parameters, and the input schema has 100% description coverage (though empty). The description doesn't need to add parameter details, so it naturally compensates by focusing on the tool's purpose. Baseline is 4 for zero parameters, as there's no schema burden to address.

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 what the tool does: 'Zeigt Informationen über die Rufzeichen-Datenbank (Version, Anzahl Einträge, Statistiken)' translates to 'Shows information about the callsign database (version, number of entries, statistics).' This specifies the verb ('shows information') and resource ('callsign database') with concrete examples of what information is provided. It distinguishes from siblings like 'callsign_lookup' or 'callsign_validate' by focusing on database metadata rather than individual callsign operations.

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 no guidance on when to use this tool versus alternatives. It does not mention prerequisites, context, or exclusions. For example, it doesn't clarify if this should be used before other callsign tools to check database status or if it's for administrative purposes only. With siblings like 'callsign_lookup' and 'callsign_available', explicit differentiation would be helpful.

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 the data sources (fb.gv.at, QRZ.com, HamQTH) which is valuable context about reliability and coverage. However, it doesn't mention rate limits, authentication requirements, error conditions, or what specific information is returned beyond 'Inhaberinformationen.' For a lookup tool with no annotations, this leaves behavioral gaps.

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 concise sentences that efficiently convey purpose, scope, and data sources without redundancy. Every word earns its place, and the information is front-loaded with the core functionality stated first.

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 adequately covers the basic purpose and data sources but lacks details on return values, error handling, or operational constraints. For a lookup tool with 2 parameters and no structured output documentation, this is minimally viable but leaves gaps in understanding full behavior.

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

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

Schema description coverage is 100%, so the schema fully documents both parameters. The description doesn't add parameter-specific details beyond what's in the schema, but it provides overall context that the tool searches Austrian callsigns. With high schema coverage, the baseline is 3, but the description's clarity about the tool's purpose slightly enhances parameter understanding, warranting a 4.

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 specific action ('Sucht' - searches), resource ('österreichisches Amateurfunkrufzeichen' - Austrian amateur radio callsign), and outcome ('gibt Inhaberinformationen zurück' - returns holder information). It distinguishes from sibling tools like callsign_available, callsign_validate, and callsign_suggest by focusing on lookup and information retrieval rather than availability checking, validation, or suggestion generation.

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

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

The description provides clear context for when to use this tool: for looking up Austrian amateur radio callsigns to get holder information. It mentions primary and fallback data sources, which helps understand reliability. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools, though the different purposes of sibling tools are implied.

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 of behavioral disclosure. It mentions that suggestions consider availability, phonetics, and CW-friendliness, which adds some context about how suggestions are generated. However, it does not disclose critical behavioral traits such as whether this is a read-only operation, potential rate limits, authentication needs, or what the output format looks like (e.g., list of suggestions with scores).

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, efficient sentence in German that directly states the tool's function and key considerations. It is front-loaded with the main purpose and includes no redundant information, making it appropriately sized 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 the complexity of a suggestion-generation tool with 5 parameters and no output schema, the description is moderately complete. It covers the purpose and some behavioral aspects (availability, phonetics, CW-friendliness), but lacks details on output format, error handling, or performance characteristics. Without annotations or an output schema, more context would be beneficial for an AI 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?

Schema description coverage is 100%, so the schema already documents all 5 parameters thoroughly. The description adds no additional parameter semantics beyond what the schema provides, such as explaining how 'name' influences suggestions or what 'phonetic score' means in practice. Baseline 3 is appropriate when the schema does the heavy lifting.

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: generating callsign suggestions based on name and preferences. It specifies the verb 'generates' and the resource 'callsign suggestions', and distinguishes from siblings like callsign_available, callsign_lookup, and callsign_validate by focusing on suggestion generation rather than availability checking, lookup, or validation.

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 usage context through 'based on names and preferences' and mentions criteria like availability, phonetics, and CW-friendliness, which guide when to use it. However, it lacks explicit guidance on when to choose this tool over alternatives like callsign_available or callsign_validate, and does not specify exclusions or prerequisites.

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 of behavioral disclosure. It states what the tool checks (format, district, suffix length) but doesn't describe the output (e.g., returns a boolean or detailed validation result), error handling, rate limits, or authentication needs. For a validation tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves.

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, efficient sentence in German that front-loads the purpose ('Validiert ein Rufzeichen gegen österreichische Regeln') and adds specifics ('Prüft Format, Bezirk und Suffix-Länge'). There is no wasted text, and it's appropriately sized for a simple validation tool.

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 low complexity (1 parameter, no nested objects, no output schema) and high schema coverage, the description is adequate but incomplete. It covers the purpose and validation aspects but lacks output details, error information, and usage context. Without annotations or output schema, the agent might struggle to interpret results, making this minimally viable but with clear gaps.

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

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

The schema description coverage is 100%, with the single parameter 'callsign' documented as 'Zu validierendes Rufzeichen' (callsign to validate). The description adds context by specifying the validation rules (Austrian rules, checking format, district, suffix length), which provides meaning beyond the schema. However, it doesn't detail parameter constraints (e.g., format examples) or syntax, so it meets the baseline for high 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 the tool's purpose: 'Validiert ein Rufzeichen gegen österreichische Regeln' (validates a callsign against Austrian rules). It specifies the verb 'validates' and the resource 'callsign', and mentions the aspects checked: format, district, and suffix length. However, it doesn't explicitly differentiate from sibling tools like 'callsign_available' or 'callsign_lookup', which likely serve different purposes (availability checking vs. validation).

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 no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools (e.g., 'callsign_available' for availability checks or 'callsign_lookup' for database queries) or specify contexts where validation is needed (e.g., before registration). Usage is implied by the purpose but lacks explicit when/when-not instructions or prerequisites.

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 of behavioral disclosure. While it states what the tool does (checks frequency permission and returns the band), it doesn't describe important behavioral aspects like error handling, what happens with invalid frequencies, whether this is a read-only operation, or any rate limits or authentication requirements. The description is functional but lacks operational context.

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

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

The description is a single, efficient sentence in German that communicates the core functionality without any wasted words. It's appropriately sized for a straightforward tool and front-loads the essential information about what the tool does and what it returns.

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 tool with no annotations and no output schema, the description is minimally adequate. It explains what the tool does but lacks important contextual information about the return format, error conditions, or operational constraints. Given the tool's relative simplicity (2 parameters, no nested objects), the description meets basic requirements but could be more complete about behavioral aspects.

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 100% schema description coverage, the schema already documents both parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. It doesn't explain the relationship between frequency and unit parameters or provide context about typical frequency ranges for amateur radio. The baseline score of 3 is appropriate when the schema does all the parameter documentation work.

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 with a specific verb ('Prüft' - checks) and resource ('Frequenz im Amateurfunk' - frequency in amateur radio), and it distinguishes from siblings by focusing on frequency validation rather than calculations, conversions, or callsign operations. The description explicitly mentions returning the associated band, which is unique among the sibling tools.

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

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

The description provides no guidance on when to use this tool versus alternatives. While it's clear this is for checking amateur radio frequency permissions, there's no mention of when not to use it, what prerequisites might be needed, or how it relates to similar tools like 'get_band_plan' or 'list_all_bands' that might provide related information.

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 of behavioral disclosure. It states the tool compares cable types but doesn't describe what 'compares' entails—whether it returns performance metrics, cost comparisons, availability, or other attributes. It also doesn't mention any side effects, rate limits, or authentication requirements, leaving significant gaps for a tool with no annotation coverage.

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, efficient sentence in German that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to understand quickly.

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 comparing cable types (which could involve multiple attributes like loss, impedance, cost), no annotations, and no output schema, the description is incomplete. It doesn't explain what the comparison outputs (e.g., a table, rankings, detailed specs) or how results are structured, leaving the agent with insufficient information 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?

The description adds minimal meaning beyond the input schema. It mentions frequency and length as key inputs, which aligns with the schema's parameters (frequency_mhz, length_meters). However, with 100% schema description coverage, the schema already documents these parameters well, so the description doesn't provide additional syntax, format, or contextual details. This meets the baseline for high 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 the tool's purpose: 'Vergleicht alle verfügbaren Kabeltypen bei einer bestimmten Frequenz und Länge' (Compares all available cable types at a specific frequency and length). It specifies the verb (compare), resource (cable types), and key constraints (frequency and length). However, it doesn't explicitly distinguish this tool from potential siblings like 'calculate_cable_loss', which might perform related calculations.

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 no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, exclusions, or comparisons to sibling tools like 'calculate_cable_loss' or 'list_all_bands'. The user must infer usage from the purpose alone.

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 of behavioral disclosure. While it states the conversion function, it doesn't describe what the tool returns (output format), whether it handles edge cases like negative values, precision, or error conditions. For a tool with no annotation coverage, this leaves significant behavioral gaps.

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, efficient sentence in German that directly states the tool's function without any fluff. It's appropriately sized for a simple conversion tool and front-loads the core purpose immediately.

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 conversion tool with 2 parameters and 100% schema coverage, the description is minimally adequate. However, with no output schema and no annotations, it should ideally mention the output format or result structure. The description covers the basic purpose but leaves behavioral aspects undefined.

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

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

Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema (value as power value, from_unit as source unit with enum). Baseline 3 is appropriate when the schema does the heavy lifting.

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: converting power values between specific units (Watt, dBm, dBW). It uses a specific verb ('umrechnet' - converts) and identifies the resource (power values/units). However, it doesn't explicitly differentiate from sibling tools like 'calculate_eirp' or 'calculate_cable_loss' which might involve power calculations but serve different purposes.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'calculate_eirp' (which might involve power conversions in a specific context) or clarify scenarios where this unit converter is appropriate versus other calculation tools. No usage context or exclusions are provided.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns typical gain values, implying a read-only operation, but doesn't specify if it's a lookup, calculation, or estimation, nor does it mention any constraints like rate limits, data sources, or error handling. For a tool with no annotations, this leaves significant behavioral gaps.

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, efficient sentence in German that directly states the tool's function without unnecessary words. It's front-loaded with the core purpose and avoids redundancy, making it highly concise and well-structured for its 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 the tool's low complexity (1 parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on behavior, usage context, and output format. For a simple lookup tool, this might suffice, but it doesn't provide enough context for optimal agent decision-making without additional 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?

The input schema has 1 parameter with 100% description coverage ('Antennentyp (z.B. 'dipol', 'yagi-5el') oder leer für alle'). The description adds minimal value beyond this, as it only implies the parameter relates to 'verschiedene Antennentypen' (different antenna types) without detailing semantics like format or examples. With high schema coverage, the baseline score of 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Gibt typische Gewinnwerte für verschiedene Antennentypen zurück' (Returns typical gain values for different antenna types). It specifies the verb 'returns' and resource 'gain values for antenna types', making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'calculate_eirp' or 'compare_cables', which might also involve antenna-related calculations.

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 no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, exclusions, or specific contexts for usage. Given sibling tools like 'calculate_eirp' (which might involve gain calculations) and 'list_all_bands' (which could relate to antenna bands), the lack of differentiation leaves the agent without clear usage instructions.

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

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

No annotations are provided, so the description carries full burden. While it states what information is returned, it doesn't disclose behavioral traits like whether this is a read-only operation (implied but not stated), whether it requires authentication, rate limits, error conditions, or response format. For a tool with no annotation coverage, this is a significant gap.

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, efficient sentence that front-loads all essential information: what it returns, for what resource, and the geographical scope. Every word earns its place with zero wasted content.

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 (single parameter lookup), 100% schema coverage, but no output schema and no annotations, the description is adequate but incomplete. It explains what information is returned but not the format or structure of that information. For a tool with no output schema, more detail about return values would be helpful.

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

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

Schema description coverage is 100% with the single parameter 'band' well-documented in the schema. The description doesn't add any parameter-specific information beyond what's in the schema. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't need to.

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 with specific verbs ('gibt... zurück' meaning 'returns') and resources ('Frequenzgrenzen, erlaubte Modes und maximale Sendeleistung' meaning 'frequency limits, allowed modes and maximum transmit power'). It distinguishes from siblings by specifying it's for amateur radio bands in IARU Region 1/Austria, unlike general calculation or lookup tools in the sibling list.

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

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

The description provides clear context for when to use this tool: when needing regulatory information for amateur radio bands in a specific region. However, it doesn't explicitly state when not to use it or name alternatives (like 'list_all_bands' which might provide different information).

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 of behavioral disclosure. While 'listet auf' suggests a read-only operation, the description doesn't specify whether this requires authentication, what format the output takes, whether results are paginated, or any rate limits. For a tool with zero annotation coverage, this leaves significant behavioral questions unanswered.

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, efficient German sentence that communicates the core purpose without unnecessary words. It's appropriately sized for a simple listing tool and front-loads the essential information.

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

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

For a zero-parameter listing tool without annotations or output schema, the description adequately communicates what the tool does. However, it doesn't provide enough context about the output format or behavioral characteristics that would be helpful for an AI agent to use it effectively. The lack of output schema means the description should ideally hint at what 'Grundinformationen' includes.

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

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

The tool has zero parameters (schema coverage 100%), so there are no parameters to document. The description appropriately doesn't attempt to explain nonexistent parameters, earning a baseline score of 4 for not creating confusion where none exists.

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

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

The description clearly states the verb ('listet auf' - lists) and resource ('alle verfügbaren Amateurfunkbänder' - all available amateur radio bands) with additional detail about what information is included ('mit Grundinformationen' - with basic information). It doesn't explicitly differentiate from sibling tools like 'get_band_plan', but the purpose is specific and clear.

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 no guidance on when to use this tool versus alternatives like 'get_band_plan' or other sibling tools. There's no mention of prerequisites, context for usage, or comparison with similar functionality available in the toolset.

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 of behavioral disclosure. It states that the tool lists tools with URLs and descriptions, implying a read-only operation, but does not disclose any behavioral traits such as rate limits, authentication needs, pagination, or error handling. For a tool with zero annotation coverage, this is a significant gap in transparency.

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

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

The description is a single, efficient sentence in German that directly states the tool's purpose without unnecessary words. It is front-loaded with the main action and resource, making it easy to understand quickly. Every part of the sentence earns its place.

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

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

Given the tool's low complexity (one optional parameter, no output schema, no annotations), the description is somewhat complete but lacks depth. It explains what the tool does but does not cover behavioral aspects or usage guidelines. Without an output schema, it hints at return values ('URLs und Beschreibungen'), but more detail could be helpful for an agent to understand the full context.

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

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

The input schema has 100% description coverage, with one parameter 'category' fully documented in the schema. The description does not add any meaning beyond the schema, as it does not mention parameters at all. According to the rules, with high schema coverage (>80%), the baseline score is 3, which is appropriate here.

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

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

The description clearly states the tool's purpose: 'Listet alle verfügbaren OERadio.at Amateurfunk-Werkzeuge mit URLs und Beschreibungen' (Lists all available OERadio.at amateur radio tools with URLs and descriptions). It specifies the verb ('Listet'), resource ('OERadio.at Amateurfunk-Werkzeuge'), and output details ('URLs und Beschreibungen'). However, it does not explicitly differentiate from sibling tools like 'list_all_bands', which might list bands rather than tools, leaving some ambiguity.

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 no guidance on when to use this tool versus alternatives. It does not mention sibling tools such as 'list_all_bands' or other list-like tools, nor does it specify prerequisites or contexts for usage. The agent must infer usage based on the tool name and description alone.

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