Medical Terminologies MCP

Validate Medical Codes

validate_codes

Read-onlyIdempotent

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.

First observedSep 6, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare read-only, open-world, idempotent, and non-destructive behavior. The description goes well beyond annotations by explaining return-field semantics, the valid:false + error:null vs. error:set distinction, terminology auto-detection being unsupported, parallel validation, hard cap of 50, and the SNOMED feature-flag dependency. This is rich, honest behavioral disclosure.

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?

Though fairly long, the description is information-dense and every section earns its place: purpose, return semantics, required-terminology rationale, accepted values, and performance characteristics. The most important purpose statement is front-loaded, and the detailed return-field explanation is well structured.

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?

Even though an output schema exists, the description supplies the interpretive context an agent needs: what valid/active/title/replaced_by/source/error each mean, the difference between 'not found' and 'couldn't validate', and practical constraints like the 50-code cap and worst-case latency. Nothing critical is missing for correct invocation.

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?

The input schema already documents the codes array and its nested objects at 100% coverage, so the baseline is 3. The description adds meaningful semantic context beyond the schema by explaining why terminology is required (ambiguous category codes), listing accepted values, and clarifying the per-code hard cap and parallel execution behavior.

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 opens with a specific verb and resource: 'Validate a mixed batch of medical codes against their source terminologies.' It clearly distinguishes itself from sibling lookup/search/mapping tools by emphasizing batch validation, legacy-database analysis, 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 explicitly targets retrospective analysis of legacy databases and mixed-batch scenarios, which signals when this tool is the right choice. It does not explicitly name sibling tools to avoid, but the batch/multi-terminology framing is clear enough to select this over single-terminology lookup tools.

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

All Medical Terminologies MCP tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.