Skip to main content
Glama

Find Equivalents Across Terminologies

find_equivalent
Read-onlyIdempotent

Ranked unified search for equivalent terms across multiple medical terminologies.

Use this tool to:

  • Find the same concept in different coding systems

  • Compare how terminologies represent a concept

  • Support terminology mapping and data integration

Searches across: ICD-11, SNOMED CT, LOINC, RxNorm, and MeSH. Set target_terminologies to limit which are searched, or set source_terminology to exclude one (e.g. when you already have a code from that terminology and want equivalents elsewhere). The two combine: source is subtracted from targets. limit caps candidates per terminology (default 5, max 10).

Every candidate carries match_score (lexical similarity to the search term, 0-1) and rank (global position across all searched terminologies) — both computed by this server, since upstreams don't expose comparable relevance scores. Candidates from different terminologies whose titles are lexically identical are clustered in groups — a strong same-concept signal (absence of a group is NOT evidence of non-equivalence).

Searches upstreams in English. For official pt-BR content, use the dedicated tools: icd11_search/mesh_search accept language: "pt", and cid10_search is natively Portuguese.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
termYesMedical term to search (e.g., "diabetes", "aspirin")
limitNoMaximum candidates returned PER terminology (1-10, default 5). This is a cap, not a page: the live fan-out has no stable cursor across five upstreams, so raise the limit instead of paging.
source_terminologyNoIf set, this terminology is excluded from the search. Use this when the term came from this terminology and you want equivalents in the others. Combines with target_terminologies by subtraction (source is removed from the target list).
target_terminologiesNoLimit the search to these terminologies. If omitted, all five are searched.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
termYes
groupsYes
rankingYes
resultsYes
provenanceYesOne provenance block per upstream source that contributed to this response (contract v1.0; licenses are never merged)
attributionYesCanonical source URLs of this response (attribution list)
source_terminologyYes
searched_terminologiesYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A5/5.0
Behavior5/5

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

Annotations already mark the tool read-only, idempotent, non-destructive, and open-world, and the description reinforces and extends this. It discloses server-computed match_score and rank, the grouping heuristic with the caveat that absence of a group is not evidence of non-equivalence, and the no-stable-cursor limitation that makes limit a cap rather than a page.

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 information-dense but well-structured with a clear opening, bulleted use cases, and focused paragraphs. Every sentence adds value, including the pt-BR routing guidance and the semantics of match_score/groups. Nothing feels redundant or filler.

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?

Given the tool's complexity and the rich output schema, the description is complete: it covers supported terminologies, parameter interactions, result scoring, grouping semantics, open-world caveats, and language limitations. It also routes the agent to sibling tools when appropriate, leaving no critical ambiguity for selecting or invoking the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100%, the description adds meaning beyond the schema: it explains that source_terminology is subtracted from target_terminologies, that limit is a per-terminology cap due to lack of stable pagination, and that omitting target_terminologies searches all five. These are non-obvious operational details that help an agent use parameters correctly.

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: 'Find equivalents across terminologies', and the 'Use this tool to' list clarifies the exact intent. It clearly differentiates this tool from per-terminology search siblings by emphasizing unified multi-terminology search and mapping support.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives concrete usage conditions: when to use target_terminologies versus source_terminology, how they combine, and when to prefer dedicated pt-BR tools. It explicitly names the alternatives (icd11_search, mesh_search, cid10_search) and the language conditions that should trigger their use.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.