MCP Validation and Test Cases¶
ADIF-MCP v0.4.3 Sovereign Test Suite¶
- Build Status: Verified Stable
- Spec Build Date: 2025-09-15
- Validation Engine: 3.1.6 Sovereign
Phase 1: Resource Management & Scale¶
| Test ID | Resource | Focus | Result | Notes |
|---|---|---|---|---|
| T1 | Primary_Sub |
Size Handling | PASS | Successfully parsed 540KB file without exceeding 1MB limit. |
| T2 | Band |
Frequency Range | PASS | Correctly identified 20M as 14.0–14.35 MHz. |
| T3 | Mode |
Parentage | PASS | Verified FT8 as a submode of MFSK. |
Phase 2: Relational Integrity¶
| Test ID | Logic Check | Focus | Result | Behavior |
|---|---|---|---|---|
| T4 | State vs DXCC | Conflict | PASS | Identified 'QC' as Canada (DXCC 1), blocking US (DXCC 291) assignment. |
| T5 | Band vs Award | Eligibility | PASS | Blocked 'VUCC' credit for 20M (HF) contacts. |
| T6 | Prop vs Path | Consistency | PASS | Flagged 'Greyline' as logically invalid for 'Satellite' propagation. |
Phase 3: Administrative Rules¶
| Test ID | Domain | Focus | Result | Verification |
|---|---|---|---|---|
| T7 | Awards | Field Name | PASS | Caught non-standard AWARD_ID; redirected to AWARD_GRANTED. |
| T8 | Contests | Enum Search | PASS | Validated CQ-WW-SSB and rejected MY-LOCAL-HAM-FEST. |
| T9 | QSL Via | Code Logic | PASS | Flagged "DIRECT Buro" as illegal; enforced single-letter codes (D, B, E). |
| T10 | Credits | Specificity | PASS | Verified WAS and DXCC as valid CREDIT_SUBMITTED enumerations. |
| T11 | Metadata | Data Type | PASS | Confirmed STATION_CALLSIGN as a free-text String. |
| T12 | Versioning | Sovereignty | PASS | Verified local build date 2025-09-15T11:13:27Z from headers. |
Phase 4: Edge Case & Technical Precision¶
| Test ID | Logic Check | Focus | Result | Behavior |
|---|---|---|---|---|
| T13 | Grid Square | Format | PASS | Enforced CC-XXX format and leading zero rules for IOTA identifiers. |
| T14 | QSL Status | Workflow | PASS | Validated 'R' (Requested) and 'Q' (Queued) workflow with 'E' (Electronic). |
| T15 | Alaska Sub | Filtering | PASS | Successfully filtered Alaska Boroughs (Aleutians East, etc.) from 540KB file. |
| T16 | MA Collision | Resolving | PASS | Distinguished MA.54 (Moscow) from MA.291 (Massachusetts). |
| T17 | Submodes | Legacy | PASS | Identified <MODE>MFSK <SUBMODE>MFSK16 as standard vs legacy. |
| T18 | IOTA Meta | Comments | PASS | Successfully pulled formatting rules from field Description and Data Type. |
Build Integrity Confirmation¶
This test suite confirms that the ADIF-MCP server successfully handles the complete 30-file ADIF 3.1.6 specification. It demonstrates full awareness of field existence, data types, and complex relational constraints across international borders and legacy systems.
ADIF-MCP v0.4.3 Test Suite Prompts¶
Phase 1: Scale & Performance¶
Test 1 (Subdivisions):
Use the `read_specification_resource` tool for **'primary_administrative_subdivision'**. List the first 10 entries it finds. Does the server handle this 540KB file without lagging or disconnecting?
Test 2 (DXCC Codes):
Read the **'dxcc_entity_code'** resource. Find the code for 'United Kingdom' and 'Shetland Islands'. Are they listed as separate entities in the 3.1.6 spec?"
Test 3 (Relational Break):
I have a log with `<COUNTRY:13>United States <MY_STATE:2>NY`. Verify this using your tools. Then, try a fake one: `<COUNTRY:13>United States <MY_STATE:2>ZZ`. Does the spec show 'ZZ' as a valid subdivision for the US?
Phase 2: Data Integrity & Logic¶
Test 4 (Relational Conflict):
Validate this record: `<COUNTRY:13>United States <MY_STATE:2>QC`. Check the `dxcc_entity_code` for the US and the `primary_administrative_subdivision` list. Is 'QC' a valid subdivision for DXCC 291? If it belongs to another DXCC, tell me which one.
Test 5 (Type Enforcement):
I have a field `<FREQ:6>14.200`. According to the `fields.json` resource, what is the 'Data Type' for the `FREQ` field? Then, check the `datatypes.json` resource—is a 6-character string with a decimal point valid for that specific data type?
Test 6 (Submode Hierarchy):
Read the **'submode'** resource. Find the submode **'FT4'**. What is its 'Parent Mode'? Then, check the **'mode'** resource—is that Parent Mode listed as 'Import-only' or is it a standard active mode?
Phase 3: Administrative & Technical Deep-Dives¶
Test 7 (Awards):
"Read the **'award'** resource. I have a log with `<AWARD_ID:15>DXCC_MIXED_#100`. According to the ADIF 3.1.6 specification, is this the correct format for a DXCC award ID? Specifically, how does the spec suggest handling the '#' symbol in an award identifier?
Test 8 (Contest IDs):
Use the `search_enumerations` tool to find the record for 'CQ-WW-SSB' in the `contest_id` resource. What is the full name of this contest? Then, try a fake one: 'MY-LOCAL-HAM-FEST'. Does the spec recognize that as a valid Contest_ID?
Test 9 (QSL Pathing):
Read the **'qsl_via'** and **'qsl_rcvd'** resources. If I have `<QSL_RCVD:1>Y` and `<QSL_VIA:10>DIRECT Buro`, is that a valid combination of values? Check the `qsl_rcvd` enumeration to see what 'Y' means and if 'DIRECT Buro' is an allowed value for the `qSL_VIA` field.
Test 10 (Credits):
Read the **'credit'** resource. I have a record claiming credit for **'WAS'** and **'DXCC'**. Are these valid enumeration values for the `CREDIT_SUBMITTED` field? Also, does the spec allow the credit type **'VUCC'** for a 20M contact?
Test 11 (Callsign Metadata):
"Check the **'fields'** resource for **'STATION_CALLSIGN'** and **'OWNER_CALLSIGN'**. What are their 'Data Types'? Then, verify if there is an enumeration for these, or if they are free-text strings.
Test 12 (Versioning):
Request the 'adif_catalog' or the header of the **'all'** resource. What is the exact 'Created' date and 'Version' of the specification you are currently using?
Phase 4: Edge Cases & Advanced Filtering¶
Test 13 (Grid Precision):
Check the 'datatypes' resource for 'GridSquare' and 'GridSquareExt'. What is the character length for a standard grid vs. an extended grid? Then, validate if `<MY_GRIDSQUARE:4>FN20ab` is a valid entry based on these rules.
Test 14 (QSL Workflow):
"Search the **'qsl_sent'** and **'qsl_sent_via'** resources. If a user logs `<QSL_SENT:1>R <QSL_SENT_VIA:1>E`, what does 'R' mean and is 'E' a valid method for an electronic QSL? What about 'Q'? Is 'Q' a valid value for `QSL_SENT`?
Test 15 (Alaska Reverse Lookup):
I have a record with `<MY_STATE:2>AK`. Use your tools to find all 'secondary_administrative_subdivision' records that belong to Alaska (DXCC 6). Return just the first 5 names.
Test 16 (International Collision):
Use `search_enumerations` to find the record for 'MA' in the `primary_administrative_subdivision` resource. I am looking for a region in European Russia (DXCC 54). Does the record exist, and what is its 'Primary Administrative Subdivision' name? Then, find 'MA' for the United States (DXCC 291). Does the tool correctly distinguish between the two based on their DXCC Entity Codes?
```
**Test 17 (Legacy Submodes):
```bash
Read the 'submode' resource. Find 'MFSK16' and 'FT4'. Is either one marked as 'Import-only'? Then, check the 'mode' resource for the parent mode 'MFSK'. If a log contains `<MODE:4>MFSK <SUBMODE:6>MFSK16`, is this considered a modern standard or a legacy compatibility entry according to the spec's flags?
Test 18 (Metadata Flags):
Search the 'fields' resource for the 'MY_IOTA' and 'IOTA' fields. Do these fields contain any 'Comments' in the spec regarding their format (e.g., the IOTA island reference format)? Also, check if the 'FORCE_INIT' field is marked as 'Import-only'.