Skip to main content
Glama

signal_hunt

Find and rank signals in receiver audio like a contest operator, prioritizing steady CQ callers, and return frequency, mode, strength, persistence, and modem to tune.

Instructions

Find and name the signals in the receiver audio and rank them the way a contest operator reads the waterfall: the station that sits still and calls CQ scores highest.

method 'audio' (default): tap seconds of audio from the input device (FLDIGI_AUDIO_DEVICE, the device fldigi listens on; or device as a name substring or index; wav analyses a file instead). Needs the optional extra: pip install 'fldigi-mcp[hunt]'. method 'devices': list the input devices the tap can open. method 'browser': read fldigi's Signal Browser (needs the browser patch, see the browser tool): one candidate per channel the decoder bank holds, with its text, for the current modem family (PSK, RTTY or CW). Finds stations the spectrum analyser ranks near the floor, but names no mode: it reports what fldigi is set to. method 'api': blind fallback with no audio access; steps modem.search_up across the passband for each modem (mode='RTTY,BPSK31,...') and reads modem.get_quality. Slow.

Each candidate carries carrier_hz, mode (RTTY with shift, CW, BPSK31/63/125, Olivia with tones and bw, MFSK16, DominoEX, MT63, or unknown), db_over_floor, persistence (fraction of the window it was present), periodicity (a CQ loop repeats), score, and fldigi_modem, the name tune_to needs. Nothing here transmits.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
topNo
wavNo
modeNo
deviceNo
methodNoaudio
secondsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.3.1

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden, and it is transparent: 'Nothing here transmits', browser only reports what fldigi is set to and names no mode, api is slow, and each candidate's fields are enumerated. This gives an agent accurate expectations without needing annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but dense and front-loaded with the core purpose. Each method and output field earns its place, though the prose-heavy format could be slightly more scannable with bullets or explicit parameter labels.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and no output schema, the description is remarkably complete: it covers all modes of operation, return-value shape, dependencies, and behavioral caveats. Missing details are limited to the top parameter and some error/edge-case behavior, which prevents a perfect score.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains method, device, seconds, wav, and partially mode via the api example, but never defines the top parameter or clarifies how mode behaves for the audio and browser methods. This is a minor gap in an otherwise strong explanation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Find and name the signals in the receiver audio and rank them...'. It also clarifies the ranking rationale with the contest-operator waterfall analogyтные and distinguishes methods so an agent can infer what the tool does relative to siblings like browser and tune_to.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Each method is given an explicit context: audio is the default, devices lists input devices, browser is for near-floor stations that the spectrum analyser misses, and api is a blind fallback with no audio access. It also states prerequisites such as the optional 'hunt' package and the browser patch, and notes that api is slow.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.