fldigi-mcp

Server Quality Checklist

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

Latest release: v0.1.4
Disambiguation5/5
Each tool targets a distinct aspect of fldigi operation: process control, band guidance, UI controls, diagnostics, frequency, logging, modem, NAVTEX, rig control, spotting, status, text buffers, transmit, and weather fax. Even tools like 'text' and 'transmit' are clearly separated: text only stages/stores text, while transmit actually keys the radio. The escape hatch 'fldigi_call' is explicitly for methods not covered elsewhere, further reducing ambiguity.
Naming Consistency4/5
Tool names are single lowercase nouns or noun phrases (e.g., 'band_guidance', 'fldigi_call', 'wefax'), consistent in style. However, operations within tools vary (get/set/toggle vs. list vs. run), but the tool-level naming is predictable and readable. The lack of a strict verb_noun pattern is a minor deviation from ideal consistency.
Tool Count5/5
With 15 tools, the server is well-scoped for the fldigi domain. Each tool covers a logical subset of functionality, and none feel extraneous. The count is within the ideal range (3-15) and matches the complexity of a digital modem application.
Completeness4/5
The tool set covers the core fldigi workflows: launching, frequency/modem/rig control, logging, spotting, transmitting, and receiving. Minor gaps exist (e.g., audio device configuration), but the 'fldigi_call' escape hatch allows calling any XML-RPC method, ensuring no dead ends. Overall, the surface is quite complete for common tasks.
Average 3.2/5 across 15 of 15 tools scored. Lowest: 2.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 14 commits in the last 12 weeks
- Last stable release on July 31, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
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?
The description notes that send_message is 'callsign-gated', a useful behavioral trait. However, without annotations, it fails to disclose other important behaviors such as blocking behavior of get_message, potential side effects, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but poorly structured: uses line breaks and inconsistent formatting (e.g., 'NAVTEX / SitorB mode' followed by a period, then a list). It could be more concise and better organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, yet the description fails to cover essential details like return values, error handling, or prerequisites. For a tool with two operations and two parameters, this is severely incomplete.
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?
With 0% schema coverage, the description compensates partially: it explains that for get_message 'value' is timeout seconds, and for send_message 'value' is text. However, it does not describe the 'operation' parameter's possible values or format beyond listing them in the text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description mentions NAVTEX/SitorB mode and lists two operations (get_message, send_message), giving a general sense of purpose. However, it lacks a clear verb+resource statement (e.g., 'Manage NAVTEX messages') and does not differentiate well from siblings like 'fldigi_call', 'modem', or 'text'.
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?
No guidance on when to use this tool vs alternatives (e.g., when to choose get_message vs send_message, or when to use another sibling). There are no explicit usage conditions or exclusions.
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 are provided, and the description does not disclose any behavioral traits such as whether operations are destructive, require authentication, or have side effects. The listed operations suggest configuration and reporting, but this is inferred rather than stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and to the point, but it is not well-structured. It uses periods and line breaks in a way that could be clearer. It is concise but lacks organization.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description is incomplete. It does not explain what each operation does, what the return values are, or any potential side effects. The tool's complexity (multiple operations) demands more detail.
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?
The description adds some meaning to the parameters by indicating that 'value' is a bool for 'set_auto'. However, it does not explain the 'value' parameter for other operations, and the schema coverage is 0%, so the description only partially compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description mentions 'Spotting / PSK Reporter' and lists operations, giving a general idea of the tool's domain. However, it lacks a clear verb-resource statement and does not fully explain what 'spotting' entails, leaving some ambiguity.
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?
No guidance is provided on when to use this tool versus sibling tools like 'frequency' or 'log'. The description does not state any prerequisites or context, leaving the agent without decision support.
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?
Without annotations, the description carries the full burden. It mentions that stop/terminate can save log/macros and fall back to ending a process this server started, but lacks details on side effects, permissions, or state changes (e.g., what happens if launch is called while already running).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise but could be more structured. It front-loads the purpose and lists operations, but the parameter explanation is embedded in a sentence about stop/terminate, making it less clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and low parameter coverage, the description is incomplete. It lacks information on return values, error conditions, prerequisites (e.g., is fldigi must be installed?), and how to handle failed operations. The agent would struggle to use the tool correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% coverage, so the description must explain parameters. It names operations in text but does not enumerate the exact string values for the 'operation' parameter. 'save_log' and 'save_macros' are implied in the stop/terminate description but not explicitly tied to parameter names or behaviors.
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 manages the fldigi program and its process, listing specific info and process operations. However, it does not explicitly differentiate from sibling tools like controls or diagnostics, which might also interact with fldigi.
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?
No guidance is provided on when to use this tool versus alternatives. The description lists operations but does not specify scenarios or prerequisites, leaving the agent to infer usage.
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 are provided, so the description must cover behavioral aspects. It mentions 'operations' implying both read and write capabilities (get/set/toggle), but does not describe side effects, idempotency, or safety implications (e.g., whether toggling AFC affects other settings).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph. It front-loads the purpose and lists operations efficiently, but could benefit from structured formatting (e.g., bullet points) to improve readability. It is not overly long but feels cramped.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, 2 parameters (one undocumented), and 14 sibling tools, the description is incomplete. It does not explain return values, error conditions, or the role of the 'value' parameter. The agent lacks critical context to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It enumerates valid values for 'operation' in a list, which adds meaning beyond the schema's empty description. However, it fails to describe the 'value' parameter at all, leaving its type and allowed values ambiguous.
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 the tool's domain: fldigi operating controls and status, and lists specific operations. It distinguishes the tool from general-purpose tools but does not differentiate from sibling tools that may also relate to fldigi, such as 'fldigi_call' or 'frequency'.
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 lists operations but provides no guidance on when to use this tool versus alternatives, nor when to use specific operations. Sibling tools are listed but not differentiated, leaving the agent to infer usage context without explicit direction.
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?
With no annotations, the description fails to disclose behavioral traits such as side effects, required permissions, or safety. It mentions 'set' operations implying mutation but offers no warnings.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is an unstructured list of operations, not a concise statement. It lacks clear organization and repeats nouns unnecessarily.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (many sub-operations) and lack of output schema, the description is severely incomplete. It does not explain return values, error conditions, or the effect of each operation beyond naming.
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?
The description partially adds meaning by listing example values for 'set' (e.g., 'BPSK31'), but does not explain the 'value' parameter for other operations. Schema coverage is 0%, so the description adds some value but not enough.
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 indicates the tool deals with modem operating modes and settings, and lists specific operations. It differentiates from sibling tools which cover other aspects like frequency or rig control.
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?
No guidance is provided on when to use this tool or when to avoid it. The description lists operations but does not explain context or alternatives.
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 are provided, so the description must carry this burden. It lists operations like 'take_control' and 'release_control' but doesn't disclose whether any are destructive, require permissions, or have side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short but is a run-on list of operations without clear structure. It could be more organized but is not excessively long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, annotations, and 0% parameter coverage, the description should provide more details on return values, operation-specific inputs, and behaviors. It lacks completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description lists operation names but does not explain the 'value' parameter for each operation. While it adds some meaning, it's insufficient for an agent to know how to construct valid inputs.
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 explicitly states it's for rig control and lists many operations (get/set frequency, mode, etc.), so the resource and actions are clear. However, it lacks a concise summary and is a bit messy.
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?
No guidance on when to use this tool versus siblings like 'frequency' or 'controls'. The list of siblings includes similar-sounding tools, but no differentiation is provided.
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?
With no annotations, the description carries full burden but only lists operations. It fails to disclose side effects (e.g., whether setting frequency affects other settings), permissions needed, or error behavior, providing minimal transparency.
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 concise, listing operations in a compact format. It avoids redundancy but could benefit from slight restructuring (e.g., separating frequency and sideband concerns) for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters, multiple operations, and no output schema, the description is incomplete. It omits return values, success/failure indicators, and examples, leaving many usage questions unanswered.
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 0%, so description must compensate. It explains that 'value' is in Hz for set/increment operations and 'USB' or 'LSB' for set_sideband. However, it does not fully clarify the 'operation' parameter's enumerated values or provide format constraints.
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 the tool handles RF frequency and waterfall sideband, listing specific operations (get, set, increment, get_sideband, set_sideband). This distinguishes it from sibling tools like rig or controls by focusing on frequency and sideband control.
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?
No guidance is provided on when to use this tool vs alternatives, nor any conditions for when not to use it. The description simply lists operations without context.
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?
With no annotations, the description bears full responsibility for behavioral disclosure. It only reveals that 'send_file transmits and is callsign-gated,' but omits effects, permissions, or side effects for other operations. This is insufficient 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with a front-loaded header. The list structure is functional but could be more readable (e.g., with line breaks). Every sentence adds value, though some operations lack context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10+ operations, 2 params, no output schema), the description is incomplete. It omits operation details, return values, prerequisites, and error conditions, making it insufficient for reliable agent usage.
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 0%, so the description must compensate. It partially clarifies the 'value' parameter for set_adif_log, set_max_lines, get_received_file, and send_file. However, it does not describe the 'operation' parameter values beyond listing names, leaving meaning ambiguous.
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 states 'WEFAX (weather fax) mode' and lists operations, clearly indicating the tool's domain. However, it does not explicitly differentiate from sibling modes like navtex, which could cause confusion for agents.
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?
No guidance is provided on when to use this tool versus alternatives. The description lacks context on prerequisites, exclusions, or typical scenarios, leaving the agent to infer usage from the operation list.
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?
The description discloses that add_tx does not transmit, a key behavioral trait. It also enumerates valid operations. However, it does not explain the effects of clear_rx, clear_tx, or the return values of get_* operations. With no annotations, the description carries the full burden and only partially meets it.
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 concise, with three sentences covering the purpose, operation list, and a critical behavioral note. It is front-loaded and avoids unnecessary detail, though the list format could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/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 (0% schema coverage), no output schema, and no annotations, the description is insufficiently complete. It explains the 'operation' parameter but omits descriptions for other parameters and return values. More detail is needed for a tool with this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It lists valid operation values (e.g., read, add_tx, clear_rx), which adds meaning to the 'operation' parameter. However, it provides no explanation for the 'start', 'value', or 'length' parameters, leaving their semantics unclear.
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 states the tool is for 'RX/TX text and data' and lists specific operations (read, clear_rx, add_tx, etc.), which conveys the core purpose. However, it does not explicitly differentiate from sibling tools like 'transmit' or 'controls', leaving some ambiguity about when to use this tool.
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 includes a critical note that 'add_tx only stages text; it does not transmit', which provides usage guidance for that operation. However, there is no general statement about when to use this tool versus alternatives, and the purpose of other listed operations is implied rather than explicitly stated.
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 are provided. The description does not disclose side effects, permissions, or whether the tool is read-only. It only describes the output snapshot without behavioral context.
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?
One short sentence that conveys the tool's output efficiently. No unnecessary words or repetition. Perfectly concise.
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 no output schema and no annotations, the description lists output fields but lacks types or value ranges. It provides a reasonable idea of what the tool returns but could be more detailed for an unparameterized 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?
There are zero parameters, so the input schema fully defines all parameters. The description adds no parameter info because none is needed. Baseline 4 for 0-parameter tools is appropriate.
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 provides a 'Snapshot' of specific status fields (version, modem, frequency, TX/RX state, etc.), making the purpose evident. It distinguishes itself from sibling tools like 'frequency' or 'modem' by being a composite view, though not explicitly.
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?
No guidance on when to use this tool versus alternatives. No mention of prerequisites, context, or when not to use it. The description only lists output fields.
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?
The description discloses that keying operations require a configured callsign and that rx/abort/disable_tx are always allowed (taking station off air). It also notes that 'send' auto-returns to receive. However, it omits error scenarios, rate limits, or other side effects.
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 concise, using two sentences. It front-loads the purpose ('Transmitter control') and then lists operations and key constraints. The list format is somewhat messy but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (multiple operations, 4 parameters, no output schema or annotations), the description lacks detail on what each operation does exactly, error conditions, return values, and the type of 'value' parameter. It leaves many gaps for the agent.
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 description adds significant meaning beyond the input schema by listing operation values (tx, tune, etc.), explaining that for run_macro the parameter 'value' is an id, and for 'send' the parameter 'text' is used. It also clarifies the default behavior of 'return_to_rx'. Schema coverage was 0%, so this is valuable.
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 states 'Transmitter control' and lists specific operations (tx, tune, rx, etc.), clearly indicating what the tool does. It distinguishes itself from sibling tools by focusing exclusively on transmitter operations.
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 provides minimal guidance on when to use this tool versus alternatives. It mentions that keying operations require a configured callsign, but does not compare with sibling tools like 'controls' or 'modem' to help the agent choose.
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?
Given no annotations, the description carries the full burden. It discloses that the tool is experimental, region-aware, informational only, and that move_to_watering_hole sets the dial without transmitting. This covers key behavioral aspects adequately.
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 concise, front-loading the purpose and then listing operations succinctly. Every sentence contributes necessary information without redundancy.
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?
For a tool with 4 parameters and no output schema, the description covers the three operations and their parameters. It could be more complete by mentioning the return format, but overall it provides sufficient context for an informational 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?
Schema coverage is 0%, but the description explains each operation's parameters (e.g., lookup uses frequency_hz and optional mode, watering_hole uses mode and optional band). It adds meaning beyond parameter names, such as 'what the band plan says at a frequency' and 'preferred calling frequency'.
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 the tool provides advisory band guidance for QSY help, listing three specific operations (lookup, watering_hole, move_to_watering_hole). It uses specific verbs and identifies the resource (band plan). However, it does not explicitly distinguish itself from sibling tools like frequency or rig.
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 mentions 'informational / QSY help only' and that move_to_watering_hole does not transmit, implying read-only use. It does not explicitly state when to use this tool versus alternatives or provide contraindications.
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 must bear full burden. It mentions that keying methods are 'callsign-gated', but does not disclose other behavioral traits such as destructive potential, authentication requirements, or error behavior. This is moderately transparent.
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: three sentences with no redundant information. The first sentence front-loads the core purpose and an example, making it easy for an agent to quickly grasp the tool's function.
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 lack of an output schema and annotations, the description provides adequate context for understanding the tool's use and discovery. However, it does not describe return values or error handling, which would improve completeness.
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 0%, so the description must compensate. It explains that 'method' is a dotted XML-RPC method name, adding meaning beyond the schema. However, it does not clarify the structure or purpose of 'params', leaving some ambiguity.
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 identifies the tool as an 'escape hatch' for calling any fldigi XML-RPC method by dotted name, with a concrete example ('rig.get_mode'). This distinguishes it from sibling tools, which are domain-specific.
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 advises using `station` with 'list_methods' to discover available methods, implying that this tool should be used when no specific sibling tool exists. However, it does not explicitly state when not to use it or provide alternatives.
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 the full burden. It discloses that some fields are settable and some are gettable, and that last_record/all_records return ADIF. However, it does not mention any side effects, permissions, or error handling.
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, using two sentences to convey operations and field categories. It is front-loaded with the purpose and enumerates efficiently. No wasted 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 no output schema, the description partially explains return values (ADIF for last_record/all_records) but omits return formats for get, set, clear. It covers all operations and field lists, making it mostly adequate for a multi-operation 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 0% description coverage, so the description must compensate. It does so by explaining the 'operation' parameter values and listing which fields are valid for 'field' in get vs set contexts. This adds significant meaning beyond the bare 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 the tool is for Logbook fields and lists specific operations (get, set, clear, last_record, all_records). It distinguishes from sibling tools like 'frequency' or 'status' by specifying the context of QSO/contest log fields.
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 implies when to use each operation via the list of fields and operations, but does not explicitly state when not to use it or provide alternatives. For example, it doesn't guide against using 'set' when only read access is needed.
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?
Discloses that it does not connect to fldigi, and details exactly what information it reports (resolved FLDIGI_HOST/PORT, Python version, hostname, transmit-gate state, network interfaces). No annotations provided, but description fully informs agent of behavior.
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?
Concise multi-sentence paragraph that front-loads the main purpose and adds necessary context efficiently. Every sentence adds value without redundancy.
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 zero parameters and no output schema, the description fully explains the tool's purpose, what it reports, and how to interpret results. It is complete for a diagnostic 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?
No parameters exist, so baseline 4. The description adds no parameter info because none 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?
Clearly states it performs host and network diagnostics for troubleshooting connectivity. The description distinguishes itself from siblings by specifying its diagnostic scope, which is unique among the listed tools.
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?
Explicitly states that it does NOT connect to fldigi, and provides guidance on what to do if a non-loopback host times out, directing to mcp-host-bridge docs. This helps the agent choose this tool for connectivity troubleshooting.
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:

[![fldigi-mcp MCP server](https://glama.ai/mcp/servers/sbrunner-atx/fldigi-mcp/badges/card.svg)](https://glama.ai/mcp/servers/sbrunner-atx/fldigi-mcp)

Score Badge

Copy to your README.md:

[![fldigi-mcp MCP server](https://glama.ai/mcp/servers/sbrunner-atx/fldigi-mcp/badges/score.svg)](https://glama.ai/mcp/servers/sbrunner-atx/fldigi-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/sbrunner-atx/fldigi-mcp'

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