io.github.qso-graph/pota-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| POTA_MCP_MOCK | No | Set to 1 to mock the POTA API for testing without network. | 0 |
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": true
} |
| logging | {} |
| prompts | {
"listChanged": true
} |
| resources | {
"subscribe": false,
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_version_infoA | Get pota-mcp service version and upstream spec version. Returns the running PyPI version of pota-mcp and the POTA API revision currently 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. |
| pota_spotsA | Get current POTA activator spots. Returns live spot feed with park details, grid squares, and coordinates. All filters are optional — omit to get all active spots. |
| pota_park_infoC | Get detailed park information by POTA reference code. |
| pota_park_statsB | Get activation and QSO counts for a POTA park. |
| pota_park_activationsA | List recent activations of a POTA park, most recent first. Answers "when was this park last activated?" and "is it often on the air?". |
| pota_park_leaderboardA | Top activators and hunters of a POTA park. Three boards: most activations, most QSOs as an activator, most QSOs as a hunter. Each row is a callsign and a count and nothing else. |
| pota_user_statsA | Get POTA activator and hunter statistics for a callsign. |
| pota_scheduledA | Get upcoming scheduled POTA activations. All filters are optional and combine with AND — omit them all and the whole schedule comes back, as before. |
| pota_location_parksA | List all POTA parks in a state, province, or country. |
| pota_nearby_parksA | Find POTA parks near a geographic point. Fetches all parks in the given location and filters by distance. Useful for finding 2-fer candidates near an activation site. |
| pota_rare_parks_nearA | Find the least-activated POTA parks near a point. Answers "which parks near me have never, or rarely, been activated?" — for an activator looking for something unworked, or a hunter looking for a rare one. Least activated first, nearest first among equals. |
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 11 tools
Most tools cleanly target distinct Park/User/Activity/Spot/Schedule resources. The only meaningful overlap is pota_nearby_parks vs pota_rare_parks_near, which the latter's description explicitly refines (rarity-filtered subset), and pota_park_activations vs pota_spots/pota_scheduled which differ by time frame.
Ten of eleven tools follow a consistent pota_<resource> snake_case convention. get_version_info breaks the prefix pattern, though it is a service-level meta tool and its name is still clear and predictable in style.
Eleven tools is well-scoped for a POTA domain covering parks, activations, spots, schedules, users, and leaderboards. Each tool has a distinguishable job and none appear redundant.
Coverage spans discovery (location, nearby, rare), live/scheduled activity, historical activations, stats, and leaderboards, plus a version tool. Minor gaps remain: no lookup by park name or callsign-driven park listing, and no per-activation QSO detail, but core activator/hunter workflows are supported.