Skip to main content
Glama
qso-graph

n1mm-mcp

by qso-graph

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
N1MM_MCP_MOCKNoSet to 1 to run in mock mode for testing without N1MM.

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

CapabilityDetails
tools
{
  "listChanged": true
}
logging
{}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}

Tools

Functions exposed to the LLM to take actions

NameDescription
get_version_infoA

Get n1mm-mcp service version and upstream UDP contract version.

Returns the running PyPI version of n1mm-mcp and the N1MM Logger+ UDP broadcast contract revision in use. Use this to confirm fleet alignment across MCP deployments — agents can compare service_version and spec_version across servers to detect drift without going outside the MCP protocol.

Note: n1mm_diagnostics remains the canonical health probe (heartbeat, parse errors, memory). get_version_info is a lighter-weight identity attestation that succeeds even when N1MM isn't broadcasting.

Returns: service_name, service_version (PyPI), and spec_version (UDP contract).

n1mm_current_stateB

Complete station snapshot — connection, contest, operator, radios.

Returns connection status, contest info, operator callsign, and full radio state for Radio 1 (and Radio 2 if SO2R). This is the first tool any AI session should call.

n1mm_lookupB

Pre-log callsign lookup — THE Contest-Copilot trigger.

Fires when operator types a callsign and presses spacebar in N1MM. Returns the lookup data plus current band/mode from RadioInfo. Check lookup_age_ms — if >30000, the advice window has closed.

n1mm_contactsB

QSO log — recent contacts, edits, and deletes.

Returns the last QSO, filtered recent QSOs, recent edits, and recent deletes in one coherent snapshot.

n1mm_bandmapA

Live bandmap — spots, mult targets, and activity summary.

Returns active spots (with TTL eviction), unworked multipliers, and per-band spot activity counts in one snapshot.

n1mm_performanceB

Complete performance snapshot — score, rate, bands, run/S&P, timeline.

Returns score, rolling rates (10m/30m/60m), rate derivative for band exhaustion detection, per-band breakdown, per-mode breakdown, hourly summary, and run vs S&P stats in one coherent view.

n1mm_multipliersB

Multiplier status — worked mults, mult map, and available needs.

Returns total mults worked, per-band mult grid, unworked mults currently spotted, and mult value analysis.

n1mm_clockC

Contest clock — timing, off-time, and pacing in one view.

n1mm_diagnosticsB

Server health and diagnostics — connection, parse errors, memory.

Essential for production debugging. First tool to call when something goes wrong during a contest.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

B3.4/5.0

Scored across 9 tools

Disambiguation4/5

Most tools target distinct resources (contacts, bandmap, clock, lookup), but multiplier data bleeds across three tools: n1mm_bandmap (unworked mults), n1mm_performance (per-band breakdown), and n1mm_multipliers. The status trio of get_version_info, n1mm_current_state, and n1mm_diagnostics also overlap somewhat, though descriptions explicitly differentiate version attestation vs health probe vs full snapshot.

Naming Consistency3/5

Eight tools share an n1mm_ prefix but are bare noun phrases (n1mm_clock, n1mm_bandmap), while get_version_info drops the prefix entirely and is the only verb_noun name. Readable, but the convention is noticeably mixed across the set.

Tool Count5/5

Nine tools is well-scoped for a contest-station monitoring server, and each tool maps to a coherent domain area (state, contacts, bandmap, performance, multipliers, clock, health, identity). No tool appears redundant enough to remove.

Completeness4/5

The monitoring surface is comprehensive — live state, log, spots, rates, mults, clock, and diagnostics all covered. It is essentially read-only, with no control/write operations (e.g. logging a QSO, tuning radio, posting a spot), which is a modest gap if agents are meant to act rather than observe.

Maintenance

ActivityNo data
ResponsivenessNo issues