Server Quality Checklist

Tool Scores

• radar_ambiguityA
  4.4/5.0
  Behavior4/5

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

  No annotations are present, so the description carries the full burden. It discloses the computation formulas, the sign convention for closing velocity, the output format (human-readable summary plus JSON), and the PhysicalViolationError behavior for invalid physics or exceeded claims. This is transparent for a pure calculation tool, though it could have been even more explicit about being side-effect-free.

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

  Conciseness4/5

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

  The description is well organized: a one-line purpose, a dense but relevant formula block, a bulleted usage list, and a final output/error note. Textbook references are slightly extraneous for an agent deciding whether to call the tool, but they do not bloat the description significantly.

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

  Completeness5/5

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

  Given 8 parameters, no annotations, and no visible output schema content in this definition, the description is remarkably complete. It covers all input semantics, physical validity constraints, claim validation behavior, and return conventions. The only optional improvement would be naming sibling alternatives for exclusion, but that is not required for completeness here.

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

  Parameters4/5

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

  Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining how pulse_width drives duty cycle, eclipsing range, and resolution; how bandwidth_hz overrides resolution; that target_velocity_m_s is closing-positive; and that the three claimed_* parameters are validation checks against computed limits.

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

  Purpose5/5

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

  The description opens with a specific verb and resource: 'Calculate pulse-Doppler radar ambiguity limits and validate range/velocity claims.' It then names the exact quantities computed, including unambiguous range, blind speed, Doppler aliasing, and the range-Doppler dilemma, which clearly distinguishes it from sibling tools like radar_range or rf_link_budget.

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

  Usage Guidelines4/5

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

  Provides an explicit 'Use this tool when you need to' list covering five concrete scenarios, such as finding unambiguous range/velocity coverage and validating claims. However, it does not explicitly state when not to use it or name sibling alternatives for contrast, so it stops short of full differentiation.

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

• shannon_hartleyA
  4.4/5.0
  Behavior5/5

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

  With no annotations, the description carries the full burden and meets it: it discloses the mathematical model, the validation behavior, the judgment that exceeding the Shannon limit is physically impossible, and the PhysicalViolationError dict returned in that case. This is strong behavioral disclosure for a pure calculation tool.

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

  Conciseness5/5

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

  The description is well-structured and front-loaded with the core purpose and formula. The use-case list is compact and each line adds distinct value, and the error behavior is stated efficiently. No filler.

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

  Completeness4/5

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

  For a calculation tool with full schema coverage and an output schema, the description is nearly complete. It covers calculation, validation, use cases, and error behavior. Minor gap: the formula writes 'SNR' without explicitly clarifying that it must be linear, though the schema's snr_linear parameter mitigates this.

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

  Parameters3/5

  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. The description references bandwidth, SNR, and claimed throughput, but adds little semantic detail beyond the schema. Baseline 3 is appropriate.

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

  Purpose5/5

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

  The description names a specific verb and resource: 'Calculate Shannon-Hartley channel capacity and validate throughput claims', and includes the governing formula. This clearly distinguishes the tool from sibling RF tools like rf_link_budget or noise_floor.

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

  Usage Guidelines4/5

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

  The description provides explicit use cases ('Use this tool when you need to:') covering calculation, validation, spectral efficiency limits, and plausibility checks. It lacks explicit exclusions or references to sibling tools, but the context is clear enough for an agent to select it appropriately.

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

• noise_floorA
  4.7/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full burden and delivers: it reveals the exact formulas, the crucial semantic that T_0 = 290 K is the noise-figure reference independent of temperature_k, and that a PhysicalViolationError dict is returned on thermodynamic violations. These are exactly the behavioral subtleties an agent could not infer from the schema alone.

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

  Conciseness4/5

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

  Front-loaded single-sentence summary followed by formulas, a bulleted use-case list, and an error-behavior note. Slightly verbose — T_0 = 290 K is introduced twice and the formula block is dense — but each section earns its place and the structure aids scanning.

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

  Completeness5/5

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

  For a four-parameter, three-computation tool with subtle reference-temperature semantics, zero annotations, and a loose stage-object schema, the description covers the physics, parameter roles, routing criteria, and error behavior. An output schema exists so return-value format needn't be repeated; nothing an agent needs to invoke this correctly is missing.

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

  Parameters5/5

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

  Schema coverage is 100%, so baseline is 3, but the description exceeds it by tying each parameter into its formula: bandwidth_hz is B in k_B*T*B, required_snr_db appears in the S_min expression, and the Friis formula defines how stages' gain_db and noise_figure_db are consumed. Most valuably, it clarifies that temperature_k is the source temperature T_A, not the noise-figure reference temperature.

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

  Purpose5/5

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

  First sentence names a specific verb (Calculate) and three concrete outputs: thermal noise power (kTB), cascaded noise figure, and receiver sensitivity. The subject matter — thermal noise, Friis cascading, sensitivity — is clearly distinct from siblings like rf_link_budget, shannon_hartley, and radar_range, so an agent can route correctly by topic alone.

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

  Usage Guidelines4/5

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

  Includes an explicit 'Use this tool when you need to' bulleted list with four concrete use cases, including a diagnostic one (validate that a claimed noise figure is physically plausible). It does not name sibling alternatives or give when-not-to-use conditions, so it stops short of the top bar but is well above vague context.

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

• radar_rangeA
  4.7/5.0
  Behavior5/5

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

  With no annotations present, the description carries the full burden and succeeds: it discloses the monostatic same-antenna assumption, the fourth-root relationship, return formats (human-readable plus machine-readable JSON), and the PhysicalViolationError dict behavior on invalid physics or exceeded ranges. This is far more behavioral detail than is typical.

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

  Conciseness5/5

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

  The description is front-loaded with the purpose and formula, followed by a compact bulleted use-case list and a brief return/error summary. It is moderately long but every segment earns its place, and there is no filler.

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

  Completeness5/5

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

  For a 10-parameter physics-heavy tool with a nullable validation input, the description supplies the equation, assumptions, use cases, return behavior, and error handling. Since an output schema exists, it correctly avoids over-explaining return fields, leaving no major gap for correct invocation.

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

  Parameters4/5

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

  Input schema covers all 10 parameters at 100%, so the baseline is 3. The description adds value by showing how parameters combine in the governing equation and explicitly linking claimed_range_m to the validation behavior, plus explaining integration gain and Swerling I defaults. Most individual parameter semantics remain in the schema, but the equation adds meaningful physical context.

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

  Purpose5/5

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

  The opening sentence states a specific action and resource: 'Calculate maximum monostatic radar detection range and validate range claims.' It also differentiates the tool from siblings by anchoring it to the radar range equation and fourth-root fallacy, making its scope unmistakable.

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

  Usage Guidelines4/5

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

  The description provides an explicit 'Use this tool when you need to' list with concrete scenarios such as validating claimed ranges and checking R^4 path loss. However, it does not explicitly mention sibling tools like rf_link_budget or state when not to use this tool, so it falls just short of full routing guidance.

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

• rf_link_budgetA
  4.7/5.0
  Behavior5/5

  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 explains the mathematical model, the hard gain limit, the warning threshold, rejection of negative losses, acceptance/rejection behavior, and the return of a PhysicalViolationError dict. This is exceptional transparency for a physics-validating tool.

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

  Conciseness5/5

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

  The description is front-loaded with a one-line summary, follows with the necessary physics and validation rules, then gives usage bullets and output behavior. Though long, it is dense with information and every part earns its place given the tool's mathematical complexity.

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

  Completeness5/5

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

  Given 10 parameters, no annotations, and an output schema, the description still provides the full operational picture: inputs, physical constraints, validation logic, return format, and error behavior. An agent has enough information to decide when to call it and what to expect.

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

  Parameters4/5

  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 meaningful semantics beyond the schema by explaining the aperture efficiency threshold, the physical gain bound formula, and how antenna diameter parameters enable gain validation. It does not describe every parameter, but the schema already covers those descriptions.

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

  Purpose5/5

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

  The description opens with a specific verb and resource: 'Calculate a complete RF link budget using the Friis transmission equation.' It then enumerates concrete outputs (FSPL, received power, gain validation), which clearly distinguishes it from siblings like shannon_hartley, noise_floor, and antenna_gain.

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

  Usage Guidelines4/5

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

  The 'Use this tool when you need to' list provides four clear scenarios for when to invoke the tool, such as estimating received signal strength and validating physical achievability. It does not explicitly state when not to use it or name alternative tools, but the context is clear enough for an agent to route correctly.

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

• antenna_gainA
  4.8/5.0
  Behavior5/5

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

  With no annotations, the description carries the full burden, and it delivers: it explains the computational model, aperture-efficiency assumption, Harrington bound, hard gain limit, limiting_bound selection logic, validation behavior for claimed gain, warning thresholds, and the PhysicalViolationError return for invalid inputs. This gives the agent a detailed behavioral model without needing annotations.

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

  Conciseness5/5

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

  The description is long, but every sentence earns its place for a calculation-heavy tool. It front-loads the core purpose, then supplies formulas, defaults, boundary behavior, and use cases in a logical structure. The density is justified by the tool's complexity and the absence of annotations.

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

  Completeness5/5

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

  Given the tool's complexity, no annotations, and an existing output schema, the description is complete: all inputs are explained, the key computed outputs are enumerated, validation and error behavior are disclosed, and use cases are specified. Nothing an agent needs to decide whether to call this tool and understand its behavior is missing.

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

  Parameters5/5

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

  Even though schema coverage is 100%, the description adds substantial meaning beyond the schema: the diameter-area equivalence via D = sqrt(4A/pi), the default efficiency context (0.55 for parabolic dish), the meaning of claimed_gain_dbi validation, and the physical constraints. This is far more than a restatement of parameter names or types.

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

  Purpose5/5

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

  The description opens with a specific verb and resource: 'Calculate antenna aperture gain limits, beamwidth, far-field distance; validate gain claims.' It clearly names the domain and outputs, and the use-case list differentiates it from RF link budget, Shannon-Hartley, noise floor, and radar tools. An agent can immediately tell what this tool does and why it is distinct.

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

  Usage Guidelines4/5

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

  The 'Use this tool when you need to' list gives explicit scenarios: checking quoted gain consistency, estimating dish parameters, finding far-field range, and sizing an antenna for required gain. It provides clear usage context, though it does not explicitly name sibling tools or state when not to use them. Therefore it earns a 4 rather than a 5.

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