wspr-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.3.2
Disambiguation5/5
Each tool targets a unique aspect of WSPR data: version, band activity, grid activity, propagation paths, SNR trends, raw spots, and top stations. No two tools have overlapping purposes, and descriptions clearly differentiate them.
Naming Consistency5/5
All tool names follow a consistent pattern: 'wspr_' prefix followed by a descriptive noun phrase in snake_case (e.g., wspr_band_activity, wspr_grid_activity). get_version_info is the only exception but uses a standard verb_noun pattern.
Tool Count5/5
With 9 tools, the server is well-scoped for WSPR data retrieval. Each tool serves a distinct analytical need without overwhelming the agent with too many options.
Completeness4/5
The tool surface covers core WSPR query operations: activity by band/grid, propagation analysis, spots, and top stations. Minor gaps exist (e.g., no tool for aggregated statistics or historical comparison), but it covers the main use cases.
Average 3.9/5 across 9 of 9 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under GPL 3.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions that WSPR beacons transmit every 2 minutes and spots represent 2-minute integrations, but does not disclose other behaviors such as data freshness limits, pagination behavior, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences that directly state the purpose and add key context about WSPR spots. No redundant information; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters and an output schema (not shown), the description does not explain return values or typical usage patterns. It provides basic context but lacks guidance on how to interpret spots or combine filters. Adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters have descriptions in the schema. The description adds no additional meaning beyond the schema; it only restates the tool's purpose. Baseline 3 is appropriate.
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 clearly states 'Get recent WSPR spots', specifying the verb and resource. Additional context about WSPR beacon transmission intervals and integration periods distinguishes it from sibling tools like wspr_band_activity or wspr_grid_activity, which aggregate spots differently.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or compare with sibling tools, leaving the agent to infer usage from the name and parameter schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description carries full burden. Only states the tool is for reading longest paths but omits any behavioral traits like cost, caching, or side effects. Minimal transparency beyond purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences. First directly states purpose, second adds relevant context about WSPR's significance. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has 4 optional parameters, output schema exists. Description covers purpose but lacks behavioral context (e.g., whether the tool is expensive). Adequate but not comprehensive for a complex radio propagation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 4 parameters with descriptions (100% coverage). Description adds no extra semantic meaning; it only mentions 'time window' which is already in schema. Baseline 3 applies.
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?
Description clearly states 'Get the longest WSPR paths in the given time window.' Verb 'get' and resource 'longest paths' are specific. Distinguishes from siblings like wspr_spots or wspr_propagation by focusing on longest paths.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for detecting band openness via long paths ('Long paths here prove the band is open'), but no explicit comparison to sibling tools or when-not-to-use. Agent must infer context from WSPR significance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of transparency. It explains the ranking criteria (spot count, max distance) but does not disclose behavioral traits such as whether results are live cached, what time window is used (beyond the hours parameter), or how ties are handled. It is adequate but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: two sentences front-load the action and value. Every sentence is purposeful with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, an output schema, and sibling tools, the description covers the core purpose but lacks details on result behavior (e.g., pagination, empty results, ordering ties). It is minimally complete for a simple tool but could be more informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100%, so parameters are well documented. The description adds minimal semantic context beyond the schema (e.g., 'ranked by spot count or max distance' reinforces the sort_by parameter). It does not introduce new meaning or clarify format or units.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves top WSPR transmitters ranked by spot count or max distance. It mentions 'beacon operators', distinguishing from sibling tools like 'wspr_top_spotters' which likely focus on spotters. However, it does not explicitly differentiate from 'wspr_spots' or other related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a general use case ('finding who's putting out a big signal on a band') but lacks explicit guidance on when to use this tool versus alternatives like 'wspr_top_spotters' or 'wspr_spots'. No when-not-to-use or comparative context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. Mentions 'summary stats and recent spots' but does not explicitly state read-only nature, safety, or other behavioral traits. Adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is very concise: three sentences, front-loaded with main purpose, no unnecessary words.
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 presence of output schema and 4 parameters, description covers the key usage (grid format, summary/spots) but could elaborate on other parameters (band, hours, limit) or provide examples. Still reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are well-documented in schema. Description adds no additional meaning beyond what schema already provides (e.g., grid format advice is already in schema description). Baseline score of 3 is appropriate.
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?
Clearly states the tool retrieves WSPR activity for a grid square, using specific verbs ('Get all') and resource ('Maidenhead grid square'). Differentiates from sibling tools (wspr_band_activity, wspr_spots) by focusing on grid-based queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on grid format choice (2-char vs 4-char) for wide vs specific regions. However, does not explicitly contrast with sibling tools or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that it searches both directions automatically and returns specific statistics, but lacks details on data recency, rate limits, or potential limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (under 50 words) with front-loaded purpose. Every sentence adds value, and there is no redundant or filler content.
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 the existence of an output schema (not shown) and 4 parameters, the description covers the main inputs, outputs, and key behavior (bidirectional search). It is sufficiently complete for an agent to understand the tool's function, though the time window parameter could use a brief mention.
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 coverage is 100%, and the description adds value by mentioning that it accepts callsigns or grid squares (already in schema) and notably states 'Searches both directions automatically,' which clarifies behavior beyond the schema.
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 clearly states it gets WSPR-derived propagation between two locations, listing specific outputs (bands, spot counts, SNR stats, hours). It distinguishes from sibling tools (e.g., wspr_spots, wspr_band_activity) by focusing on propagation between two endpoints and mentioning bidirectional search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains it accepts callsigns or grid squares, giving clear context for use. However, it does not provide explicit guidance on when not to use it or compare to alternatives, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations available, so description carries full burden. It describes a read operation ('Get') and ranking criteria, but lacks details on data freshness, rate limits, or any side effects. Adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states core purpose, second elaborates on utility. No redundant words, every sentence adds value.
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?
With an output schema present, the description need not explain return values. It covers purpose, usage, and parameter context sufficiently for an agent to select and invoke the tool, though could hint at data source or recency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already documented. The description adds broad context about ranking (sort_by) but does not provide additional semantic detail beyond what the schema offers.
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?
Description starts with 'Get top WSPR receivers' specifying a clear verb and resource, and mentions ranking by spot count or max distance, distinguishing this from sibling tools like wspr_spots or wspr_top_beacons.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Useful for finding good receivers to monitor for propagation,' giving clear use case guidance. However, it does not explicitly state when not to use or name alternatives, though sibling context provides differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It clearly states the tool reads historical data ('Get SNR trend over time') and returns 'hourly SNR buckets'. No destructive or auth details are needed for this read-only tool, and the description adequately discloses its non-mutating nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no wasted words. The first sentence immediately states the core purpose, followed by concise elaboration. Perfectly front-loaded and efficient.
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?
The tool has an output schema (not shown), so explanation of return values is not required. The description covers the main intent and usage scenarios adequately. Minor omission: no mention of pagination or data format, but the output schema likely covers that. For a simple parameter set, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already provides clear descriptions for each parameter (e.g., 'First endpoint — callsign or grid'). The description adds overall context by explaining the 'path between two endpoints' but does not add per-parameter details beyond the schema. Baseline 3 is appropriate for high coverage with minimal extra value.
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 uses a specific verb-resource combination ('Get SNR trend over time for a specific WSPR path') and distinguishes the tool from siblings like wspr_spots or wspr_band_activity by focusing on trend analysis for a specific path. This leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear use cases ('seeing when a band opens and closes on a specific path, and how signal strength varies over time'). While it does not explicitly state when not to use or mention alternatives, the context from sibling tools helps; however, an explicit when-not would elevate this score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It clearly describes a read-only summary operation with no side effects. Could mention data source or limits, but the behavior is transparent enough for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences: purpose statement, list of outputs, and a usage hint. No redundant words, front-loaded with key information. Excellent conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter and an output schema (not shown but exists), description lists all output fields (spot counts, station counts, distance, SNR). Adequate for an agent to understand expected results without needing the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter 'hours' with 100% schema description coverage (time window, range, default). Description does not add extra meaning beyond what the schema provides, so score is baseline 3.
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?
Description explicitly states 'Get per-band WSPR activity summary' with specific details (spot counts, station counts, distance, SNR). The closing sentence 'best indicator of which bands are open right now' distinguishes it from sibling tools like wspr_grid_activity or wspr_longest_paths.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: 'best indicator of which bands are open right now' implies when to use. However, no explicit guidance on when not to use or alternatives among siblings. Still, the description helps an agent decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description fully discloses behavior: it is a read-only operation that returns specific fields (service_name, service_version, spec_version). No destructive or complex side effects are implied.
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 relatively concise, with a clear front-loaded statement and an additional paragraph explaining the use case. It could be slightly tighter, but it earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and an output schema implied by 'Returns:', the description covers all needed aspects: what it does, why to use it, and what it returns. It is complete for a simple utility tool.
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?
The input schema has zero parameters, so the baseline is 4. The description adds value by explaining the return fields and purpose, but no parameter details are needed.
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 clearly states it retrieves wspr-mcp service and upstream spec version, with specific verbs 'Get' and 'Returns'. It distinguishes from sibling tools that focus on wspr data like band activity or spots.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use for confirming fleet alignment and detecting drift across MCP deployments. It does not mention when not to use, but given its simplicity and lack of sibling overlap, this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![wspr-mcp MCP server](https://glama.ai/mcp/servers/qso-graph/wspr-mcp/badges/card.svg)](https://glama.ai/mcp/servers/qso-graph/wspr-mcp)

Score Badge

Copy to your README.md:

[![wspr-mcp MCP server](https://glama.ai/mcp/servers/qso-graph/wspr-mcp/badges/score.svg)](https://glama.ai/mcp/servers/qso-graph/wspr-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/qso-graph/wspr-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server