Skip to main content
Glama

radar_ambiguity

Compute pulse-Doppler radar ambiguity limits and validate claimed range/velocity values against physical bounds, including blind speeds, aliasing, resolution, and the range-Doppler dilemma.

Instructions

Calculate pulse-Doppler radar ambiguity limits and validate range/velocity claims.

Computes the maximum unambiguous range R_ua = c / (2 * PRF), the first blind speed lambda * PRF / 2, the unambiguous velocity v_ua = +/- lambda * PRF / 4 (Doppler within +/- PRF/2), the Doppler shift f_d = 2 * v_r / lambda of a target (closing velocity positive) and whether it aliases, and — when a pulse width is given — the duty cycle, eclipsing minimum range c * tau / 2 and the range resolution c * tau / 2 (or c / (2 B) when a compressed bandwidth is supplied). Reports the range-Doppler dilemma invariant R_ua * v_ua = c * lambda / 8, which no choice of PRF can beat (Skolnik, Introduction to Radar Systems, Ch. 2-3; Richards, Fundamentals of Radar Signal Processing, Ch. 1, 3, 5).

Use this tool when you need to:

  • Find the unambiguous range and velocity coverage of a given PRF

  • Check whether a claimed unambiguous range or velocity is possible at that PRF

  • Check whether a claimed range resolution is possible for the pulse/bandwidth

  • Determine whether a target's Doppler will alias or fall at a blind speed

  • Expose claims that silently violate the range-Doppler dilemma

Returns both human-readable summary and machine-readable JSON with all intermediate values. Returns a PhysicalViolationError dict if any input violates physics (PRF <= 0, tau <= 0, duty cycle >= 1) or a claim exceeds its limit.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
prf_hzYesPulse repetition frequency in Hz (must be > 0)
bandwidth_hzNoOptional compressed bandwidth in Hz; sets the resolution limit to c/(2B)
frequency_hzYesCarrier frequency in Hz (must be > 0)
pulse_width_sNoOptional transmitted pulse width tau in seconds (must be > 0)
target_velocity_m_sNoOptional target radial velocity in m/s (closing positive)
claimed_range_resolution_mNoOptional claimed range resolution to validate (m)
claimed_unambiguous_range_mNoOptional claimed unambiguous range to validate (m)
claimed_unambiguous_velocity_m_sNoOptional claimed unambiguous velocity to validate (m/s)

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.2.1

TDQS

A4.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.