Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@loinc-mcp search for LOINC codes related to glucose"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol server for querying LOINC (Logical Observation Identifiers Names and Codes) terminology through the LOINC Search API.
Tool | Description |
| Search LOINC codes by text query. Returns codes, names, and classifications. |
| Get full details for a LOINC code: parts, classification, units, panel members, and answer options. |
Related MCP server: SNOMED CT MCP Server
Python 3.12+
A LOINC account (free at loinc.org/join)
git clone https://github.com/robsyc/loinc-mcp && cd loinc-mcp
uv tool install .Then add to your .cursor/mcp.json or Claude Desktop config:
{
"mcpServers": {
"loinc-mcp": {
"command": "loinc-mcp",
"env": {
"LOINC_USERNAME": "your-username",
"LOINC_PASSWORD": "your-password"
}
}
}
}{
"mcpServers": {
"LOINC": {
"command": "uvx",
"args": ["--from", "git+https://github.com/robsyc/loinc-mcp", "loinc-mcp"],
"env": {
"LOINC_USERNAME": "your-username",
"LOINC_PASSWORD": "your-password"
}
}
}
}"Search for LOINC codes related to glucose"
"Get the full details for LOINC code 2339-0"
"Look up the lipid panel 24331-1 and show me its members"
This server wraps the LOINC Search API:
Base URL: https://loinc.regenstrief.org/searchapi/
Auth: HTTP Basic Authentication (LOINC account credentials)
Endpoints used: /loincs (search) and FHIR /Questionnaire/{code} (panels)
Rate limiting: 10 requests/second (enforced client-side)
Code | Type |
1 | Laboratory |
2 | Clinical |
3 | Claims attachments |
4 | Surveys |
When get_code is called for a panel (detected via the CLASS field), panel members are automatically fetched from the FHIR Questionnaire endpoint. For survey panels, answer options are included inline with each member.
uv sync --group dev
# Lint
uv run ruff check src/ tests/
# Tests
uv run pytest tests/ -v
# MCP Inspector
LOINC_USERNAME=your-user LOINC_PASSWORD=your-pass uv run fastmcp dev inspector src/loinc_mcp/server.py:mcpLOINC for the terminology and API
Regenstrief Institute for maintaining LOINC
FastMCP for the MCP framework
Get full details for a LOINC code: name, parts, classification, units, and panel members/answer options if applicable.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | LOINC code, e.g. '2339-0' (Glucose in Blood) or '24331-1' (Lipid Panel) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint, so the description does not add extra behavioral context. The description's role in transparency is limited, and it correctly does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the main action and lists key details, making it highly concise without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter with full schema coverage, comprehensive annotations, and the existence of an output schema, the description sufficiently covers what the tool does. It provides a clear list of returned items, leaving no major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with the parameter description including an example. The tool description adds no additional meaning beyond what the schema provides, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'full details for a LOINC code', enumerating specific items returned. It distinguishes from the sibling tool 'search' by focusing on retrieval of details for a given code rather than searching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool is used when a specific LOINC code is known to retrieve its details. However, it does not explicitly state when not to use it or mention alternatives like 'search' for finding codes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search LOINC codes by text. Returns matching codes with names and classifications.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results (1-100) | |
| query | Yes | Search text, e.g. 'glucose', 'blood pressure', 'PHQ-9'. Supports field syntax: 'Component:glucose AND System:Serum'. | |
| class_type | No | Filter by class type: '1' (Lab), '2' (Clinical), '3' (Claims), '4' (Surveys) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, destructiveHint, and idempotentHint. Description adds no further behavioral traits beyond confirming it's a search operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded, no redundant information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists and annotations are present, description sufficiently explains functionality and return structure. Could mention pagination or sorting, but not necessary for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 3 parameters with descriptions (100% coverage). Description does not add syntactic or format details beyond schema, but the field syntax example in query description is helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it searches LOINC codes by text and returns matching codes with names and classifications. Differentiates from sibling 'get_code' which likely retrieves a specific code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use for searching LOINC codes; sibling 'get_code' suggests alternative for retrieving a specific code, but no explicit when-not-to-use or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0get_codesearchScored across 2 tools
get_code retrieves details for a specific code, while search finds codes by text. Their purposes are completely distinct, leaving no ambiguity.
Both names follow a simple verb pattern, but get_code uses verb_noun while search is just a verb. Slight inconsistency, though both are clear and predictable.
With only 2 tools, the server is minimal but covers basic search and retrieval for LOINC. It is slightly thin for a domain with many potential operations, yet acceptable for a focused utility.
The set covers core lookup and search but lacks operations like listing by class, navigating hierarchies, or batch queries. Notable gaps exist, but the two tools serve essential needs.
Read-only U.S. lab-test catalog, collection-site search, and reference-range context.
NIH Clinical Tables: ICD-10/9, RxTerms, LOINC, NPI, conditions search. Keyless.
Diagnoses, drugs & lab codes: ICD-11, SNOMED, LOINC, RxNorm, MeSH, ATC, CID-10. 33 tools, MIT.
WHO ICD-10/ICD-11 diagnosis codes. Lookup, search, chapters via official WHO API.
