PhysBound is an MCP server that validates RF and physics calculations against hard physical limits, catching AI hallucinations in engineering workflows.
RF link budgets: Compute FSPL and received power via the Friis equation, and validate antenna gains against aperture/Harrington limits.
Shannon-Hartley capacity: Calculate the maximum channel capacity and validate whether a claimed throughput is physically possible.
Noise floor and sensitivity: Compute thermal noise (kTB), cascade noise figures with the Friis formula, and determine receiver sensitivity.
Radar range: Calculate maximum monostatic detection range and validate range claims, including the fourth-root power/range relationship.
Antenna analysis: Determine gain limits, beamwidth, far-field distance, and implied aperture efficiency for a single antenna.
Radar ambiguity: Compute unambiguous range and velocity, Doppler aliasing, and the range-Doppler dilemma invariant.
Violations return structured PhysicalViolationError responses with the violated law, computed limit, and LaTeX explanation.
Generates structured physical violation errors with LaTeX-formatted explanations to provide clear, mathematically rigorous reasoning for rejected calculations.
LLMs generate plausible-sounding RF numbers that violate fundamental physics — throughput above the Shannon limit, antenna gains no aperture can produce, radar ranges the range equation forbids. PhysBound gives any MCP-compatible AI assistant six validated calculation tools, backed by CODATA constants (via SciPy) and dimensional analysis (via Pint). Impossible claims return structured PhysicalViolationError responses with the violated law, the computed limit, and a LaTeX explanation — not silent failures.
Tool | What it validates |
Friis link budgets: FSPL, received power, antenna gains vs. aperture/Harrington limits | |
Throughput claims against channel capacity | |
Thermal noise | |
Detection-range claims against the monostatic radar range equation | |
Gain limits, beamwidth, and far-field distance for a single antenna | |
Pulse-Doppler unambiguous range/velocity, Doppler aliasing, range resolution |
PhysBound is a standard stdio MCP server published on PyPI. The recommended launch command is uvx physbound, which fetches and runs the latest release in an isolated environment — no manual install step.
First run:
uvxdownloads ~60 MB of dependencies (SciPy, NumPy) the first time. Runuvx physboundonce in a terminal to pre-cache them (Ctrl-C to exit); subsequent starts are instant.
claude mcp add physbound -- uvx physboundAdd to claude_desktop_config.json (macOS: ~/Library/Application Support/Claude/, Windows: %APPDATA%\Claude\):
{
"mcpServers": {
"physbound": {
"command": "uvx",
"args": ["physbound"]
}
}
}Use the same JSON server entry as above in your client's MCP configuration file (Cursor: ~/.cursor/mcp.json; Windsurf: ~/.codeium/windsurf/mcp_config.json).
If you prefer a plain Python install (requires Python 3.12+):
pip install physboundthen set "command": "physbound" (with no args) in the client configuration.
Once configured, ask your assistant an RF question — "Can a 20 MHz channel with 15 dB SNR support 500 Mbps?" — and it will answer with physics-validated numbers.
Related MCP server: bluemouse
The same validators are available directly from the terminal — useful in scripts and CI pipelines, since a physics violation exits with code 1:
$ physbound check shannon --bandwidth-hz 20e6 --snr-db 15 --claimed-throughput-bps 500e6
PHYSICS VIOLATION [Shannon-Hartley Theorem]
Claimed throughput 500000000.0 bps exceeds Shannon limit of 100556153.5 bps by 397.2%
Computed limit: 1.00556e+08 bps
Claimed value: 5e+08 bps
$ echo $?
1$ physbound check shannon --bandwidth-hz 20e6 --snr-db 15 --claimed-throughput-bps 100e6
Shannon-Hartley Capacity: ... # exit code 0Available subcommands: check {link-budget, shannon, noise, radar-range, antenna, radar-ambiguity} (flags mirror the MCP tool parameters; add --json for the full structured result) and serve --transport {stdio,http} for running the MCP server over HTTP. See physbound check --help for details.
Sixteen real hallucination patterns, each caught by PhysBound's test suite:
# | Category | LLM Hallucination | PhysBound Truth | Verdict |
1 | Shannon-Hartley | A 20 MHz 802.11n channel with 15 dB SNR can achieve 500 Mbps | Shannon limit: 100.6 Mbps (not 500 Mbps) | CAUGHT |
2 | Shannon-Hartley | A 100 MHz 5G channel with 20 dB SNR delivers 2 Gbps | Shannon limit: 665.8 Mbps (not 2000 Mbps) | CAUGHT |
3 | Antenna Aperture | A 30 cm dish antenna at 1 GHz provides 45 dBi gain | Physical limit: 12.1 dBi (Harrington); aperture eta=1: 9.9 dBi; typical dish: 7.4 dBi (eta=0.55) (not 45 dBi) | CAUGHT |
4 | Thermal Noise | Receiver noise floor of -180 dBm/Hz at room temperature | Thermal noise floor: -174.0 dBm/Hz at 290K (not -180 dBm/Hz) | CAUGHT |
5 | Link Budget / FSPL | Wi-Fi at 2.4 GHz with 20 dBm TX reaches 10 km with -40 dBm RX power | Actual RX power at 10 km: -94.1 dBm (not -40 dBm) | CAUGHT |
6 | Link Budget / FSPL | A 1W transmitter at 12 GHz with 0 dBi antennas reaches GEO at -80 dBm | Actual RX power at GEO: -175.1 dBm (not -80 dBm) | CAUGHT |
7 | Link Budget / FSPL | Bluetooth at 2.4 GHz with 0 dBm TX and 0 dBi antennas reaches 1 km at -60 dBm | Actual RX power at 1 km: -100.1 dBm (not -60 dBm) | CAUGHT |
8 | Shannon-Hartley | A 10 MHz LTE channel at 10 dB SNR supports 1 Gbps | Shannon limit: 34.6 Mbps (not 1000 Mbps) | CAUGHT |
9 | Noise Cascade | Receiver NF is the same regardless of stage order: LNA(20dB/1.5dB) + Mixer(10dB/8dB) | LNA first: 1.66 dB vs mixer first: 8.03 dB (penalty: 6.4 dB) | CAUGHT |
10 | Antenna Aperture | A 10 cm patch antenna at 900 MHz provides 20 dBi gain | Physical limit: 4.4 dBi (Harrington, D < lambda); aperture eta=1: -0.5 dBi; typical: -3.1 dBi (eta=0.55) (not 20 dBi) | CAUGHT |
11 | Radar Range Equation | Doubling transmit power doubles radar detection range | Range increases by factor 1.189 (2^(1/4) = 1.189), not 2.0 | CAUGHT |
12 | Radar Range Equation | Small drone (0.01 m^2 RCS) detectable at 200 km by 1 kW X-band radar with 30 dBi gain | Max range: 2.7 km for 0.01 m^2 RCS at 1 kW X-band (not 200 km) | CAUGHT |
13 | Antenna Gain | A 0.5 m user-terminal dish at 12 GHz gives 50 dBi gain | Physical limit: 36.1 dBi (Harrington); typical dish: 33.4 dBi (eta=0.55) (not 50 dBi) | CAUGHT |
14 | Antenna Gain | A 3 m dish at 10 GHz is in its far field at 10 m, so gain can be measured there | Far-field distance 2D^2/lambda = 600 m; 10 m is in the near field | CAUGHT |
15 | Radar Ambiguity | A 10 GHz radar at 10 kHz PRF unambiguously measures 500 m/s | v_ua = lambda*PRF/4 = +/-74.9 m/s (blind speed 149.9 m/s); 500 m/s aliases (not 500 m/s) | CAUGHT |
16 | Radar Ambiguity | A 10 GHz pulse-Doppler radar can unambiguously cover 150 km and +/-300 m/s at once | R_uav_ua = clambda/8 = 1.123e+06 m^2/s for any PRF; claimed 4.5e+07 m^2/s (40x too large) | CAUGHT |
Generated automatically by pytest tests/test_marketing.py -s
Full derivations, sources, and worked examples for every formula are in docs/formulas.md.
rf_link_budgetComputes a complete RF link budget using the Friis transmission equation and validates antenna gains against physical limits.
Example: "What's the received power for a 2.4 GHz link at 100 m with 20 dBm TX, 10 dBi TX gain, 3 dBi RX gain?"
Returns FSPL, received power, wavelength, and — when antenna diameters are supplied — gain limit checks. Gains above the hard bound G_max = max((pi D / lambda)^2, (ka)^2 + 2ka) (the eta = 1 aperture value, or Harrington's bound for electrically small antennas) are rejected; gains above the typical dish value (eta = 0.55) are accepted with a warning. Also warns inside the far-field distance 2D^2/lambda and rejects negative losses.
shannon_hartleyComputes Shannon-Hartley channel capacity C = B log2(1 + SNR) and validates throughput claims.
Example: "Can a 20 MHz channel with 15 dB SNR support 500 Mbps?"
Returns theoretical capacity, spectral efficiency, and whether the claim is physically possible, including the exact percentage by which a violating claim exceeds the Shannon limit.
noise_floorComputes thermal noise power N = k_B T B, cascades noise figures through multi-stage receivers with the Friis noise formula, and calculates receiver sensitivity.
Example: "What's the noise floor for a 1 MHz receiver at 290 K with a two-stage LNA chain?"
Returns thermal noise in dBm and watts, cascaded noise figure, effective input noise temperature T_e = 290 K * (F - 1), and receiver sensitivity.
radar_rangeComputes the monostatic radar range equation R_max = [P_t G^2 lambda^2 sigma / ((4pi)^3 S_min L)]^(1/4) and validates detection-range claims.
Example: "Can a 1 kW X-band radar with 30 dBi gain detect a 0.01 m^2 drone at 200 km?"
Returns maximum detection range, minimum detectable signal, wavelength, and intermediate values. Catches the common fourth-root fallacy that doubling power doubles range.
antenna_gainAnalyses a single antenna from its diameter or physical area: gain limits, beamwidth, and far-field distance, with optional validation of a claimed gain.
Example: "Can a 0.5 m dish at 12 GHz really give 50 dBi? What beamwidth should I expect?"
Returns the physical gain limit (aperture or Harrington bound, and which one governs), typical gain at the given efficiency (default 0.55), effective aperture, half-power beamwidth estimates, far-field distance 2D^2/lambda, and — for a claimed gain — the implied aperture efficiency and validity.
radar_ambiguityComputes pulse-Doppler ambiguity limits for a given carrier frequency and PRF.
Example: "Can a 10 GHz radar at 10 kHz PRF unambiguously measure a 500 m/s target out to 150 km?"
Returns unambiguous range R_ua = c / (2 PRF), unambiguous velocity v_ua = lambda PRF / 4, blind speed, Doppler shift and apparent (aliased) velocity, range resolution (c tau / 2, or c / 2B with pulse compression), minimum range, duty cycle, and the range-Doppler dilemma invariant R_ua v_ua = c lambda / 8. Rejects range, velocity, or resolution claims the PRF or pulse cannot support.
Every calculation is validated against hard physical limits:
Speed of light: c = 299,792,458 m/s — no exceptions
Thermal noise floor: N = -174 dBm/Hz at 290 K — the IEEE standard reference
Shannon limit: C = B log2(1 + SNR) — no throughput claim exceeds this
Antenna gain limit: G_max = max((pi D / lambda)^2, (ka)^2 + 2ka) — the eta = 1 aperture value for planar apertures and Harrington's bound for any antenna in a sphere of diameter D; eta = 0.55 is a warning threshold, not a limit
Radar range equation: R_max = [P_t G^2 lambda^2 sigma / ((4pi)^3 S_min)]^(1/4) — range obeys the fourth-root law
Receiver sensitivity: S_min = k (T_A + T_0 (F - 1)) B * SNR with T_e = T_0 (F - 1) referenced to 290 K
Unambiguous range: R_ua = c / (2 PRF) — echoes beyond it fold into a later pulse interval
Unambiguous velocity: v_ua = lambda PRF / 4 — Doppler is sampled at the PRF, so |f_d| <= PRF/2
Range-Doppler dilemma: R_ua * v_ua = c lambda / 8 — no PRF choice beats it for a given carrier
Violations return structured PhysicalViolationError responses with LaTeX explanations, not silent failures.
Catching Hallucinations — walkthrough of five real LLM failure modes with full JSON responses
Interactive Demo Notebook — Jupyter notebook calling the physics engines directly
Formula Reference — every formula, constant, and validation guard with sources
Changelog — release history
Requires uv and Python 3.12+ (CI covers 3.12–3.14):
# Clone and install
git clone https://github.com/JonesRobM/physbound.git
cd physbound
uv sync --all-extras
# Run checks
uv run pytest tests/ -v
uv run ruff check src/ tests/
uv run mypy src/physbound/
# Regenerate the hallucination table above
uv run pytest tests/test_marketing.py -s
# Start the MCP server locally
uv run physboundContributions that expand the set of validated physics domains are welcome — see CONTRIBUTING.md for the architecture guide and the step-by-step recipe for adding a new validator.
RF system design review — validate link budgets, receiver sensitivity, and noise cascades
Telecom proposal vetting — catch impossible throughput claims before they reach a customer
Radar system sizing — sanity-check detection range, PRF selection, and ambiguity trade-offs
Educational tools — teach Shannon-Hartley, Friis transmission, and thermal noise with verified calculations
CI/CD for physics — integrate as a validation step in engineering pipelines
If PhysBound is useful in your work, consider buying me a coffee.
MIT License. See LICENSE.
Model Context Protocol — the open standard for AI tool integration
MCP Server Registry — official directory of MCP servers
FastMCP — Python framework for building MCP servers
Calculate antenna aperture gain limits, beamwidth, far-field distance; validate gain claims.
For a circular aperture of diameter D (or an aperture of area A, converted to the equivalent circular diameter D = sqrt(4A/pi)) computes the planar-aperture directivity D_0 = 4piA/lambda^2 = (piD/lambda)^2 (aperture efficiency eta = 1), Harrington's bound D_max = (ka)^2 + 2ka (k = 2pi/lambda, a = D/2) for any antenna enclosed in a sphere of diameter D, the hard physical gain limit max(D_0, D_max) (numerically D_max; equal to D_0 to within 0.1 dB for D >> lambda, but several dB higher for electrically small antennas D < lambda, e.g. a 2.15 dBi dipole in a 0.1 m footprint at 900 MHz is valid although D_0 = -0.5 dBi), and the typical gain G = etaD_0 at the given efficiency (default eta = 0.55, parabolic dish). The limiting_bound field reports 'harrington' for D < lambda and 'aperture' for D >= lambda. Also returns the effective aperture A_e = etaA, a half-power beamwidth estimate (HPBW ~ 70lambda/D degrees for a tapered reflector; 58.4lambda/D for a uniformly illuminated circular aperture) and the far-field (Fraunhofer) distance 2*D^2/lambda.
If claimed_gain_dbi is given it is validated: a claim above the physical limit is rejected as a physics violation; a claim between the typical gain and the physical limit is accepted with a warning and the implied planar-aperture efficiency eta = G_claim / D_0 is reported.
Use this tool when you need to:
Check whether a quoted antenna gain is consistent with its size and frequency
Estimate the gain, beamwidth or effective aperture of a dish of known diameter
Find the minimum far-field range for antenna measurements or Friis validity
Size an antenna for a required gain at a given frequency
Returns a PhysicalViolationError dict if any input violates physics or the claimed gain exceeds the aperture limit.
| Name | Required | Description | Default |
|---|---|---|---|
| diameter_m | No | Circular aperture diameter in meters. Provide this OR aperture_area_m2. | |
| frequency_hz | Yes | Operating frequency in Hz (must be > 0) | |
| aperture_area_m2 | No | Physical aperture area in m^2. Provide this OR diameter_m. | |
| claimed_gain_dbi | No | Optional antenna gain claim to validate in dBi | |
| aperture_efficiency | No | Efficiency for the typical gain / warning threshold (default: 0.55 for a parabolic dish; the hard limit is max(eta = 1 aperture value, Harrington bound)) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Calculate thermal noise power (kTB), cascaded noise figure, and receiver sensitivity.
Computes the fundamental thermal noise floor N = k_B * T * B, which is -174 dBm/Hz at the IEEE standard temperature of 290K. Optionally cascades multiple amplifier/filter stages using the Friis noise figure formula F_total = F_1 + (F_2-1)/G_1 + (F_3-1)/(G_1G_2) + ..., the receiver's effective input noise temperature T_e = T_0(F-1) with T_0 = 290 K (the IEEE reference at which noise figure is defined, independent of temperature_k), and receiver sensitivity S_min = k_B*(T_A + T_e)BSNR_required, which reduces to N_floor + NF + SNR_required when temperature_k = 290 K.
Use this tool when you need to:
Determine the thermal noise floor for a receiver bandwidth
Cascade noise figures through a multi-stage receiver chain
Calculate minimum detectable signal / receiver sensitivity
Validate that a claimed noise figure is physically plausible
Returns a PhysicalViolationError dict if inputs violate thermodynamic limits.
| Name | Required | Description | Default |
|---|---|---|---|
| stages | No | Optional list of stages, each with 'gain_db' and 'noise_figure_db' keys | |
| bandwidth_hz | Yes | Receiver bandwidth in Hz (must be > 0) | |
| temperature_k | No | Source/antenna noise temperature T_A in Kelvin used for the kTB floor (default: 290K, must be >= 0) | |
| required_snr_db | No | Required SNR in dB for sensitivity calculation |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| prf_hz | Yes | Pulse repetition frequency in Hz (must be > 0) | |
| bandwidth_hz | No | Optional compressed bandwidth in Hz; sets the resolution limit to c/(2B) | |
| frequency_hz | Yes | Carrier frequency in Hz (must be > 0) | |
| pulse_width_s | No | Optional transmitted pulse width tau in seconds (must be > 0) | |
| target_velocity_m_s | No | Optional target radial velocity in m/s (closing positive) | |
| claimed_range_resolution_m | No | Optional claimed range resolution to validate (m) | |
| claimed_unambiguous_range_m | No | Optional claimed unambiguous range to validate (m) | |
| claimed_unambiguous_velocity_m_s | No | Optional claimed unambiguous velocity to validate (m/s) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Calculate maximum monostatic radar detection range and validate range claims.
Computes the radar range equation R_max = [P_t * G^2 * lambda^2 * sigma / ((4*pi)^3 * S_min * L)]^(1/4) for a monostatic radar (same antenna for transmit and receive). Validates that claimed detection ranges do not exceed the theoretical maximum. Catches the common fourth-root fallacy where LLMs incorrectly state that doubling transmit power doubles radar range (it only increases range by a factor of 2^(1/4) = 1.19x).
Use this tool when you need to:
Calculate the maximum detection range of a radar system
Validate whether a claimed radar detection range is physically achievable
Determine minimum detectable signal power for a radar receiver
Check if radar performance claims account for the R^4 path loss
Verify that RCS assumptions are reasonable for the target class
Returns both human-readable summary and machine-readable JSON with all intermediate values. Returns a PhysicalViolationError dict if any input violates physics or the claimed range exceeds R_max.
| Name | Required | Description | Default |
|---|---|---|---|
| rcs_m2 | Yes | Radar cross section of the target in m^2 (must be > 0) | |
| losses_db | No | Total system losses in dB (default: 0) | |
| min_snr_db | No | Minimum required SNR in dB for detection (default: 13 dB, Swerling I) | |
| num_pulses | No | Number of integrated pulses for integration gain (default: 1) | |
| frequency_hz | Yes | Operating frequency in Hz (must be > 0) | |
| peak_power_w | Yes | Peak transmit power in watts (must be > 0) | |
| claimed_range_m | No | Optional claimed detection range to validate against R_max (meters) | |
| antenna_gain_dbi | Yes | Antenna gain in dBi (same antenna for TX and RX) | |
| noise_bandwidth_hz | No | Receiver noise bandwidth in Hz (default: 1 MHz) | |
| system_noise_temp_k | No | System noise temperature in Kelvin (default: 290K) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Calculate a complete RF link budget using the Friis transmission equation.
Computes free-space path loss (FSPL), received power, and validates antenna gains against the physical gain limit. The hard bound is G_max = max((piD/lambda)^2, (ka)^2 + 2ka) with k = 2pi/lambda and a = D/2, i.e. the larger of the eta = 1 aperture value and Harrington's bound for an antenna enclosed in a sphere of diameter D (numerically the Harrington value, which converges to the aperture value for D >> lambda and matters for electrically small antennas, D < lambda); a claimed gain above it is rejected. A claimed gain above the typical-efficiency value eta*(pi*D/lambda)^2 (eta = 0.55 by default) but below the physical bound is accepted with a warning. Negative losses are rejected (conservation of energy).
Use this tool when you need to:
Estimate received signal strength for a wireless link
Validate whether a claimed link budget is physically achievable
Check if antenna gain claims are consistent with antenna dimensions
Compute free-space path loss at a given frequency and distance
Returns both human-readable summary and machine-readable JSON with all intermediate values. Returns a PhysicalViolationError dict if any input violates physics.
| Name | Required | Description | Default |
|---|---|---|---|
| distance_m | Yes | Link distance in meters (must be > 0) | |
| frequency_hz | Yes | Carrier frequency in Hz (must be > 0) | |
| rx_losses_db | No | RX-side miscellaneous losses in dB (default: 0) | |
| tx_losses_db | No | TX-side miscellaneous losses in dB (default: 0) | |
| tx_power_dbm | Yes | Transmit power in dBm | |
| aperture_efficiency | No | Efficiency for the typical-gain warning threshold (default: 0.55 for a parabolic dish; the hard limit is max(eta = 1 aperture value, Harrington bound)) | |
| rx_antenna_gain_dbi | Yes | Receive antenna gain in dBi | |
| tx_antenna_gain_dbi | Yes | Transmit antenna gain in dBi | |
| rx_antenna_diameter_m | No | RX antenna diameter in meters (enables aperture check) | |
| tx_antenna_diameter_m | No | TX antenna diameter in meters (enables aperture check) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Calculate Shannon-Hartley channel capacity and validate throughput claims.
Computes the theoretical maximum data rate C = B * log2(1 + SNR) for an AWGN channel. If a claimed throughput is provided, validates it against this limit. Any claim exceeding the Shannon limit is a physical impossibility.
Use this tool when you need to:
Calculate maximum achievable throughput for a given bandwidth and SNR
Validate whether a throughput claim is physically possible
Determine spectral efficiency limits
Check if a modulation/coding scheme claim is realistic
Returns a PhysicalViolationError dict when a claim exceeds the Shannon limit.
| Name | Required | Description | Default |
|---|---|---|---|
| snr_db | No | Signal-to-noise ratio in dB. Provide this OR snr_linear. | |
| snr_linear | No | Signal-to-noise ratio (linear, not dB). Provide this OR snr_db. | |
| bandwidth_hz | Yes | Channel bandwidth in Hz (must be > 0) | |
| claimed_throughput_bps | No | Optional throughput claim to validate in bits/sec |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.2.1antenna_gainnoise_floor5 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / bandwidth_hz / descriptionAdded value: +"Receiver bandwidth in Hz (must be > 0)"Input schema / properties / required_snr_db / descriptionAdded value: +"Required SNR in dB for sensitivity calculation"Input schema / properties / stages / descriptionAdded value: +"Optional list of stages, each with 'gain_db' and 'noise_figure_db' keys"Input schema / properties / temperature_k / descriptionAdded value: +"Source/antenna noise temperature T_A in Kelvin used for the\nkTB floor (default: 290K, must be >= 0)"radar_ambiguityradar_range11 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / antenna_gain_dbi / descriptionAdded value: +"Antenna gain in dBi (same antenna for TX and RX)"Input schema / properties / claimed_range_m / descriptionAdded value: +"Optional claimed detection range to validate against R_max (meters)"Input schema / properties / frequency_hz / descriptionAdded value: +"Operating frequency in Hz (must be > 0)"Input schema / properties / losses_db / descriptionAdded value: +"Total system losses in dB (default: 0)"Input schema / properties / min_snr_db / descriptionAdded value: +"Minimum required SNR in dB for detection (default: 13 dB, Swerling I)"Input schema / properties / noise_bandwidth_hz / descriptionAdded value: +"Receiver noise bandwidth in Hz (default: 1 MHz)"Input schema / properties / num_pulses / descriptionAdded value: +"Number of integrated pulses for integration gain (default: 1)"Input schema / properties / peak_power_w / descriptionAdded value: +"Peak transmit power in watts (must be > 0)"Input schema / properties / rcs_m2 / descriptionAdded value: +"Radar cross section of the target in m^2 (must be > 0)"Input schema / properties / system_noise_temp_k / descriptionAdded value: +"System noise temperature in Kelvin (default: 290K)"rf_link_budget11 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / aperture_efficiencyAdded value: +{
+ "default": 0.55,
+ "description": "Efficiency for the typical-gain warning threshold\n(default: 0.55 for a parabolic dish; the hard limit is\nmax(eta = 1 aperture value, Harrington bound))",
+ "type": "number"
+}Input schema / properties / distance_m / descriptionAdded value: +"Link distance in meters (must be > 0)"Input schema / properties / frequency_hz / descriptionAdded value: +"Carrier frequency in Hz (must be > 0)"Input schema / properties / rx_antenna_diameter_m / descriptionAdded value: +"RX antenna diameter in meters (enables aperture check)"Input schema / properties / rx_antenna_gain_dbi / descriptionAdded value: +"Receive antenna gain in dBi"Input schema / properties / rx_losses_db / descriptionAdded value: +"RX-side miscellaneous losses in dB (default: 0)"Input schema / properties / tx_antenna_diameter_m / descriptionAdded value: +"TX antenna diameter in meters (enables aperture check)"Input schema / properties / tx_antenna_gain_dbi / descriptionAdded value: +"Transmit antenna gain in dBi"Input schema / properties / tx_losses_db / descriptionAdded value: +"TX-side miscellaneous losses in dB (default: 0)"Input schema / properties / tx_power_dbm / descriptionAdded value: +"Transmit power in dBm"shannon_hartley5 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / bandwidth_hz / descriptionAdded value: +"Channel bandwidth in Hz (must be > 0)"Input schema / properties / claimed_throughput_bps / descriptionAdded value: +"Optional throughput claim to validate in bits/sec"Input schema / properties / snr_db / descriptionAdded value: +"Signal-to-noise ratio in dB. Provide this OR snr_linear."Input schema / properties / snr_linear / descriptionAdded value: +"Signal-to-noise ratio (linear, not dB). Provide this OR snr_db."v0.2.0noise_floorradar_rangerf_link_budgetshannon_hartleyEach tool targets a distinct RF physics equation family, and the descriptions are detailed enough to disambiguate most cases. However, rf_link_budget and antenna_gain both validate antenna gain claims against the same physical aperture/Harrington limits, so an agent could initially be uncertain which tool to call for a gain-checking task.
All six tool names follow a consistent snake_case noun phrase pattern: rf_link_budget, shannon_hartley, noise_floor, radar_range, antenna_gain, radar_ambiguity. There is no mixing of conventions or vague verbs, so the naming is predictable and readable.
Six tools is well-scoped for a specialized RF/physics validation server. Each tool covers a distinct and substantial calculation area, and none feel redundant or unnecessary.
The tool set covers the major RF physical-layer validation surfaces: link budgeting, channel capacity, noise floor and sensitivity, radar range, antenna gain limits, and pulse-Doppler ambiguity. Within the apparent domain of validating RF claims against physics, there are no obvious dead ends or missing core operations.
AI-callable calculators and engineering models with real formulas. No hallucinated math.
Jailbreak-proof AI guardrails. Automated Reasoning SMT solver, not an LLM. ZK proofs included.
Deterministic runtime safety for AI agents: scan PII, gate tool actions, verify LLM output.
33 tools that make AI write, implement, and verify intent against explicit, testable constraints.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/JonesRobM/physbound'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
