physbound

Overview Schema Source Related Servers Discussions Admin

rf_link_budget

Compute free-space path loss and received power while validating antenna gains against physical limits, then flag impossible RF link configurations.

Instructions

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.

Input Schema

TableJSON Schema

Name	Required	Description
`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)

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed11 schema fields changedv0.2.1Sep 5, 2026

addedInput schema / additionalProperties
```
Added value: +false
```

addedInput schema / properties / aperture_efficiency

Added 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"
+}

addedInput schema / properties / distance_m / description
```
Added value: +"Link distance in meters (must be > 0)"
```
addedInput schema / properties / frequency_hz / description
```
Added value: +"Carrier frequency in Hz (must be > 0)"
```

addedInput schema / properties / rx_antenna_diameter_m / description

Added value: +"RX antenna diameter in meters (enables aperture check)"

addedInput schema / properties / rx_antenna_gain_dbi / description
```
Added value: +"Receive antenna gain in dBi"
```

addedInput schema / properties / rx_losses_db / description

Added value: +"RX-side miscellaneous losses in dB (default: 0)"

addedInput schema / properties / tx_antenna_diameter_m / description

Added value: +"TX antenna diameter in meters (enables aperture check)"

addedInput schema / properties / tx_antenna_gain_dbi / description
```
Added value: +"Transmit antenna gain in dBi"
```

addedInput schema / properties / tx_losses_db / description

Added value: +"TX-side miscellaneous losses in dB (default: 0)"

addedInput schema / properties / tx_power_dbm / description
```
Added value: +"Transmit power in dBm"
```

First observedv0.2.0Mar 11, 2026

TDQS

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

Deploy Server