mymedi-ai-mcp-server

Medical code validation

code_validate

Read-only

Validate ICD-10-CM, CPT, and HCPCS Level II codes for a specific date of service, applying effective and termination dates and returning validity, active status, warnings, and errors.

Instructions

Check that an ICD-10-CM, CPT or HCPCS Level II code exists and is valid on a date of service: termination and effective dates are applied, so a code deleted after that date still validates. dateOfService is YYYY-MM-DD (default today); asOf in the result is the date the code was judged for. Returns valid, active, warnings and errors.

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": {
      "code": "<code>"
    },
    "name": "code_validate"
  }
}

Input Schema

Name	Required	Description
`code`	Yes	Medical code to validate
`context`	No
`codeType`	No
`dateOfService`	No	Date of service, YYYY-MM-DD (default today)
`date_of_service`	No	Same as dateOfService (snake_case spelling)

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedv1.7.9Nov 2, 2026

addedInput schema / properties / code / maxLength
```
Added value: +500
```

changedInput schema / properties / context / properties / dateOfService / description

Previous value: -"Date of service (YYYY-MM-DD) for temporal validation"New value: +"Same as dateOfService; if both are sent they must match"

addedInput schema / properties / context / properties / dateOfService / maxLength
```
Added value: +10
```
addedInput schema / properties / context / properties / dateOfService / pattern
```
Added value: +"^\\d{4}-\\d{2}-\\d{2}$"
```

addedInput schema / properties / context / properties / date_of_service

Added value: +{
+  "description": "Same as dateOfService (snake_case spelling)",
+  "maxLength": 10,
+  "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+  "type": "string"
+}

addedInput schema / properties / dateOfService

Added value: +{
+  "description": "Date of service, YYYY-MM-DD (default today)",
+  "maxLength": 10,
+  "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+  "type": "string"
+}

addedInput schema / properties / date_of_service

Added value: +{
+  "description": "Same as dateOfService (snake_case spelling)",
+  "maxLength": 10,
+  "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+  "type": "string"
+}

First observedApr 13, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint true, openWorldHint false, idempotentHint false, destructiveHint false, so the safety profile is covered. The description adds important behavioral context beyond annotations: it applies termination and effective dates, explains that a code deleted after the date of service still validates, states the default date is today, and mentions the asOf result field and return fields (valid, active, warnings, errors). This is solid behavioral disclosure for a read-only validation tool.

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, front-loaded with the primary purpose and key date logic, then the date parameter default, then return fields. No wasted words; every sentence contributes useful information.

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 helpfully lists return fields (valid, active, warnings, errors) and explains date-of-service behavior and the asOf result. Annotations cover the safety profile. The main remaining gaps are the unexplained context object and the lack of detail on the codeType enum, but for typical use the definition is mostly 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 description coverage is 60%, so the baseline is 3. The description repeats the dateOfService format and default, and implies code types (ICD-10-CM, CPT, HCPCS) which maps to the codeType enum, but it does not explain the context object, the duplicate dateOfService/date_of_service parameters, or the codeType enum values. It adds some value but doesn't compensate for the remaining schema gaps.

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 states a specific verb (Check/validate) and resource (ICD-10-CM, CPT, HCPCS Level II code), and uses singular 'a code' which implicitly distinguishes it from the batch sibling code_validate_batch. An agent can immediately tell this validates one code's existence and validity on a date.

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?

Usage is implied by 'Check that ... a code exists and is valid' but there is no explicit when-to-use versus alternatives like code_validate_batch or code_lookup, nor any stated exclusions or prerequisites. The description gives enough context to infer its purpose, but stops short of routing guidance.

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