Loading ToolBench
MCP server for OHDSI OMOP standardized medical vocabularies - search, lookup, map, and navigate concepts via AI agents
Strong MCP server with well-structured tool definitions, comprehensive descriptions, and proper schema documentation. All 11 tools have clear, action-oriented names following verb_noun conventions. Descriptions are detailed and include pagination guidance where relevant. Input schemas are complete with type definitions, constraints (min/max), and parameter descriptions. The server demonstrates production-quality tool composition and follows most Agentic Tool Patterns. Minor gaps: some parameters could benefit from enum constraints instead of free-form strings; error handling patterns are present but could be more explicit in tool descriptions; no tool annotations (readOnlyHint) visible despite all tools being read-only operations.
Explore a concept in depth: return its full details, related concepts, maps to other vocabularies, and position in the hierarchy. A comprehensive single call for understanding a concept's relationships.
Translate between OMOP concepts and FHIR (Fast Healthcare Interoperability Resources) concepts/codes. Converts OMOP concept_ids to FHIR CodeSystem URIs and codes, and vice versa. Useful for interoperability with FHIR-based systems.
Find concepts similar to a given concept_id across the vocabulary hierarchy and relationships. Useful for discovering related or alternative concepts in the same domain.
Get detailed information about a specific OMOP concept by its numeric concept_id. Returns the concept name, vocabulary, domain, concept class, standard status, valid dates, and synonyms. Use this when you already have a concept_id and need its details.
Look up an OMOP concept using a vocabulary-specific code and vocabulary ID. Both parameters are required to avoid ambiguity - the same code can exist in multiple vocabularies (e.g., 'E11' exists in both ICD10CM and ICD10). If multiple concepts share the same code within a vocabulary, all matches are returned - prefer the one with standard_concept='S'.
Tool annotations missing: all tools are read-only operations but lack explicit readOnlyHint annotations in their definitions. This prevents clients from visualizing safety properties and restricting agent permissions.
vocabulary_id parameter in get_concept_by_code and get_vocabulary_concepts accepts free-form strings (maxLength only, no enum). Should declare enum of known vocabulary IDs (SNOMED, ICD10CM, RxNorm, LOINC, HCPCS, NDC, etc.) to prevent LLM hallucination of invalid vocabulary codes.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 67 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 51 | - | v1 |
Get the hierarchical position of a concept — its ancestors (broader/parent concepts) and/or descendants (narrower/child concepts). Shows concept_id, concept_name, vocabulary_id, and nesting level for each relative. Direction can be 'up' (ancestors only), 'down' (descendants only), or 'both'. Useful for exploring how a concept fits into its taxonomy and finding related narrower or broader terms.
Get summary statistics and a sample of concepts for a specific vocabulary. Returns metadata (name, version, concept counts) and a paginated list of concepts in that vocabulary.
List all available OMOP vocabularies with their metadata: vocabulary ID, name, reference, version, total concept count, and standard concept count. Use this to understand what vocabularies are available and how many concepts they contain.
Find mappings FROM a source concept TO equivalent concepts in other vocabularies. The concept_id you provide is always the SOURCE — results show what it maps TO. Returns cross-vocabulary mappings with relationship types and mapping quality. If no mappings exist, the response explicitly states 'No mappings found' with mapped=false in JSON — never returns ambiguous empty results. Example: provide a SNOMED concept_id and filter by target_vocabularies='ICD10CM' to get the ICD-10 equivalent. PAGINATED: results are one page of a possibly larger set — total_mappings is the full count and has_more says whether further pages exist. When building a complete code list, keep incrementing page until has_more is false; a single call is not the whole answer.
Search for OMOP concepts by name or keyword across all vocabularies or specific ones. Returns a paginated list of matching concepts with their IDs, names, codes, domains, standard status, and validity information. Useful for finding the concept ID to use with other tools. PAGINATED: results show one page of possibly larger result set — total_items in the response is the full count and has_next says whether more pages exist.
Search for OMOP concepts using semantic/AI-powered search that understands clinical meaning and synonyms better than keyword matching. Useful for fuzzy or synonymous concept names. Returns paginated results like search_concepts.
Error handling not explicitly documented in tool descriptions. Tools should document what errors can occur (e.g., 'concept not found', 'invalid vocabulary'), how to recover, and what the LLM should try next. Current descriptions focus on success path only.
fhir_translate has mutually exclusive parameters (concept_id vs fhir_code) but this is not explicitly documented in parameter descriptions. Should state: 'Pass either concept_id OR fhir_code, not both.'
direction parameter in get_hierarchy is documented as enum but the description example uses 'both' as default, should clarify that 'both' is the default and is the recommended starting point for exploring taxonomy.