Skip to content
verify mcp Beta VerifyMCP is currently in beta. If you notice any issues, get in touch and we’ll put it right.

io.github.JonesRobM/physbound

PYPI · PHYSBOUND · SCANNED SEP 21

Physical Layer Linter: validates RF and radar calculations against hard physical limits.

Available components

0 this week 65 Trust /100

Recent critical change

CVE-2026-32871 affects this package (4 Aug 2026). See the changelog before you install this server.

Trust breakdown (7 categories)

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
Install

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

# add to Claude Code
claude mcp add jonesrobm-physbound -- uvx physbound
// .cursor/mcp.json
{
  "mcpServers": {
    "jonesrobm-physbound": {
      "command": "uvx",
      "args": [
        "physbound"
      ]
    }
  }
}
// .vscode/mcp.json
{
  "servers": {
    "jonesrobm-physbound": {
      "command": "uvx",
      "args": [
        "physbound"
      ]
    }
  }
}
# add to Codex CLI
codex mcp add jonesrobm-physbound -- uvx physbound
// opencode.json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "jonesrobm-physbound": {
      "type": "local",
      "command": [
        "uvx",
        "physbound"
      ],
      "enabled": true
    }
  }
}
# add to OpenClaw
openclaw mcp add jonesrobm-physbound --command uvx --arg physbound
# ~/.hermes/config.yaml
mcp_servers:
  jonesrobm-physbound:
    command: "uvx"
    args: ["physbound"]
// ~/.netclaw/config/netclaw.json
{
  "McpServers": {
    "jonesrobm-physbound": {
      "Transport": "stdio",
      "Command": "uvx",
      "Arguments": [
        "physbound"
      ]
    }
  }
}
# add to Vellum
assistant mcp add jonesrobm-physbound -t stdio -c uvx -a physbound
// mcp.json
{
  "mcpServers": {
    "jonesrobm-physbound": {
      "command": "uvx",
      "args": [
        "physbound"
      ]
    }
  }
}
Changelog

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
Diagnostics

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 →

MCP tools · 6 exposed · ~2,724 tokens

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 →

Tool Tokens
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.

NameTypeReqDescription
aperture_area_m2Physical aperture area in m^2. Provide this OR diameter_m.
aperture_efficiencynumberEfficiency 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_dbiOptional antenna gain claim to validate in dBi
diameter_mCircular aperture diameter in meters. Provide this OR aperture_area_m2.
frequency_hznumberyesOperating 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.

NameTypeReqDescription
bandwidth_hznumberyesReceiver bandwidth in Hz (must be > 0)
required_snr_dbRequired SNR in dB for sensitivity calculation
stagesOptional list of stages, each with 'gain_db' and 'noise_figure_db' keys
temperature_knumberSource/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.

NameTypeReqDescription
bandwidth_hzOptional compressed bandwidth in Hz; sets the resolution limit to c/(2B)
claimed_range_resolution_mOptional claimed range resolution to validate (m)
claimed_unambiguous_range_mOptional claimed unambiguous range to validate (m)
claimed_unambiguous_velocity_m_sOptional claimed unambiguous velocity to validate (m/s)
frequency_hznumberyesCarrier frequency in Hz (must be > 0)
prf_hznumberyesPulse repetition frequency in Hz (must be > 0)
pulse_width_sOptional transmitted pulse width tau in seconds (must be > 0)
target_velocity_m_sOptional 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.

NameTypeReqDescription
antenna_gain_dbinumberyesAntenna gain in dBi (same antenna for TX and RX)
claimed_range_mOptional claimed detection range to validate against R_max (meters)
frequency_hznumberyesOperating frequency in Hz (must be > 0)
losses_dbnumberTotal system losses in dB (default: 0)
min_snr_dbnumberMinimum required SNR in dB for detection (default: 13 dB, Swerling I)
noise_bandwidth_hznumberReceiver noise bandwidth in Hz (default: 1 MHz)
num_pulsesintegerNumber of integrated pulses for integration gain (default: 1)
peak_power_wnumberyesPeak transmit power in watts (must be > 0)
rcs_m2numberyesRadar cross section of the target in m^2 (must be > 0)
system_noise_temp_knumberSystem 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.

NameTypeReqDescription
aperture_efficiencynumberEfficiency 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_mnumberyesLink distance in meters (must be > 0)
frequency_hznumberyesCarrier frequency in Hz (must be > 0)
rx_antenna_diameter_mRX antenna diameter in meters (enables aperture check)
rx_antenna_gain_dbinumberyesReceive antenna gain in dBi
rx_losses_dbnumberRX-side miscellaneous losses in dB (default: 0)
tx_antenna_diameter_mTX antenna diameter in meters (enables aperture check)
tx_antenna_gain_dbinumberyesTransmit antenna gain in dBi
tx_losses_dbnumberTX-side miscellaneous losses in dB (default: 0)
tx_power_dbmnumberyesTransmit 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.

NameTypeReqDescription
bandwidth_hznumberyesChannel bandwidth in Hz (must be > 0)
claimed_throughput_bpsOptional throughput claim to validate in bits/sec
snr_dbSignal-to-noise ratio in dB. Provide this OR snr_linear.
snr_linearSignal-to-noise ratio (linear, not dB). Provide this OR snr_db.

Structured output declared, but exposes no named fields.

No examples provided.

Common questions

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.