qrz-mcp

Overview Schema Source Related Servers Discussions Admin

Qrz Logbook Fetch

qrz_logbook_fetch

Read-onlyIdempotent

Query QSOs from a QRZ logbook with filters for band, mode, date range, and callsign; optionally return the newest contacts first instead of the default oldest.

Instructions

Query QSOs from a QRZ logbook with optional filters.

Transparently paginates to collect up to limit records. QRZ returns records oldest first, so by default limit keeps the OLDEST matches. Set newest_first for the most recent QSOs instead (for example, "my last 10 contacts" is limit=10 with newest_first=true).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "persona": "<persona>"
    },
    "name": "qrz_logbook_fetch"
  }
}

Input Schema

Name	Required	Description
`band`	No	Filter by band (e.g., '20m').
`dxcc`	No	Filter by DXCC entity code.
`mode`	No	Filter by mode (e.g., 'FT8').
`limit`	No	Maximum records to return (default 250).
`persona`	Yes	Persona name configured in adif-mcp.
`callsign`	No	Filter by contacted station.
`end_date`	No	Date range end (YYYY-MM-DD).
`start_date`	No	Date range start (YYYY-MM-DD).
`newest_first`	No	Return the newest `limit` matches, newest first.
`confirmed_only`	No	Only return confirmed QSOs.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.5.0Oct 27, 2026

addedInput schema / properties / newest_first

Added value: +{
+  "default": false,
+  "description": "Return the newest `limit` matches, newest first.",
+  "type": "boolean"
+}

First observedv0.3.3May 27, 2026

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With annotations already covering readOnly/idempotent/non-destructive, the description still adds a non-obvious trait that would otherwise cause silently wrong answers: QRZ returns oldest first, so the default limit keeps the OLDEST matches, and it transparently paginates. It does not mention rate limits or auth requirements, keeping it short of a 5.

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 short sentences, front-loaded with the purpose, then the two behaviors most likely to trip up an agent. Every sentence carries information that changes how the tool is called.

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?

Output shape is covered by the output schema, and the description handles pagination, ordering, and limit semantics for a 10-parameter tool. Filter composition (AND vs OR) and persona resolution failure modes remain undocumented, a minor but real gap.

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%, so the baseline is 3, but the description adds meaning beyond the schema: the interaction between limit and newest_first determines WHICH records are kept, not just how many. It adds nothing about how band/mode/dxcc/callsign/date filters combine, so it is not fully additive.

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?

States a specific verb and resource ('Query QSOs from a QRZ logbook') plus the fact that filters are optional, which is enough to distinguish it from qrz_logbook_status and qrz_download. It never names a sibling explicitly, so the differentiation is inferred rather than stated.

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?

Gives a concrete usage scenario ('my last 10 contacts' is limit=10 with newest_first=true), which tells the agent how to satisfy a common intent. It does not say when to prefer qrz_download or qrz_lookup over this tool, so context is clear but exclusions are absent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server