io.github.sbrunner-atx/wsjtx-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| WSJTX_HOST | No | UDP address to bind/listen on. | 127.0.0.1 |
| WSJTX_PORT | No | WSJT-X UDP Server port. | 2237 |
| WSJTX_CALLSIGN | No | Operator callsign — the single transmit gate. Blank = receive-only. | |
| WSJTX_INSTANCE | No | Target a specific WSJT-X Id when several instances broadcast. | |
| WSJTX_MULTICAST | No | Optional multicast group to join (coexist with other UDP consumers). |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| statusA | Latest WSJT-X state snapshot plus listener/connection health. Returns the most recent If no |
| diagnosticsA | Host + network + listener diagnostics for troubleshooting connectivity. Does NOT command WSJT-X. Reports the resolved WSJTX_HOST/PORT, whether the UDP listener is bound (and any bind error), datagram counts by message type, the discovered instances, the transmit-gate state, and this host's network interfaces — so you can tell whether this process can even receive WSJT-X's broadcasts (e.g. host-side vs. sandboxed, or a port already owned by JTAlert / GridTracker). |
| decodesA | The RX data plane: buffered operations:
Each decode carries: kind (decode/wspr), New, time, snr, delta_time,
delta_frequency, mode, message, low_confidence, off_air, and a |
| logA | Read buffered completed QSOs ( Observe-only: WSJT-X emits these when the operator accepts its "Log QSO" dialog. Each entry has the structured QSO record (call, grids, frequency, mode, reports, times, exchanges, propagation mode) and the one-record ADIF document — ready to forward to N3FJP via contest-mcp. |
| replyA | Answer a buffered decode — initiates a transmission (gated by callsign). Equivalent to double-clicking that decode in the Band Activity window. WSJT-X only acts if the message exactly matches a prior decode that is a CQ or QRZ. If WSJT-X's "Auto Seq" is on (the usual FT8/FT4 default) it then sequences the rest of the QSO to completion on its own; if Auto Seq is off this starts only the first transmission (Auto Seq is a UI setting, not UDP-controllable). Identify the decode by |
| free_textA | Set the free-text (Tx5) message; with Setting the text alone (send=false) is safe and always allowed. With
send=true the message is transmitted — that keys the radio, so it requires
WSJTX_CALLSIGN. An empty |
| transmitA | Stop transmitting. (WSJT-X's UDP protocol can halt but cannot enable Tx.) operations:
Always allowed — halting only ever takes you off the air. To start a
transmission use |
| configureA | Set operating parameters via a Sets: mode, submode, frequency tolerance, fast mode, T/R period, Rx DF, DX
call, DX grid, and whether to regenerate the standard messages. Empty string
= "no change" for text fields; IMPORTANT caveats:
|
| clearC | Clear a WSJT-X decode window (no transmit). window: 'band' (Band Activity, default), 'rx' (Rx Frequency), or 'both'. |
| highlightA | Colour (or clear) a callsign in the Band Activity panel (no transmit). operations:
Keep the number of active highlights modest (a rough cap of ~100) so WSJT-X decoding performance isn't impacted. |
| locationA | Override the session Maidenhead grid (4- or 6-character). No transmit. Session-lifetime only — does not change the persistent setting. Intended for mobile/portable operation where the grid changes during a session. |
| switch_configA | Switch WSJT-X to a named configuration (which must already exist). No transmit. |
| annotateA | Set a Fox/Hound sort-order annotation for a DX call (no transmit). Niche DXpedition feature (AnnotationInfo): lets a server "score" callers so
the Hound queue can be sorted by it. |
| wsjtx_callA | Escape hatch: build and send any WSJT-X message type by name.
The same transmit gate applies: a keying message — |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 14 tools
Most tools map to distinct WSJT-X actions, and the descriptions are detailed enough to avoid confusion in normal use. The main risks are the generic wsjtx_call escape hatch, which overlaps with several specific tools, and the 'transmit' tool, whose name suggests starting transmission but actually halts it.
Tool names are readable and consistently snake_case, but there is no uniform verb_noun pattern: some are nouns (status, decodes, log), some are single verbs (reply, clear, configure), and some are phrases (switch_config, free_text). The 'transmit' name is also semantically inverted from the action it performs.
Fourteen tools is within the well-scoped range for a WSJT-X control server. Each tool covers a distinct functional area, and the generic wsjtx_call fills protocol-level gaps without making the set feel bloated.
The set covers the core WSJT-X UDP workflow: reading status, decodes, and logged QSOs; replying to calls; sending free text; halting TX; configuring; clearing; highlighting; switching configurations; and annotating calls. Minor gaps exist around dial-frequency control and enumerating configurations, but the wsjtx_call escape hatch and external rig control provide workarounds.