io.github.JonesRobM/physbound
PYPI · PHYSBOUND · SCANNED SEP 21
Physical Layer Linter: validates RF and radar calculations against hard physical limits.
Available components
Recent critical change
CVE-2026-32871 affects this package (4 Aug 2026). See the changelog before you install this server.
How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. How we score → Why this is hard to score →
Supply Chain Security50
- Malware scan not yet available for this package.Unverified
- No known CVEs affecting this package version or its production dependencies.Pass
- Runs hatchling.build at install time, a recognised native-build step with no shell scripting around it. View diagnostics → Pass
- 2 of 19 dependencies flagged as unhealthy. View diagnostics → Partial
Provenance & Transparency35
- Source repository is publicly reachable at the declared URL. View diagnostics → Pass
- Provenance check failed: no build-provenance attestation is published. See how to fix → View diagnostics → Fail
- License check failed: the license (MIT License) isn't a recognized OSI-approved license. See how to fix → Fail
- Actively maintained (last published 20 days ago).Pass
- Publishes a security disclosure policy (SECURITY.md).Pass
Schema Quality & AI Usability72
- 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).Pass
- AI-judged instruction clarity (good).Pass
- Context-footprint check failed: tool/resource definitions use about 2828 tokens (~404/item across 7 items; 6 tools + 1 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management87
- Stability observed for 26 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage100
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 100% of tool parameters carry a description.Pass
- Structured output schemas are declared (100% of tools); any adoption earns full credit.Pass
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- We read all 6 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
- An AI judge read all 8 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
How do I install the io.github.JonesRobM/physbound MCP server?
io.github.JonesRobM/physbound runs locally as a PyPI package, launched with uvx physbound. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
pypi · physbound
claude mcp add jonesrobm-physbound -- uvx physbound
{
"mcpServers": {
"jonesrobm-physbound": {
"command": "uvx",
"args": [
"physbound"
]
}
}
} {
"servers": {
"jonesrobm-physbound": {
"command": "uvx",
"args": [
"physbound"
]
}
}
} codex mcp add jonesrobm-physbound -- uvx physbound
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"jonesrobm-physbound": {
"type": "local",
"command": [
"uvx",
"physbound"
],
"enabled": true
}
}
} openclaw mcp add jonesrobm-physbound --command uvx --arg physbound
mcp_servers:
jonesrobm-physbound:
command: "uvx"
args: ["physbound"] {
"McpServers": {
"jonesrobm-physbound": {
"Transport": "stdio",
"Command": "uvx",
"Arguments": [
"physbound"
]
}
}
} assistant mcp add jonesrobm-physbound -t stdio -c uvx -a physbound
{
"mcpServers": {
"jonesrobm-physbound": {
"command": "uvx",
"args": [
"physbound"
]
}
}
} Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 20 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 80 to 83. That category is still filling its 30-day observation window: 24 days of observed history at the previous scan, 25 at this one. The score rises as the window fills, whether or not the server changes.
- 19 Sept 26 −3
- Stability: pass → 0.80 functional
- 18 Sept 26 0
- Stability: 0.97 → pass security
- 17 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 93 to 97. That category is still filling its 30-day observation window: 28 days of observed history at the previous scan, 29 at this one. The score rises as the window fills, whether or not the server changes.
- 15 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 87 to 90. That category is still filling its 30-day observation window: 26 days of observed history at the previous scan, 27 at this one. The score rises as the window fills, whether or not the server changes.
- 14 Sept 26 −15
- Malware scan: pass → unverified ▼ security
- 13 Sept 26 +16
- Malware scan: unverified → pass ▲ security
- 12 Sept 26 −3
- Stability: pass → 0.80 functional
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 21 Sept 2026 · Analysed pypi/physbound@0.3.0
Provenance No attestation
The registry publishes no build provenance for this version, so there is nothing to verify.
| Result | No attestation |
|---|---|
| Ecosystem | pypi |
Background: How many MCP packages publish verified provenance →
Install scripts 1 script
| Hook | Tier | Command |
|---|---|---|
| build_backend | allowlisted | hatchling.build |
Background: Why install scripts are a supply-chain risk →
Dependencies 19 packages
| Packages resolved | 19 |
|---|---|
| Stale | 2 |
| Tree resolution | Complete |
Background: SBOMs and build attestations, explained →
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
antenna_gain ~623
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 = 4*pi*A/lambda^2 = (pi*D/lambda)^2 (aperture efficiency eta = 1), Harrington's bound D_max = (ka)^2 + 2ka (k = 2*pi/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 = eta*D_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 = eta*A, a half-power beamwidth estimate (HPBW ~ 70*lambda/D degrees for a tapered reflector; 58.4*lambda/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 | Type | Req | Description |
|---|---|---|---|
| aperture_area_m2 | – | – | Physical aperture area in m^2. Provide this OR diameter_m. |
| aperture_efficiency | number | – | 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)) |
| claimed_gain_dbi | – | – | Optional antenna gain claim to validate in dBi |
| diameter_m | – | – | Circular aperture diameter in meters. Provide this OR aperture_area_m2. |
| frequency_hz | number | yes | Operating frequency in Hz (must be > 0) |
Structured output declared, but exposes no named fields.
No examples provided.
noise_floor ~358
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_1*G_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)*B*SNR_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 | Type | Req | Description |
|---|---|---|---|
| bandwidth_hz | number | yes | Receiver bandwidth in Hz (must be > 0) |
| required_snr_db | – | – | Required SNR in dB for sensitivity calculation |
| stages | – | – | Optional list of stages, each with 'gain_db' and 'noise_figure_db' keys |
| temperature_k | number | – | Source/antenna noise temperature T_A in Kelvin used for the kTB floor (default: 290K, must be >= 0) |
Structured output declared, but exposes no named fields.
No examples provided.
radar_ambiguity ~536
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 | Type | Req | Description |
|---|---|---|---|
| bandwidth_hz | – | – | Optional compressed bandwidth in Hz; sets the resolution limit to c/(2B) |
| claimed_range_resolution_m | – | – | Optional claimed range resolution to validate (m) |
| claimed_unambiguous_range_m | – | – | Optional claimed unambiguous range to validate (m) |
| claimed_unambiguous_velocity_m_s | – | – | Optional claimed unambiguous velocity to validate (m/s) |
| frequency_hz | number | yes | Carrier frequency in Hz (must be > 0) |
| prf_hz | number | yes | Pulse repetition frequency in Hz (must be > 0) |
| pulse_width_s | – | – | Optional transmitted pulse width tau in seconds (must be > 0) |
| target_velocity_m_s | – | – | Optional target radial velocity in m/s (closing positive) |
Structured output declared, but exposes no named fields.
No examples provided.
radar_range ~466
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 | Type | Req | Description |
|---|---|---|---|
| antenna_gain_dbi | number | yes | Antenna gain in dBi (same antenna for TX and RX) |
| claimed_range_m | – | – | Optional claimed detection range to validate against R_max (meters) |
| frequency_hz | number | yes | Operating frequency in Hz (must be > 0) |
| losses_db | number | – | Total system losses in dB (default: 0) |
| min_snr_db | number | – | Minimum required SNR in dB for detection (default: 13 dB, Swerling I) |
| noise_bandwidth_hz | number | – | Receiver noise bandwidth in Hz (default: 1 MHz) |
| num_pulses | integer | – | Number of integrated pulses for integration gain (default: 1) |
| peak_power_w | number | yes | Peak transmit power in watts (must be > 0) |
| rcs_m2 | number | yes | Radar cross section of the target in m^2 (must be > 0) |
| system_noise_temp_k | number | – | System noise temperature in Kelvin (default: 290K) |
Structured output declared, but exposes no named fields.
No examples provided.
rf_link_budget ~520
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((pi*D/lambda)^2, (ka)^2 + 2ka) with k = 2*pi/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 | Type | Req | Description |
|---|---|---|---|
| aperture_efficiency | number | – | 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)) |
| distance_m | number | yes | Link distance in meters (must be > 0) |
| frequency_hz | number | yes | Carrier frequency in Hz (must be > 0) |
| rx_antenna_diameter_m | – | – | RX antenna diameter in meters (enables aperture check) |
| rx_antenna_gain_dbi | number | yes | Receive antenna gain in dBi |
| rx_losses_db | number | – | RX-side miscellaneous losses in dB (default: 0) |
| tx_antenna_diameter_m | – | – | TX antenna diameter in meters (enables aperture check) |
| tx_antenna_gain_dbi | number | yes | Transmit antenna gain in dBi |
| tx_losses_db | number | – | TX-side miscellaneous losses in dB (default: 0) |
| tx_power_dbm | number | yes | Transmit power in dBm |
Structured output declared, but exposes no named fields.
No examples provided.
shannon_hartley ~221
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 | Type | Req | Description |
|---|---|---|---|
| bandwidth_hz | number | yes | Channel bandwidth in Hz (must be > 0) |
| claimed_throughput_bps | – | – | Optional throughput claim to validate in bits/sec |
| snr_db | – | – | Signal-to-noise ratio in dB. Provide this OR snr_linear. |
| snr_linear | – | – | Signal-to-noise ratio (linear, not dB). Provide this OR snr_db. |
Structured output declared, but exposes no named fields.
No examples provided.
What is the io.github.JonesRobM/physbound MCP server?
io.github.JonesRobM/physbound is an MCP server listed in the public MCP registry as io.github.JonesRobM/physbound. Physical Layer Linter: validates RF and radar calculations against hard physical limits. This page covers its PyPI package (physbound).
Is the io.github.JonesRobM/physbound MCP server safe to use?
io.github.JonesRobM/physbound scores 65 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 21 September 2026. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the io.github.JonesRobM/physbound MCP server expose?
io.github.JonesRobM/physbound exposes 6 tools: rf_link_budget, shannon_hartley, noise_floor, radar_range, antenna_gain, radar_ambiguity. Their descriptions and schemas cost roughly 2,724 tokens of context every time the server is loaded.
Is the io.github.JonesRobM/physbound MCP server still maintained?
io.github.JonesRobM/physbound is still listed as active in the MCP registry. We last reached this channel on 21 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.