Berechnet EIRP (Equivalent Isotropically Radiated Power) aus Sendeleistung, Kabelverlust und Antennengewinn. Nützlich für Sicherheitsabstands-Berechnungen nach ÖNORM.
| Name | Required | Description | Default |
|---|---|---|---|
| power_watts | Yes | Sendeleistung in Watt | |
| cable_loss_db | Yes | Kabelverlust in dB | |
| antenna_gain_dbi | Yes | Antennengewinn in dBi |
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. The description indicates a pure calculation with no side effects, but does not explicitly state that it is read-only, non-destructive, or that it returns a numeric result in a specific unit (e.g., watts). For a simple calculator, this is acceptable but not fully transparent about output format or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose immediately. Every word serves a function: the first sentence states the calculation, the second gives a use case. No redundancy or 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?
Given the absence of an output schema and annotations, the description should explain the return value and any relevant details. It mentions the use case (ÖNORM safety distance) but does not specify the output unit or format (e.g., result in watts or dBW). The tool is simple, but the description is somewhat incomplete for an agent that needs to know what to expect from the response.
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 baseline is 3. The description adds minimal value by naming the parameters in natural language ('Sendeleistung, Kabelverlust und Antennengewinn'), but the schema already provides full descriptions for each parameter. The description does not add additional semantics beyond what the schema offers.
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 function: 'Berechnet EIRP (Equivalent Isotropically Radiated Power) aus Sendeleistung, Kabelverlust und Antennengewinn.' This specifies the verb (calculate), the resource (EIRP), and the inputs, distinguishing it from sibling calculation tools like calculate_cable_loss 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 context for when to use the tool: 'Nützlich für Sicherheitsabstands-Berechnungen nach ÖNORM.' This implies the tool is appropriate for safety distance calculations, but does not explicitly exclude alternatives or name sibling tools. Clear use-case context is given, but no exclusions or alternative recommendations are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct operation: calculations for different physical quantities, separate callsign functions for lookup, validation, suggestion, and availability, and band plan queries. No two tools appear to perform the same action, making selection unambiguous.
Most tools follow a verb_noun convention (calculate_, check_, list_), but the callsign_* group consistently places the noun first (callsign_lookup, callsign_validate). This split is readable but represents a mixed convention that slightly reduces predictability.
With 17 tools, the server is above the ideal 3-15 range and falls into the borderline 'feels heavy' category. While every tool has a distinct purpose, the number may be slightly unwieldy for quick selection.
The toolkit covers a broad range of amateur radio calculations (battery, cable, EIRP, wavelength, SWR, power) and callsign operations (lookup, validate, suggest, availability, database info). Some advanced features like propagation prediction are absent, but the core domain is well covered without critical gaps.
