Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@SpectraMCP analyze the spectrum from radar_cube.npy"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Hardware Optional: SpectraMCP runs fully in file-based mode (.wav, .iq, .sigmf-data, .npy radar cubes) with zero hardware. If an RTL-SDR, HackRF, or any SoapySDR-supported device is attached, live-capture tools unlock automatically.
SpectraMCP is a zero-trust Model Context Protocol (MCP) server that gives AI agents (Claude Desktop, Claude Code, Cursor, Antigravity) native tool access to RF spectrum capture, spectral analysis, and classical radar-DSP primitives — no SDR hardware required to get started.
// Add directly to claude_desktop_config.json
{
"mcpServers": {
"spectramcp": {
"command": "uvx",
"args": ["spectramcp"]
}
}
}GitHub About Section: 🛰️ The Model Context Protocol Server for RF Signal Processing, SDR & Radar DSP — We're totally on the same wavelength! 📶
Repository Topics / Tags: mcp · sdr · radar-dsp · rf-signals · fft · cfar · mvdr · kalman-filter · spectrogram · sigmf · rtl-sdr · hackrf · soapysdr · fastmcp · python
Related MCP server: SDR MCP Server
Every AI coding agent can write a DSP script. None of them can see a spectrum. Today, working with RF signals alongside an AI agent means a constant context-switch: the agent writes a matplotlib script, you run it, you screenshot the plot back into the chat, and you describe what you're looking at in words. SpectraMCP removes that loop entirely.
Instead of maintaining a folder of one-off analysis scripts, SpectraMCP unifies RF and radar DSP behind a single, structured tool interface:
Spectral Analysis: FFTs, STFT spectrograms, and rolling PSD waterfalls rendered directly as images the agent can reason over.
Radar DSP Primitives: 2D Range-Doppler processing, CA-CFAR detection, MVDR/Capon beamforming, and Kalman-filter multi-target tracking — exposed as callable tools instead of standalone scripts.
Signal Classification: Rule-based modulation and micro-Doppler cadence classification for quick "what am I looking at" triage.
Hardware Bridge: Optional live capture from RTL-SDR, HackRF, and any SoapySDR-supported device.
📡 Signal I/O & Format Parser: Loads .wav, raw .iq, .sigmf-data/.sigmf-meta, and .npy radar cubes into a normalized, zero-copy IQBuffer.
📊 Spectral Analysis Engine: Windowed FFTs (Hann/Hamming/Blackman), high-resolution STFT spectrograms, and rolling PSD waterfall visualization.
🎯 Radar DSP Suite: 2D FMCW Range-Doppler processing, 2D CA-CFAR adaptive thresholding, MVDR/Capon beamforming with diagonal loading, and constant-velocity Kalman multi-target tracking.
🔍 Signal & Micro-Doppler Classifier: Feature-based modulation scheme identification (AM/FM/OOK/FSK/PSK) and cadence-spectrum periodicity extraction for rotor-vs-flutter discrimination.
📁 Local Workspace Export: Saves generated plots and sliced IQ data segments directly to a user-configured local directory via SPECTRAMCP_WORKSPACE.
SpectraMCP unifies file loaders, SDR hardware bridges, spectral rendering, radar processing, and classification engines behind the stdio FastMCP transport layer.
graph TD
Agent["AI Agent (Claude / Cursor / Antigravity)"] --> Server["SpectraMCP stdio Server"]
Server --> IO[Signal I/O Layer]
IO --> File["File Loaders: .wav / .iq / .sigmf / .npy"]
IO --> HW["SDR Bridge: RTL-SDR / HackRF / SoapySDR"]
Server --> Spectral[Spectral Analysis Engine]
Spectral --> FFT["Windowed FFT"]
Spectral --> STFT["STFT Spectrogram"]
Spectral --> Waterfall["Rolling PSD Waterfall"]
Server --> Radar[Radar DSP Engine]
Radar --> RDM["2D Range-Doppler Map"]
Radar --> CFAR["2D CA-CFAR Detector"]
Radar --> Beam["MVDR / Capon Beamformer"]
Radar --> Track["Kalman Multi-Target Tracker"]
Server --> Classify[Classification Engine]
Classify --> Mod["Modulation Classifier"]
Classify --> MicroD["Micro-Doppler Cadence Extractor"]
Server --> Workspace["Workspace Export"]
Workspace --> Out["PNG / GIF / .npy / .sigmf Output"]
classDef default fill:#0f172a,stroke:#3b82f6,stroke-width:2px,color:#fff;
classDef process fill:#1e1b4b,stroke:#a855f7,stroke-width:2px,color:#fff;
class Spectral,Radar,Classify process;Zero-Trust & Stdio Isolation: SpectraMCP communicates strictly via standard I/O streams (stdio). It opens no network ports and requires no elevated privileges.
For any supplied RadarCube, range-to-beat-frequency mapping follows the standard closed-form FMCW relation. For a target at range $R$, sweep bandwidth $B$, and chirp duration $T_c$:
$$f_b = \frac{2BR}{cT_c} \implies R = \frac{f_b c T_c}{2B}$$
range_doppler_map applies Blackman windowing across both fast-time and slow-time axes before 2D FFT computation to suppress sidelobe leakage.
ca_cfar_detect estimates the local noise floor $P_n$ by averaging training cells around the cell-under-test (CUT), excluding guard cells, then applies:
$$T_{cell} = \alpha \cdot P_n, \qquad \alpha = N_{ref}\left(P_{fa}^{-1/N_{ref}} - 1\right)$$
where $N_{ref}$ is the number of reference training cells and $P_{fa}$ is the user-specified target false-alarm probability (default $10^{-3}$).
mvdr_beamform regularizes the sample covariance matrix $\hat{\mathbf{R}}$ whenever snapshot count $K < M$ array elements:
$$\hat{\mathbf{R}}_{loaded} = \hat{\mathbf{R}} + \epsilon \cdot \text{tr}(\hat{\mathbf{R}}) \cdot \mathbf{I}$$
$$\mathbf{w} = \frac{\hat{\mathbf{R}}{loaded}^{-1}\mathbf{a}(\theta)}{\mathbf{a}(\theta)^H \hat{\mathbf{R}}{loaded}^{-1}\mathbf{a}(\theta)}$$
setup.batInstalls Python 3.12 via winget if missing, installs spectramcp and its Python dependencies, and auto-configures claude_desktop_config.json with an absolute interpreter path.
git clone https://github.com/IamOumarIbrahim/SpectraMCP.git
cd SpectraMCP
pip install -e .🔍 Verification Command:
python -m spectramcp.selftestExpected Output: [OK] Core DSP engine [OK] MCP transport [SDR: not detected — file mode only]
Only required if you plan to use capture_from_sdr / list_sdr_devices:
# Windows (winget)
winget install --id PothosWare.SoapySDR -e
# macOS (Homebrew)
brew install soapysdr rtl-sdr hackrf
# Linux (Debian/Ubuntu)
sudo apt install soapysdr-tools librtlsdr-dev libhackrf-devOpen your configuration file:
Windows: %APPDATA%\Claude\claude_desktop_config.json
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Add the spectramcp server entry:
{
"mcpServers": {
"spectramcp": {
"command": "python",
"args": ["-m", "spectramcp.server"],
"env": {
"SPECTRAMCP_WORKSPACE": "C:\\Users\\YourUsername\\Downloads\\Spectra_Outputs"
}
}
}
}Restart Claude Desktop and open the tool icon to confirm all 13 tools are registered.
User: Load capture_2026_07_29.sigmf-data, show me the waterfall for the first 5 seconds,
then run CA-CFAR at Pfa=1e-3 and tell me what you find.
Agent:
→ load_iq_file(path="capture_2026_07_29.sigmf-data")
→ render_waterfall(duration_s=5.0)
[returns waterfall.png]
→ range_doppler_map(source="last_loaded")
→ ca_cfar_detect(pfa=1e-3, guard_cells=2, training_cells=12)
[returns detections at ranges 41.2m, 118.6m, 203.9m]
"The waterfall shows a steady carrier around 433.9 MHz with two brief bursts.
CFAR detected 3 targets after Range-Doppler processing — ranges and radial
velocities are annotated on the returned detection map."Highlights of provided tools. View complete parameters in docs/TOOLS_REFERENCE.md.
Category | MCP Tool | Description |
Signal I/O |
| Loads |
Signal I/O |
| Captures a fixed-duration IQ segment from an attached RTL-SDR/HackRF/SoapySDR device |
Signal I/O |
| Enumerates attached SDR hardware and reports supported sample rates / tunable range |
Spectral Analysis |
| Windowed FFT with configurable window (Hann/Hamming/Blackman) and zero-padding factor |
Spectral Analysis |
| STFT spectrogram image with configurable frame size, hop, and dB dynamic range |
Spectral Analysis |
| Rolling PSD waterfall across N consecutive capture segments |
Radar DSP |
| 2D windowed FFT (fast-time/slow-time) over a supplied |
Radar DSP |
| 2D Cell-Averaging CFAR detector with configurable guard/training cell geometry |
Radar DSP |
| Adaptive Capon/MVDR beamformer with diagonal-loading stabilization for rank-deficient snapshots |
Radar DSP |
| Constant-velocity Kalman tracker associating detections across sequential frames |
Classification |
| Rule-based AM/FM/OOK/FSK/PSK-family classifier using envelope, kurtosis, and spectral-flatness features |
Classification |
| Cadence-spectrum periodicity extraction for rotor-vs-flutter style signature comparison |
Workspace |
| Saves any generated figure or IQ slice directly to a local folder on the user's PC |
Tool | Primary Purpose | Where SpectraMCP Fits |
GNU Radio | Full flow-graph SDR runtime | SpectraMCP exposes discrete, agent-callable analysis primitives rather than a visual flow-graph builder |
GQRX / SDR# | Live GUI spectrum viewer | SpectraMCP is headless; built to be driven by an AI agent reasoning over spectral images |
Universal Radio Hacker | Manual protocol reverse-engineering | Complementary — URH is for interactive dissection, SpectraMCP is for agent-driven automated triage |
Passive Receiver Scope: SpectraMCP focuses exclusively on signal analysis, spectral visualization, and radar target extraction. It contains no transmission, jamming, or active protocol decoding logic.
Hardware Agnostic Fallback: If physical SDR hardware is unplugged or missing drivers, live capture tools fall back cleanly to file-based mode without crashing server execution.
SpectraMCP/
├── spectramcp/
│ ├── server.py - FastMCP stdio server & tool registration
│ ├── io.py - File loaders and SDR hardware bridge
│ ├── spectral.py - FFT, STFT, waterfall rendering
│ ├── radar.py - Range-Doppler, CA-CFAR, MVDR, Kalman tracker
│ ├── classify.py - Modulation & micro-Doppler classifiers
│ └── selftest.py - Verification CLI module (python -m spectramcp.selftest)
├── tests/ - Pytest suite (DSP + MCP schema)
├── docs/TOOLS_REFERENCE.md - Full 13-tool parameter reference
├── .github/workflows/ - CI/CD and release automation
├── setup.bat - Windows 1-click installer
├── pyproject.toml - Package configuration
├── SECURITY.md - Security disclosure policy
├── CONTRIBUTING.md - Contribution guidelines
└── CODE_OF_CONDUCT.md - Code of conductIssue | Root Cause | Resolution |
| Missing SoapySDR driver or unplugged hardware | Reinstall drivers per Setup Guide; file-mode tools still work |
| Relative Python path in config | Use an absolute interpreter path, as shown in Connecting to AI Clients |
CFAR returns 0 detections |
| Lower |
| RTL-SDR driver not installed | Run the SoapySDR driver install step under Setup Guide |
Contributing: Please review CONTRIBUTING.md for development setup and PR guidelines.
Code of Conduct: Adheres to the Contributor Covenant. See CODE_OF_CONDUCT.md.
Security Policy: For vulnerability reporting, see SECURITY.md.
Automated releases and build artifacts are generated via GitHub Actions whenever a new release tag (e.g. v1.0.0) is pushed to the repository:
git tag v1.0.0
git push origin v1.0.0See .github/workflows/release.yml for workflow details.
MIT © 2026 Oumar Ibrahim
NumPy · SciPy · SoapySDR · sigmf-python · FastMCP
If SpectraMCP saved you from writing another one-off FFT script, a ⭐ helps other people find it.
2D Cell-Averaging CFAR detector with configurable guard/training cell geometry.
| Name | Required | Description | Default |
|---|---|---|---|
| pfa | No | ||
| source | No | last_loaded | |
| guard_cells | No | ||
| training_cells | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It states it is a 2D CA-CFAR detector but does not explain side effects (e.g., data is read from 'last_loaded' source), output format, or requirements for prior computation. Missing crucial behavioral details.
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 a single concise sentence with no wasted words. However, it omits important context that could be included without significant bloat, so balance is moderate.
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?
Despite having an output schema, the description lacks information about expected input data, preprocessing steps, and interpretation of results. For a complex detection algorithm, this is insufficient for an agent to use correctly.
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?
Only two of four parameters (guard_cells, training_cells) are mentioned in the description. pfa and source are not explained. With 0% schema description coverage, the description should compensate but fails to fully clarify parameter meaning.
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 clearly identifies the tool as a 2D Cell-Averaging CFAR detector with configurable guard/training cell geometry. It specifies the algorithm and key parameters, distinguishing it from sibling tools like compute_fft or render_spectrogram.
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?
No usage guidelines are provided. The description does not indicate when to use this tool, prerequisites (e.g., a 2D matrix must be available), or how it relates to sibling tools like range_doppler_map or classify_modulation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Captures a fixed-duration IQ segment from an attached RTL-SDR/HackRF/SoapySDR device.
| Name | Required | Description | Default |
|---|---|---|---|
| gain | No | ||
| duration_s | No | ||
| center_freq | No | ||
| sample_rate | No | ||
| device_index | No |
| 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 burden of behavioral disclosure. It mentions capturing from an attached device and the fixed-duration IQ segment, but does not disclose what happens if no device is found, error handling, or if the operation is destructive. Adequate but not thorough.
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 a single sentence that immediately conveys the primary action. It is concise without extraneous information, though it could be slightly more structured for readability.
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 5 parameters with defaults, no schema descriptions, an output schema (not detailed here), and multiple sibling tools, the description is too minimal. It does not mention that all parameters are optional, the expected output format, or device compatibility constraints. Incomplete for a tool with this complexity.
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 0%, meaning no parameter descriptions are provided in the schema. The tool description does not explain any parameter meaning beyond their names (e.g., gain, sample_rate). This requires the agent to infer from parameter names alone, which is insufficient for proper invocation.
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 clearly states that the tool captures a fixed-duration IQ segment from specific SDR devices (RTL-SDR/HackRF/SoapySDR), which distinguishes it from siblings like load_iq_file (loading from file) and list_sdr_devices (listing devices).
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 does not provide any guidance on when to use this tool versus alternatives, nor does it mention prerequisites like requiring an attached device or driver setup. No explicit when-to-use or when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rule-based AM/FM/OOK/FSK/PSK-family classifier using envelope, kurtosis, and spectral-flatness features.
| Name | Required | Description | Default |
|---|---|---|---|
| source | No | last_loaded |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It mentions being rule-based and using specific features, but omits crucial details like required input format, output structure, or limitations. The tool's reliance on a loaded signal is only hinted at by the input schema.
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 a single, efficient sentence that covers the core purpose. However, it could be restructured to front-load the most important information (e.g., the classification action) and optionally include parameter guidance.
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?
Despite having an output schema, the description fails to explain prerequisites (e.g., need to load an IQ file first), acceptable values for 'source', or what the output classification looks like. The tool's context requires more completeness for effective use.
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 0%, and the description does not explain the 'source' parameter or its values. The description adds no meaning beyond the schema, leaving the agent without guidance on how to specify the input signal.
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 clearly identifies the tool as a modulation classifier using a specific algorithm and features. It distinguishes itself from sibling tools like compute_fft or render_spectrogram, which are not classifiers.
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 implies usage on a previously loaded signal via the 'source' parameter defaulting to 'last_loaded', but it does not explicitly state prerequisites or when to choose this over alternatives. No when-not-to-use guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Windowed FFT with configurable window (Hann/Hamming/Blackman) and zero-padding factor.
| Name | Required | Description | Default |
|---|---|---|---|
| n_fft | No | ||
| source | No | last_loaded | |
| window | No | hann | |
| zero_padding_factor | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It reveals configurability (window, zero-padding) but does not state side effects, prerequisites, or what happens to source data. The phrase 'last_loaded' is unexplained, and behavioral traits like non-destructive nature are absent.
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 a single sentence, front-loaded with purpose and key features, with zero wasted words. It is appropriately sized for its role.
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 4 parameters with 0% schema coverage, no annotations, and an existing output schema, the description is too sparse. It omits details about source parameter usage, how n_fft affects output, and does not clarify the computation context (e.g., real vs complex). An agent would need additional knowledge to use this tool correctly.
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 0%, so the description must compensate. It adds value for window (lists Hann/Hamming/Blackman) and zero-padding factor, but n_fft and source (which has a default 'last_loaded') are not explained. This provides partial but insufficient compensation.
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 explicitly states 'Windowed FFT with configurable window and zero-padding factor,' clearly identifying the verb (compute FFT) and resource (signal data) with specific configurables. It distinguishes from sibling tools like render_spectrogram and range_doppler_map which are higher-level or different algorithms.
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 implies usage when a plain FFT is needed, but lacks explicit guidance on when to use this tool versus siblings like render_spectrogram or range_doppler_map. No alternatives or when-not-to-use are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Saves an IQ segment slice directly to a local folder on the user's PC.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | sigmf | |
| filename | Yes | ||
| num_samples | No | ||
| start_sample | No | ||
| workspace_dir | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It states the tool saves to a local folder, but does not address potential side effects like file overwriting, permission requirements, or error handling. The behavior is minimally described.
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 a single, front-loaded sentence with no wasted words. It could be slightly more informative without losing conciseness, but it is efficient and directly states the main action.
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 has 5 parameters, no annotations, and a minimal description, the context is incomplete. Key details about parameter meanings, output expectations, and usage constraints are missing. The tool's complexity warrants a more comprehensive description.
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 0%, meaning no parameter descriptions exist in the schema. The description does not explain any of the five parameters (format, filename, num_samples, start_sample, workspace_dir), leaving the agent with no understanding of how to specify an 'IQ segment slice' or use defaults.
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 clearly states that the tool saves an IQ segment slice to a local folder. It uses a specific verb ('Saves') and resource ('IQ segment slice'), and distinguishes itself from siblings like export_plot and load_iq_file by specifying the output location and data type.
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?
No guidance is provided on when to use this tool versus alternatives such as export_plot or load_iq_file. It does not mention prerequisites (e.g., having an IQ segment loaded) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Saves any generated figure directly to a local folder on the user's PC.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | ||
| source_path | No | ||
| workspace_dir | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits like file overwriting behavior, permission needs, or expected folder structure. The description only states it saves to a local folder, omitting critical details for a write operation.
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 a single sentence, which is concise but too brief to cover necessary details. It lacks structure but does not waste words.
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 lack of schema descriptions, no annotations, and three parameters, the description is incomplete. It does not explain the output despite an output schema existing, and it fails to clarify the tool's behavior in different parameter configurations.
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 0% and the description does not explain the purpose of any parameters except implicitly 'filename'. The optional parameters 'source_path' and 'workspace_dir' are left entirely undefined, making correct usage difficult.
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 clearly states the action ('saves') and the resource ('generated figure') to a specific location ('local folder on user's PC'). However, it does not differentiate from the sibling tool 'export_iq_segment', which likely has a similar purpose.
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?
No guidance on when to use this tool versus alternatives like 'export_iq_segment'. No mention of prerequisites or context where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Constant-velocity Kalman tracker associating detections across sequential frames.
| Name | Required | Description | Default |
|---|---|---|---|
| detections | No | ||
| process_noise | No | ||
| measurement_noise | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It mentions constant-velocity but does not elaborate on limitations, state representation, multi-target handling, or output format, leaving significant behavioral gaps despite an existing output schema.
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 a single concise sentence but is arguably under-specified for the tool's complexity. It could include more detail without becoming verbose.
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 three parameters with no schema descriptions and an output schema omitted, the description fails to cover usage context or results, making it incomplete for an agent to invoke correctly.
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 0%, and the description fails to explain any parameter. 'detections' format, 'process_noise', and 'measurement_noise' are left undefined, forcing the agent to infer or guess their meaning.
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 clearly states it is a 'constant-velocity Kalman tracker' that 'associates detections across sequential frames,' which is specific and distinguishes it from sibling tools like 'ca_cfar_detect' or 'range_doppler_map' that focus on detection rather than tracking.
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?
No guidance is provided on when to use this tool versus alternatives, such as prerequisites (e.g., having detections from earlier tools) or scenarios where constant velocity assumption is inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enumerates attached SDR hardware and reports supported sample rates / tunable range.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully discloses behavior: it enumerates hardware and reports capabilities. This is a read-only operation with no side effects. It could be improved by mentioning driver requirements or that it's a query.
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?
Single sentence with no wasted words. Information is front-loaded and every part is essential. Highly concise.
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 zero parameters and existing output schema, the description is complete. It specifies the exact kind of information returned (supported sample rates and tunable range). No additional details needed.
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?
No parameters exist, so schema coverage is trivially 100%. Description adds no parameter info because none are needed. Baseline score of 4 is appropriate for zero-parameter tools.
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?
Description clearly states it enumerates attached SDR hardware and reports supported sample rates and tunable range, which is a specific verb and resource. It easily distinguishes from sibling tools like capture_from_sdr and compute_fft.
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 implies usage for discovering available devices and their capabilities before using other tools, but does not explicitly state when to use or provide exclusion conditions. Context is clear but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Loads .wav, .iq, .sigmf-data/.sigmf-meta, or .npy into a normalized IQBuffer.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| format | No | ||
| sample_rate | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description mentions 'normalized' but does not disclose read-only nature, error handling, or side effects. Insufficient for a tool with no annotation support.
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?
Single sentence, efficient and front-loaded. No redundant words, but could benefit from listing parameters briefly.
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?
With 3 parameters and no parameter documentation in description, the description does not fully equip an agent to use the tool correctly. Output schema exists but its content is unknown, so description should compensate more.
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 0%, yet description only lists file formats. Does not explain what the 'format' parameter does (auto-detect vs override) or the role of 'sample_rate' (e.g., for raw IQ). Adds minimal value beyond schema.
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?
Description specifies exact verb 'Loads' and resource types (.wav, .iq, etc.) and output 'normalized IQBuffer', clearly distinguishing from sibling tools like capture_from_sdr or compute_fft.
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?
No explicit guidance on when to use this tool versus alternatives like capture_from_sdr for live data or exports. Implied by sibling names but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cadence-spectrum periodicity extraction for rotor-vs-flutter style signature comparison.
| Name | Required | Description | Default |
|---|---|---|---|
| source | No | last_loaded |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It indicates a computational analysis (read-like) but does not mention side effects, permissions, computational cost, or whether it modifies state. The default parameter suggests it uses previously loaded data, but no details on dependencies or outcomes.
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 one sentence, front-loaded with the core action. However, it is overly terse and lacks structured details that would aid an agent without sacrificing efficiency.
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?
Despite an output schema being present, the description provides no context on the expected output or how the result relates to the input. For a specialized tool with domain jargon, more context (e.g., what a cadence spectrum is, what rotors vs flutters means) would improve completeness for an AI agent.
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 0%, and the description does not explain the only parameter 'source' (default 'last_loaded'). No insight into valid values, behavior when changed, or its impact on the extraction.
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 states the tool performs 'cadence-spectrum periodicity extraction' specifically 'for rotor-vs-flutter style signature comparison', clearly indicating the operation and context. It distinguishes itself from sibling tools like range_doppler_map or ca_cfar_detect by targeting periodic micro-Doppler signatures.
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?
No guidance on when to use this tool versus alternatives. It does not specify prerequisites, data requirements, or scenarios where it is applicable, leaving the agent to infer usage from the description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Adaptive Capon/MVDR beamformer with diagonal-loading stabilization for rank-deficient snapshots.
| Name | Required | Description | Default |
|---|---|---|---|
| source | No | last_loaded | |
| angles_deg | No | ||
| diagonal_loading | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It states the algorithm and stabilization technique but lacks details on side effects, output structure, or state changes.
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?
Single sentence containing all essential information without fluff, efficiently conveying the tool's nature.
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?
The description covers the algorithm but omits parameter guidance, usage context, and output details. Given three parameters and no annotations, it is insufficient for effective tool selection and 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?
Schema description coverage is 0%, and the description does not explain any parameter (source, angles_deg, diagonal_loading) beyond their names, failing to add meaning.
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 specifies the exact algorithm (Capon/MVDR) and a key feature (diagonal-loading stabilization for rank-deficient snapshots), clearly distinguishing it from sibling tools like compute_fft or range_doppler_map.
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?
No explicit when-to-use or alternatives are mentioned. The description implies it is for beamforming with diagonal loading, but does not guide the agent on scenarios or contrast with other signal processing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
2D windowed FFT (fast-time/slow-time) over a supplied RadarCube.
| Name | Required | Description | Default |
|---|---|---|---|
| source | No | last_loaded | |
| window | No | blackman | |
| bandwidth | No | ||
| center_freq | No | ||
| chirp_duration | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations. Description only hints at windowing but omits whether this is a destructive operation, if it returns a new object, and what the output represents. Without annotations, the agent lacks behavioral safeguards.
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?
Single sentence, no redundancy, front-loaded with key info. Highly efficient.
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 complex tool with 5 parameters and no annotations, the description is too sparse. Output schema exists but missing parameter explanations and usage guidance hurt completeness.
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?
None of the 5 parameters are described; schema provides defaults but no purpose. With 0% schema coverage, the description does not compensate, leaving the agent to guess.
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 specifies the operation ('2D windowed FFT') and the input resource ('RadarCube'), distinct from sibling tools like compute_fft (1D) or render_spectrogram (visualization).
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?
No usage context: does not state when to use versus alternatives (e.g., compute_fft for 1D), no prerequisites (RadarCube must exist), and no mention of parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
STFT spectrogram image with configurable frame size, hop, and dB dynamic range.
| Name | Required | Description | Default |
|---|---|---|---|
| n_fft | No | ||
| source | No | last_loaded | |
| window | No | hann | |
| hop_length | No | ||
| dynamic_range_db | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It states the output is an image but does not mention read-only nature, whether it is destructive, what happens if source data is not available, or any side effects. The default parameter 'source' (last_loaded) implies reliance on prior state but is not explained.
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?
Single sentence that is front-loaded with the core purpose and key parameters. No unnecessary words or redundancy.
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?
Despite having an output schema, the description does not explain return values, error conditions, or relationships to sibling tools like 'compute_fft' (which provides raw spectrum data) or 'render_waterfall' (similar visualization). Prerequisites (e.g., loaded IQ data) are implied by default but not stated.
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?
The description adds meaning for three parameters (n_fft as frame size, hop_length as hop, dynamic_range_db as dB dynamic range) but omits 'window' and 'source'. With 0% schema coverage, the description partially compensates but is incomplete, missing details on valid values or units.
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 clearly states it produces an STFT spectrogram image and lists key configurable parameters (frame size, hop, dB range). However, it does not differentiate from the sibling tool 'render_waterfall', which is also a visualization tool.
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?
No guidance on when to use this tool vs alternatives like 'render_waterfall' or 'compute_fft'. The description does not mention prerequisites (e.g., need to load data first) or conditions where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rolling PSD waterfall across N consecutive capture segments.
| Name | Required | Description | Default |
|---|---|---|---|
| n_fft | No | ||
| source | No | last_loaded | |
| colormap | No | viridis | |
| duration_s | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions 'rolling' and 'PSD waterfall' but does not explain data persistence, segment handling, or resource implications. More detail is needed.
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 a single terse sentence. While not verbose, it is under-specified and could benefit from more detail without becoming excessive.
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 four parameters, no annotations, and an output schema (content unknown), the description is incomplete. It does not explain the output, parameter behavior, or prerequisites, leaving significant gaps for an agent.
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 0%. The description does not explain any of the four parameters (n_fft, source, colormap, duration_s) or how they relate to the rolling waterfall. It adds no semantic value beyond the parameter names.
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 states it renders a rolling PSD waterfall across capture segments, which is specific and distinguishable from siblings like render_spectrogram. However, it is concise but clear.
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?
No guidance on when to use this tool versus alternatives such as render_spectrogram or range_doppler_map. The context includes many signal processing tools, but the description offers no selection criteria.
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.
v1.0.0ca_cfar_detectcapture_from_sdrclassify_modulationcompute_fftexport_iq_segmentexport_plotkalman_tracklist_sdr_devicesload_iq_filemicro_doppler_signaturemvdr_beamformrange_doppler_maprender_spectrogramrender_waterfallEach tool has a clearly distinct purpose in the signal processing pipeline, from device enumeration and IQ capture to advanced radar processing and export. No two tools overlap in functionality.
All tool names use lowercase with underscores and mostly follow a verb_noun pattern (e.g., load_iq_file, capture_from_sdr). A few names like range_doppler_map and micro_doppler_signature are noun-heavy, but the overall style is consistent and predictable.
14 tools cover the essential capabilities for an SDR server without being excessive. Each tool serves a specific, non-redundant function, and the count is appropriate for the scope.
The set covers acquisition, analysis (FFT, spectrogram, waterfall, radar processing, classification, tracking), and export. While basic filtering or demodulation tools are missing, the surface is comprehensive for typical SDR and radar workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Create RF signal projects from prompts, inspect graphs, and export IQ data.
Real-time planetary signal engine and Model Context Protocol (MCP) server for autonomous AI agents.
OCR, transcription, file extraction, and image generation for AI agents via MCP.
Deterministic reasoning stack for AI agents: simulate, decide & compute, plus cross-domain tools.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/IamOumarIbrahim/SpectraMCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server