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

mymedi-ai-mcp-server

by MyMedi-AI

Medical code suggestions from clinical text

code_suggest
Read-only

Suggests ICD-10-CM, CPT, and HCPCS Level II codes from clinical or equipment descriptions, ranking matches by relevance and grouping matches for separate conditions or devices.

Instructions

Suggest ICD-10-CM, CPT and HCPCS Level II codes from a clinical or equipment description — a term search over the 90K-code CMS database, no language model. Works with natural sentences ("patient with obstructive sleep apnea prescribed CPAP" lists G47.33 and E0601 first), common abbreviations and alternate forms (CPAP, OSA, COPD, IG for immune globulin, type 2), and a typed side, sex or "without". Ranked by relevance (relevanceScore 0-1: how much of the description a code matches, and how closely), with two exceptions: the best code for each separate thing a description names (a diagnosis and a device) comes first, so the list is grouped rather than strictly sorted by relevanceScore; and a bare common condition ("hypertension") lists its ICD-10-CM default code first. Weak matches are left out rather than listed. Up to 500 characters, of which up to 10 distinct terms are searched, common words left out. Automatically refunds the call when nothing matches.

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": {
      "description": "<description>"
    },
    "name": "code_suggest"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoMax suggestions to return (default 10, max 50)
codeTypeNoLimit to specific code system
descriptionYesClinical description to find codes for (e.g., "chronic lower back pain")

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.7.9
    • addedInput schema / properties / description / maxLength
      Added value: +500
    • addedInput schema / properties / limit / maximum
      Added value: +50
    • addedInput schema / properties / limit / minimum
      Added value: +1
  2. First observed

TDQS

A3.9/5.0
Behavior3/5

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

Annotations already declare readOnly, non-destructive, closed-world and non-idempotent behavior, so the safety profile is covered. The description adds real context beyond that: relevance ranking with relevanceScore 0-1, grouping of best-per-mentioned-entity, default-code behavior for bare conditions, weak matches omitted, and automatic refund when nothing matches. That is meaningful but mostly ranking semantics rather than operational constraints like latency or failure modes.

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?

Front-loaded with the core verb+resource and mechanism, and every clause carries information. It is, however, a single dense paragraph with long parentheticals and nested exceptions that make the ranking rules harder to parse than necessary.

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?

There is no output schema, and the description compensates by explaining the return ordering, the relevanceScore field, grouping behavior, and omission of weak matches — everything an agent needs to interpret results. Given only three simple parameters, nothing material is left undocumented.

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 baseline would be 3, but the description adds interpretation the schema lacks: what kinds of text the description parameter accepts (natural sentences, abbreviations, side/sex qualifiers) and the effective 500-character/10-term search behavior behind it. It says nothing extra about limit or codeType beyond the schema, which keeps it at 4 rather than 5.

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 opens with a specific verb+resource ("Suggest ICD-10-CM, CPT and HCPCS Level II codes from a clinical or equipment description") and even names the mechanism (term search over the CMS database, no language model). It is clearly distinguishable from lookup-style siblings by emphasizing natural-language input, but it never names or contrasts an actual sibling such as code_lookup or code_lookup_basic.

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 concrete guidance on what input works: natural sentences, abbreviations, alternate forms, typed side/sex/"without", 500-character cap and 10-term search limit, plus an example. It stops short of explicit when-to-use/when-not or routing to alternatives like code_lookup for exact-code resolution.

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