Medical Terminologies MCP

Validate Medical Codes

validate_codes

Read-onlyIdempotent

Validate medical codes against source terminologies to flag invalid entries, surface replacements, and retrieve activity status for legacy data cleanup.

Instructions

Validate a mixed batch of medical codes against their source terminologies. Useful for retrospective analysis of legacy databases — flag codes that no longer exist, surface ICD-10 → ICD-11 replacements, and grade activity status where the terminology exposes it.

For each input { code, terminology }, returns:

valid: whether the code exists in the source terminology.
active: whether the code is currently active. Null when the source doesn't expose an explicit active/inactive distinction at category level (CID-10, ATC, ICD-11, RxNorm, MeSH all return null today; SNOMED and LOINC return a real boolean).
title: the official label/name when available.
replaced_by: a successor code, populated today only for ICD-10 codes that have a primary ICD-11 mapping in the bundled WHO transition tables.
source: human-readable provenance of the validation (terminology + release/version).
error: non-null only when validation couldn't be performed (network error, SNOMED feature flag off, etc.). valid: false + error: null means "code not found"; valid: false + error: set means "couldn't validate".

Terminology is required per code — auto-detection isn't supported because category codes like "A00" exist in both ICD-10 and CID-10. Accepted values: icd11, icd10, snomed, loinc, rxnorm, mesh, atc, cid10.

Hard cap of 50 codes per call; codes are validated in parallel through their respective clients, so total wall time scales with the slowest upstream + its rate limit (worst case ~10 s for a full batch hitting ICD-11).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`codes`	Yes	List of code+terminology pairs to validate. Hard cap of 50 per call to keep total latency under ~10 s given upstream rate limits.

Output Schema

TableJSON Schema

Name	Required	Description
`total`	Yes	Number of codes submitted.
`results`	Yes
`provenance`	Yes	One provenance block per upstream source that contributed to this response (contract v1.0; licenses are never merged)
`attribution`	Yes	Canonical source URLs of this response (attribution list)
`error_count`	Yes	How many couldn't be validated due to upstream/network errors.
`valid_count`	Yes	How many were confirmed valid.
`invalid_count`	Yes	How many were not found.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed12 schema fields changedv1.9.1Sep 1, 2026
- removedOutput schema / properties / provenance / items / properties / data_vintage / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / provenance / items / properties / data_vintage / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedOutput schema / properties / provenance / items / properties / license / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / provenance / items / properties / license / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedOutput schema / properties / results / items / properties / active / anyOf
```
Removed value: -[
-  {
-    "type": "boolean"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / results / items / properties / active / type
```
Added value: +[
+  "boolean",
+  "null"
+]
```
- removedOutput schema / properties / results / items / properties / error / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / results / items / properties / error / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedOutput schema / properties / results / items / properties / replaced_by / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / results / items / properties / replaced_by / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedOutput schema / properties / results / items / properties / title / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / results / items / properties / title / type
```
Added value: +[
+  "string",
+  "null"
+]
```

Changed3 schema fields changedv1.8.0Aug 10, 2026

addedOutput schema / properties / attribution

Added value: +{
+  "description": "Canonical source URLs of this response (attribution list)",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedOutput schema / properties / provenance

Added value: +{
+  "description": "One provenance block per upstream source that contributed to this response (contract v1.0; licenses are never merged)",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "citation": {
+        "description": "Ready-to-use citation/attribution string",
+        "type": "string"
+      },
+      "data_vintage": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "description": "Version/release of the data as exposed by the source; null when not exposed"
+      },
+      "license": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "description": "License / legal regime of the data"
+      },
+      "retrieved_at": {
+        "description": "Real instant of the upstream extraction (ISO-8601, UTC). Responses served from cache keep the ORIGINAL fetch instant.",
+        "type": "string"
+      },
+      "source": {
+        "description": "Official upstream source of this data",
+        "type": "string"
+      },
+      "source_url": {
+        "description": "Canonical URL of the source (API base or dataset release)",
+        "type": "string"
+      }
+    },
+    "required": [
+      "source",
+      "source_url",
+      "data_vintage",
+      "retrieved_at",
+      "citation",
+      "license"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

changedOutput schema / required

Previous value: -[
-  "total",
-  "valid_count",
-  "invalid_count",
-  "error_count",
-  "results"
-]New value: +[
+  "total",
+  "valid_count",
+  "invalid_count",
+  "error_count",
+  "results",
+  "provenance",
+  "attribution"
+]

Changed18 schema fields changedv1.5.7Jun 21, 2026
- removedInput schema / additionalProperties
```
Removed value: -false
```
- removedInput schema / properties / codes / items / additionalProperties
```
Removed value: -false
```
- addedOutput schema / properties / error_count / maximum
```
Added value: +9007199254740991
```
- addedOutput schema / properties / error_count / minimum
```
Added value: +-9007199254740991
```
- addedOutput schema / properties / invalid_count / maximum
```
Added value: +9007199254740991
```
- addedOutput schema / properties / invalid_count / minimum
```
Added value: +-9007199254740991
```
- addedOutput schema / properties / results / items / properties / active / anyOf
```
Added value: +[
+  {
+    "type": "boolean"
+  },
+  {
+    "type": "null"
+  }
+]
```
- removedOutput schema / properties / results / items / properties / active / type
```
Removed value: -[
-  "boolean",
-  "null"
-]
```
- addedOutput schema / properties / results / items / properties / error / anyOf
```
Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
```
- removedOutput schema / properties / results / items / properties / error / type
```
Removed value: -[
-  "string",
-  "null"
-]
```
- addedOutput schema / properties / results / items / properties / replaced_by / anyOf
```
Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
```
- removedOutput schema / properties / results / items / properties / replaced_by / type
```
Removed value: -[
-  "string",
-  "null"
-]
```
- addedOutput schema / properties / results / items / properties / title / anyOf
```
Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
```
- removedOutput schema / properties / results / items / properties / title / type
```
Removed value: -[
-  "string",
-  "null"
-]
```
- addedOutput schema / properties / total / maximum
```
Added value: +9007199254740991
```
- addedOutput schema / properties / total / minimum
```
Added value: +-9007199254740991
```
- addedOutput schema / properties / valid_count / maximum
```
Added value: +9007199254740991
```
- addedOutput schema / properties / valid_count / minimum
```
Added value: +-9007199254740991
```
Addedv1.4.0May 12, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Even though annotations already declare readOnly and idempotent hints, the description adds substantial behavioral context beyond them: the exact meaning of valid/active/title/replaced_by/source/error, terminology-specific null behavior, ICD-10-only replacement mapping today, error semantics distinguishing 'not found' from 'couldn't validate', and worst-case timing due to parallel upstream calls. This is far beyond what annotations alone provide.

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?

The description is long but tightly structured: purpose first, then use case, then a clear field-by-field output breakdown, then constraints and performance expectations. Every sentence adds useful information, and the bullet formatting makes the return semantics easy for an agent to parse.

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?

The tool is complex, with one nested parameter, eight terminologies, nuanced output fields, and multiple sibling tools, yet the description leaves no practical gap. It explains return semantics, error interpretation, terminology requirements, batch limits, and latency behavior, making it fully actionable for an agent even before inspecting an output schema.

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%, and the schema already documents the code field, the terminology enum, the required-term logic, and the maxItems constraint. The description restates and reinforces these details but does not add materially new input-parameter semantics 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 names a specific verb and resource: validate a mixed batch of medical codes against their source terminologies. It clearly distinguishes itself from the many single-terminology lookup/search siblings by emphasizing batch, mixed-terminology validation and features like replacement surfacing and activity grading.

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?

The description gives a clear use case ('retrospective analysis of legacy databases') and explains when the tool is appropriate, including the hard 50-code cap and parallel execution behavior. It does not explicitly name sibling alternatives or state when not to use this tool, but the context is clear enough for an agent to select it correctly.

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

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/SidneyBissoli/medical-terminologies-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server