Skip to main content
Glama
mymedi-ai-mcp-server

mymedi-ai-mcp-server

by MyMedi-AI

Extract ICD-10-CM, HCPCS and CPT codes and dates from clinical text

ner_extract
Read-only

Extract medical codes from de-identified clinical text and check each against the MyMedi-AI code database to confirm code-set presence, description, and active status.

Instructions

Extract the medical codes already present in de-identified text and check each against the MyMedi-AI code database: ICD-10-CM codes whole, dotted or undotted, with their 7th-character extensions (S72.001A, S72001A); HCPCS Level II codes (a letter A–V and four digits), with modifiers attached (E0601RR, E0601-RR) reported as modifiers — a glued suffix only when it is a known DMEPOS modifier; and CPT codes only where a keyword such as CPT or procedure code marks them (Category II and III and PLA codes such as 0001U included), so ZIP codes and other numbers are not read as codes, and a five-digit number that continues a marked list is kept only when the CPT set holds it. Codes are read in upper case, as code sets print them; lower-case text is not read as a code. Each code entity says whether the code set holds it (inCodeSet) and, when it does, gives its description and whether it is active; an undotted ICD-10-CM shape is returned only when the code set holds it, so words such as B12 are not read as codes. codeSets names the code-set releases checked. Also returns M/D/Y dates and one MEDICATION_INDICATOR entity when a dose unit (mg, mcg or mL) appears. It does not extract drug names and does not infer or suggest codes. PHI-free: for de-identified text only.

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": {
      "text": "<text>"
    },
    "name": "ner_extract"
  }
}

Input Schema

NameRequiredDescriptionDefault
textYesClinical text to extract entities from
entityTypesNoReturn only these entity types: ICD10_CODE, HCPCS_CODE, CPT_CODE, DATE, MEDICATION_INDICATOR (any letter case; default all). Any other type is refused, and refunded.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.7.9
    • changedInput schema / properties / entityTypes / description
      Previous value: -"Filter to specific entity types"New value: +"Return only these entity types: ICD10_CODE, HCPCS_CODE, CPT_CODE, DATE, MEDICATION_INDICATOR (any letter case; default all). Any other type is refused, and refunded."
    • addedInput schema / properties / entityTypes / items / maxLength
      Added value: +30
    • addedInput schema / properties / entityTypes / maxItems
      Added value: +10
    • addedInput schema / properties / text / maxLength
      Added value: +20000
  2. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare read-only, non-destructive, closed-world behavior, and the description adds substantial context: code-set checking, inCodeSet and codeSets output, modifier handling, date and medication-indicator extraction, and PHI-free constraints. It discloses behavior well beyond the annotations without contradicting them.

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 front-loaded with the core extraction purpose and then supplies necessary edge-case rules. It is dense and somewhat run-on, but the detail is largely justified by the complexity of code extraction.

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?

With no output schema, the description still explains the returned entity types, code-set membership fields, codeSets metadata, dates, and medication indicators. It is complete enough for an agent to understand what the tool returns and when to use it.

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 both parameters are already documented in the input schema. The description does not add parameter-specific syntax or filtering details beyond what the schema provides, so the baseline 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?

The description states a specific verb and resource: extract medical codes already present in de-identified text and check them against the MyMedi-AI code database. It explicitly distinguishes extraction from inference/suggestion, which separates it from sibling tools like code_suggest.

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?

It gives clear usage context: de-identified text only, no drug-name extraction, and no inference or suggestion of codes. It does not explicitly name sibling alternatives, but the exclusions make the intended use clear.

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