IMO Health MCP Server

View saved version →

---
name: imo-graphql
description: Navigate the IMO Knowledge Graph via GraphQL — code mappings, hierarchy traversal, refinements, cross-domain relationships, and reverse lookups across 9 tools
when_to_use: Use when the user wants to map codes across systems (ICD-10, SNOMED, CPT, RxNorm, NDC), explore parent/child hierarchies, apply refinements (laterality, chronicity, etc.), find cross-domain relationships (treatments, procedures, causative agents), or do reverse lookups from procedures/medications to problems. Triggers on words like "map", "cross-map", "hierarchy", "children", "parent", "refine", "laterality", "specificity", "related problems", "treatments for", "what procedures".
user-invocable: true
---

# GraphQL Knowledge Graph — 9 Tools

Navigate the IMO Health Knowledge Graph via GraphQL. This skill covers code mappings, lexical context, refinements, hierarchy traversal, cross-domain relationships, and reverse lookups.

**Critical:** All tools in this skill require the `lexical_code` from normalization or search results — NOT the `imo_code`. If the user only has a free-text term, chain from `imo-normalize` or `imo-core-search` first.

---

## A. Code Mappings

### 1. `graphql_modifier___get_mappings`

**When to use:** Use for external coding-system mappings of a known IMO lexical, optionally filtered by system or enriched with Problem-domain HCC information.

#### Purpose, documented response, and behavior

Retrieve external code mappings for an IMO lexical from the Knowledge Graph.

IMPORTANT: Use the 'lexical_code' value from normalize_ppml_term results
as the code parameter (NOT the imo_code). Returns equivalent codes in industry
standard coding systems, with the available systems depending on the domain:

- problem: ICD-10-CM, ICD-10-CA, ICD-9-CM, SNOMED CT (International/Canadian/US),
  DSM-5, ICD-O, MONDO. Set include_hcc=True to add HCC data on ICD-10-CM codes
  (a structured 'hcc' array of category/description/model, e.g. CMS_HCC_V28,
  RX_HCC_V08).
- procedure: CPT, HCPCS, ICD-10-PCS, LOINC, SNOMED CT International.
- medication: RxNorm (with term-type titles), NDC (with brand/generic name,
  dosage form, route, labeler, active ingredients, package codes), CVX (with
  vaccine status and MVX manufacturers), SNOMED CT International.

Each mapping includes the code, title, code system, and relationship type
(exactMatch, closeMatch, broadMatch, narrowMatch, relatedMatch). Optionally
filter with the code_systems parameter (GraphQL enum values, no quotes).

#### Input arguments exposed by the connected MCP tool

Host-visible tool: `mcp__imo_health__graphql_modifier___get_mappings`.

```typescript
type Input = {
  // Optional list of code systems to filter by. Depends on domain — problem: icd10cm, icd10ca, icd9cm, snomedInternational, snomedCa, snomedUs, dsm5, icdO, mondo. procedure: cpt, hcpcs, icd10pcs, loinc, snomedInternational. medication: rxnorm, ndc, cvx, snomedInternational. If not provided, returns all code maps for the domain.
  code_systems?: Array<string> | null;
  // The lexical domain: 'problem' (default), 'procedure', or 'medication'. Determines which code systems are available.
  domain?: string;
  // The lexical_code from normalize_medical_term results (e.g. '78845' for knee pain)
  imo_lexical_code: string;
  // Problem domain only. If true, include HCC (Hierarchical Condition Category) data on ICD-10-CM mappings — a structured 'hcc' array with category, description, and model (e.g. CMS_HCC_V28, RX_HCC_V08).
  include_hcc?: boolean;
};
```

#### Documented input schema (JSON Schema)

```json
{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "graphql_modifier___get_mappings",
  "type": "object",
  "properties": {
    "code_systems": {
      "type": [
        "array",
        "null"
      ],
      "items": {
        "type": "string"
      },
      "description": "Optional list of code systems to filter b

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: imo-normalize
description: Normalize clinical terms to standard IMO terminology across Problem, Procedure, Medication, and Lab domains using Precision Normalize (PPML)
when_to_use: Use when the user wants to normalize, standardize, or map a free-text clinical term to IMO's standard clinical terminology. Triggers on words like "normalize", "standardize", "map term", "what's the standard name for", or when a raw clinical term needs to be resolved to an IMO concept.
user-invocable: true
---

# Normalization

Resolve free-text terms to standardized IMO terminology across four domains. **1 tool.**

## `normalize_ppml___normalize_ppml_term`

**When to use:** Use when the user wants a canonical standardized term or needs an IMO lexical code for a downstream lookup. Split a mixed-domain list into separate calls.

### Purpose, documented response, and behavior

Normalize medical terms using the IMO Precision Normalize API across Problem, Procedure, Medication, and Lab domains.

Send one or more medical terms and receive raw normalization results from the API.
For Medication domain, returns 20 results per term. For Problem, Procedure, and Lab domains, returns 1 result per term.

### Input arguments exposed by the connected MCP tool

Host-visible tool: `mcp__imo_health__normalize_ppml___normalize_ppml_term`.

The following argument type and parameter comments are copied verbatim from the connected tool definition. Fields marked `?` are optional; fields without `?` are required. Pass the argument object matching this definition.

```typescript
type Input = {
  // The domain of the medical terms. Must be one of: 'Problem', 'Procedure', 'Medication', 'Lab'.
  domain: string;
  // List of medical terms to normalize (e.g., ['diabetes', 'chest pain', 'amoxicillin', 'CBC'])
  terms: Array<string>;
};
```

### Documented input schema (JSON Schema)

```json
{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "normalize_ppml___normalize_ppml_term",
  "type": "object",
  "properties": {
    "domain": {
      "type": "string",
      "enum": [
        "Problem",
        "Procedure",
        "Medication",
        "Lab"
      ],
      "description": "The domain of the medical terms. Must be one of: 'Problem', 'Procedure', 'Medication', 'Lab'."
    },
    "terms": {
      "type": "array",
      "items": {
        "type": "string"
      },
      "description": "List of medical terms to normalize (e.g., ['diabetes', 'chest pain', 'amoxicillin', 'CBC'])"
    }
  },
  "required": [
    "domain",
    "terms"
  ]
}
```

### Inputs

| Parameter | Type | Required | Meaning, default, and constraints |
| --- | --- | --- | --- |
| `domain` | `string` | Yes | The domain of the medical terms. Must be one of: 'Problem', 'Procedure', 'Medication', 'Lab'. |
| `terms` | `Array<string>` | Yes | List of medical terms to normalize (e.g., ['diabetes', 'chest pain', 'amoxicillin', 'CBC']) |

### Interpretation and related-tool guidance

For a single canonical result, use this tool; for several ranked Problem candidates use `concept_guideline___get_concept_candidates`; for mapped search results use Core Search.

## Workflow and presentation

1. Determine the intended domain: diagnoses/findings → Problem; procedures → Procedure; medications → Medication; laboratory tests → Lab.
2. Send one or more terms from the same domain. Domain values are exactly `Problem`, `Procedure`, `Medication`, and `Lab`.
3. Present the returned standardized title and IMO lexical ID. If available, distinguish the internal `imo_code` from the `lexical_code`.
4. Use `lexical_code` for subsequent Core Search/Knowledge Graph calls only when the user requests that work.
5. If normalization yields no match, state that and suggest alternative wording; do not fabricate a lexical.

The service forwards normalization output rather than declaring a complete output schema. Existing documentati

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: imo-setup
description: Set up the IMO Health plugin after installation, guide account connection through the host OAuth flow, and verify access with a read-only terminology lookup.
---

# Set up IMO Health

Use this skill when the user runs plugin setup or asks to connect their IMO account.

1. Explain that the plugin connects to the existing IMO Health service and requires an account with the relevant API permissions. Never ask for passwords, client secrets, access tokens, or refresh tokens in chat or files.
2. Inspect tools exposed by the installed plugin. If the connection is missing, guide the user to the plugin's account/connection settings and the host's Connect or Sign in action. Use the supported host connection flow if available; let the user complete IMO sign-in, MFA, and consent on the provider page. Do not construct an OAuth authorization URL yourself or implement a token exchange in chat.
3. A publisher configuring the provided OAuth client must enter its client secret only into the host's secure connection setup and register the exact redirect URI shown there with IMO. A regular installing user should only sign in and consent. If setup lacks a supported secure secret-entry flow, explain that publisher connection setup is still required. Do not switch to unauthenticated access or change the client method.
4. After linking, verify with one read-only call: normalize the synthetic term `hypertension` in the Problem domain using the exposed normalization tool's actual input schema. A read-only test is part of this setup workflow. Do not perform additional enrichment, refinement, NLP, or relationship queries.
5. Report the actual returned title and lexical_code. Report setup as verified only when an authenticated call succeeds. Tool visibility alone is insufficient. A no-match response can establish service access, but report the lookup as no match. If there is an authentication error, guide reconnection. A permission error needs the corresponding IMO scope or entitlement. A redirect mismatch needs the publisher to register the host's exact callback URI. Never fabricate a successful connection.
6. If tools appear only in new conversations, explain that limitation and ask the user to start a new chat with this plugin selected. Do not create a chat unless requested.

The host controls when OAuth appears. Setup runs after installation when the user chooses setup; declaring onboarding does not force consent to complete inside the installation dialog.