What can you do with this server?

This server provides FHIR tools for healthcare AI agents to build, validate, read, and code clinical data. * Build FHIR resources from flat fields (Condition, MedicationStatement, Observation, AllergyIntolerance, Patient) with automatic nesting and validation. * Validate FHIR resources against spec and value-set bindings, returning issues to correct. * Load FHIR Bundles from file or JSON string to serve as the working data for read tools. * Read resources as full FHIR JSON or flattened coded entries (with status filtering and medication reference resolution). * Resolve FHIR references (e.g., Patient/123, urn:uuid, contained refs) within the loaded bundle. * Look up terminology codes via free-text search or browse the full catalog, ensuring no invented codes.

Which integrations are available for this server?

Integrates with FastAPI to build healthcare APIs with FHIR gateway and validation capabilities. Offers FHIR toolkit integration for LangChain agents, allowing validated FHIR resource creation and search.

de en es ja ko ru zh

HealthChain

by healthchainai

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

PyPI Version Stars Downloads

License Python Versions Build Status AI-Assisted Development DOI

Substack Discord

Connect Python pipelines and applications to live FHIR APIs, build and validate structured output, and deliver it through REST, CDS Hooks, CDA, MCP, or LangChain.

Installation

pip install healthchain

Related MCP server: FhirMCP

What HealthChain Does

HealthChain puts a consistent FHIR boundary around your Python code: live data in, your own logic in the middle, and validated FHIR out. Built for research software, healthcare data, and AI teams.

Why HealthChain?

Every healthcare data team rebuilds the same integration layer. Whether your logic is rule-based, a logistic regression, or an agent, it needs authenticated access to real FHIR APIs and a reliable way to turn output into coded FHIR. Pipelines tied to one site's warehouse don't travel, and structural or coding errors may only be discovered downstream.

HealthChain handles that layer so you can focus on your logic and your domain.

Live data, not exports — Connect to live FHIR APIs instead of site-specific warehouse queries and stale extracts
Keep connection details out of pipeline logic — Load endpoints and credentials from environment-backed configuration
Build FHIR with less boilerplate — Use flat, typed helpers instead of manually assembling deeply nested resources
Catch errors early — Get structured validation reports with failing field paths and actionable diagnostics
Resolve codes instead of guessing them — Map free text through a swappable terminology lookup before building a resource
Choose how to deliver the result — Expose output through FHIR REST services, CDS Hooks, SOAP/CDA, MCP, or LangChain

🏆 Recognition & Community

Featured & Presented:

Featured in TLDR AI Newsletter (900K+ developers)
Featured by Medplum for open source integration with Epic
Presented at NHS Python Open Source Conference (watch talk)
Built from NHS AI deployment experience – read the origin story

🤝 Pilots & Partnerships

Exploring HealthChain for your product or organization? Get in touch to discuss integrations, pilots, or collaborations, or join our Discord to connect with the community.

Usage Examples

Build a FHIR Service

Expose Multiple FHIR Sources [Docs]

from healthchain.gateway import HealthChainAPI, FHIRGateway
from healthchain.gateway.clients import FHIRAuthConfig
from healthchain.fhir.r4b import Bundle, Patient

# Create a FHIR-connected service
app = HealthChainAPI(title="Multi-EHR Patient Data")

# Credentials are loaded from EPIC_* and CERNER_* environment variables
fhir = FHIRGateway()
fhir.add_source("epic", FHIRAuthConfig.from_env("EPIC").to_connection_string())
fhir.add_source("cerner", FHIRAuthConfig.from_env("CERNER").to_connection_string())

@fhir.aggregate(Patient)
def patient_data(id: str, source: str) -> Bundle:
    """Fetch patient data from any configured FHIR source."""
    bundle = fhir.search(
        Patient,
        {"_id": id},
        source,
        add_provenance=True,
        provenance_tag="healthchain-source",
    )
    return bundle

app.register_gateway(fhir)

# Available at: GET /fhir/aggregate/Patient?id=123&sources=epic&sources=cerner

if __name__ == "__main__":
    app.run(port=8888)

Scaffold with the CLI

Turn a working pipeline into a configurable FHIR service:

healthchain new my-app -t fhir-gateway
cd my-app
healthchain serve

Add your logic in app.py. Use healthchain.yaml to configure FHIR sources and service settings while keeping credentials in environment variables. See the CLI reference for all commands.

Agent and Assistant Workflows

Give an Agent FHIR Tools [Docs]

from healthchain.tools import FHIRToolkit

# One toolkit: build, validate, read, and code FHIR — as typed agent tools
kit = FHIRToolkit(bundle="patient_bundle.json")

kit.as_mcp().run()          # serve to Claude or any MCP client
tools = kit.as_langchain()  # or drop into a LangChain agent

Or serve the tools straight from the terminal:

healthchain mcp --bundle patient_bundle.json

Build with an AI Assistant

Install the HealthChain plugin to give Claude Code or Codex the current API, CLI, and recipes:

# Claude Code
/plugin marketplace add healthchainai/HealthChain
/plugin install healthchain@healthchain

# Codex
codex plugin marketplace add healthchainai/HealthChain
codex plugin add healthchain@healthchain

Or point any assistant at llms.txt for a map of the current API docs.

🛣️ What we're building towards

🔌 Deeper FHIR connectivity — more authentication patterns, write workflows, and real-world examples from pilot deployments
🧪 Broader validation — cover more resource types and value-set bindings, with clearer correction reports and optional server-backed profile validation
🧭 Terminology integrations — connect the TerminologyLookup interface to FHIR terminology servers and licensed vocabularies
🔎 Traceable data movement — carry provenance, validation results, and source errors through transformations and downstream delivery
🧱 Reusable data workflows — strengthen the patterns for moving research extracts, claims, and application data behind consistent FHIR interfaces

🤝 Contributing

Building research software or working with healthcare data? Contribute a cookbook — bring your use case, and I'll personally support you through it
Read CONTRIBUTING.md for guidelines
Technical questions and ideas → GitHub Discussions
Pilots and partnerships → email

🤗 Acknowledgements

This project builds on fhir.resources and CDS Hooks standards developed by HL7 and Boston Children's Hospital.

Available Tools

8 tools

build_resourceA

Build a FHIR resource from flat fields and validate it. Call this instead of writing FHIR JSON by hand — it does the nesting (CodeableConcepts, Dosage) and returns {ok, resource} or {ok: false, issues} to correct. Supported resource_type values: Condition, MedicationStatement, Observation, AllergyIntolerance, Patient. Use a code returned by lookup_code, never an invented one.

Name	Required	Description	Default
`code`	No
`unit`	No
`onset`	No
`value`	No
`gender`	No
`status`	No
`system`	No
`display`	No
`subject`	No
`dose_unit`	No
`birth_date`	No
`dose_value`	No
`dosage_text`	No
`resource_type`	Yes
`frequency_per_day`	No
`effective_datetime`	No

TDQS

A3.8/5.0

Behavior3/5

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

Discloses nesting behavior (CodeableConcepts, Dosage), return format {ok, resource} or {ok: false, issues}, and validation. No annotations provided, so description carries full burden. However, it's ambiguous whether the resource is persisted; could be clearer about side effects.

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?

Three sentences, front-loaded with purpose and key guidance, no wasted words. Efficient and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, return format, supported types, and a critical rule about codes. However, with 16 parameters and no output schema, the description lacks detailed parameter mapping and resource-type-specific instructions, leaving gaps for correct usage.

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

Parameters2/5

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

Schema has 16 parameters with 0% coverage, but description only mentions resource_type and code usage rule. Does not explain parameters like onset, value, unit, etc., or how they map to resource types. The description adds minimal value over the schema for parameter meaning.

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 clearly states the tool builds and validates a FHIR resource from flat fields, lists supported resource types, and contrasts with writing FHIR JSON manually, distinguishing it from siblings like validate_resource and lookup_code.

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?

Provides clear guidance: 'Call this instead of writing FHIR JSON by hand' and 'Use a code returned by lookup_code, never an invented one.' Also lists supported resource types. Missing explicit when-not-to-use or comparison to siblings.

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

get_coded_entriesA

Read the coded identity of every resource of a type in the loaded bundle as flat records (code/display/system/status/authored_on/value/unit). Call this first for questions about conditions, medications, allergies, or observations — it resolves medicationReference to the actual Medication for you. Optionally filter by status (e.g. 'active').

Name	Required	Description	Default
`status`	No
`resource_type`	Yes

TDQS

A4/5.0

Behavior4/5

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

With no annotations, the description fully discloses that this is a read operation that returns flat records with specific fields and optionally filters by status. It does not mention destructive actions, authentication, or rate limits, but for a read-only tool the disclosure is sufficient. The behavior is transparent for typical use.

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 two sentences, front-loaded with the main purpose and followed by usage guidance. Every sentence provides value with no redundancy. Ideal conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations or output schema, the description covers the tool's purpose, typical use case, return format, and optional filtering. It lacks details on edge cases (e.g., invalid resource type, empty results) but is complete enough for primary use.

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

Parameters3/5

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

Schema coverage is 0%, so the description must compensate. It explains that resource_type is the type of resource (suggesting conditions, medications, etc.) and that status is an optional filter with example 'active'. This adds meaning beyond the bare schema, but does not fully clarify valid resource types or constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool reads coded identity of every resource of a type in the loaded bundle as flat records with specific fields. It specifies the resource types (conditions, medications, allergies, observations) and that it resolves medicationReference. This is specific and distinct from sibling tools like get_resources or resolve_reference, though not explicitly compared.

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 advises to call this first for questions about conditions, medications, allergies, or observations, providing clear usage context. It also notes that it resolves medicationReference automatically. However, it does not explicitly state when not to use it or mention alternative tools.

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

get_resourcesA

Get all resources of a type from the loaded bundle as full FHIR JSON. Call this when you need fields the flattened get_coded_entries view doesn't carry.

Name	Required	Description	Default
`resource_type`	Yes

TDQS

A3.9/5.0

Behavior3/5

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

No annotations provided. Description indicates it is a read operation returning full FHIR JSON, and implies prerequisite of a loaded bundle. Lacks details on permissions, errors, or other behavioral traits.

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?

Two sentences, no fluff, front-loaded with core action and differentiator.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given low complexity (1 param, no output schema), description covers purpose, usage, and return format. Missing parameter details and behavioral transparency, but overall sufficient.

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

Parameters2/5

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

Single parameter resource_type has no description in schema (0% coverage). Description fails to add any meaning, e.g., valid values or examples.

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?

Clearly states it gets all resources of a type as full FHIR JSON, and distinguishes from sibling get_coded_entries by noting it carries fields the flattened view doesn't.

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?

Explicitly says when to call this tool ('when you need fields...') and implies alternative (get_coded_entries). Does not provide when-not or other alternatives.

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

list_codesA

List every code in the local terminology catalog, optionally filtered to one code system URI. Call this to browse what codes are available (e.g. to build a mention list); use lookup_code to search by name.

Name	Required	Description	Default
`system`	No

TDQS

A4.4/5.0

Behavior3/5

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

With no annotations, description carries full burden. Reveals it lists all codes with optional filter, but doesn't mention pagination, error handling for invalid system URIs, or return format. Minimal but not misleading.

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?

Two sentences: first states purpose and filtering, second provides usage guidance and alternative. Front-loaded and efficient with no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list tool with one optional parameter and no output schema, description covers core purpose and usage. Lacks details on output format or pagination, but sufficient 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?

Schema coverage is 0%, but description explains the only parameter 'system' as a filter by code system URI. Single parameter is well-clarified, adding meaning beyond schema.

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?

Clearly states verb 'list' and resource 'codes in local terminology catalog', with optional filter by system URI. Distinguishes from sibling 'lookup_code' by contrasting browse vs search.

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?

Explicitly says when to call this tool ('to browse what codes are available') and when to use the alternative ('use lookup_code to search by name'). Provides concrete use case example.

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

load_bundleA

Load a FHIR Bundle from a file path or JSON string and make it the working bundle for the read tools. Call this first when given bundle data. Invalid bundles return issues[] locating each problem (e.g. Bundle.entry[2].resource.subject).

Name	Required	Description	Default
`source`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

No annotations provided, so the description carries full burden. It explains error behavior with invalid bundles returning issues[] and gives an example. However, it does not mention overwriting previous bundle or idempotency.

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?

Two sentences, no fluff. First sentence states purpose, second adds usage order and error handling. Every sentence is valuable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description adequately covers purpose, usage order, and error behavior. It could clarify the concept of 'working bundle' or return value, but overall is complete enough.

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 schema has 0% description coverage, but the description adds meaning by stating 'from a file path or JSON string', clarifying the source parameter's two possible formats. This compensates well.

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 clearly states the tool loads a FHIR Bundle from a file path or JSON string and sets it as the working bundle for read tools. This distinguishes it from sibling tools like build_resource or get_resources.

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 says 'Call this first when given bundle data', giving clear usage context. It does not list when not to use it or alternatives, but the context is sufficient.

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

lookup_codeA

Search the terminology catalog for codes matching free text (e.g. 'metoprolol 25', 'type 2 diabetes'). Call this whenever you need a code — use a returned candidate, never invent or recall one. Results are ranked tightest-match-first; optionally restrict to one code system URI.

Name	Required	Description	Default
`query`	Yes
`system`	No

TDQS

A4.2/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It mentions that results are ranked 'tightest-match-first', which is a useful behavioral trait. However, it does not disclose auth requirements, rate limits, result limits, or error handling. The description is adequate but not comprehensive.

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 extremely concise: three sentences covering purpose, usage guidance, and ranking/system restriction. Every sentence adds value with no fluff. Front-loaded with the core action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description covers the essential points: what it does, when to use it, ranking, and optional parameter. It could be more complete by mentioning result format or what to do if no match, but it is sufficient for a simple lookup tool.

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?

Schema description coverage is 0%, so the description must compensate. It provides concrete examples for 'query' and explains the 'system' parameter as 'optionally restrict to one code system URI'. This adds meaning beyond the schema, though it does not elaborate on what a code system URI looks like.

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 clearly states the verb 'search' and the resource 'terminology catalog for codes' with examples. It distinguishes itself from inventing codes by explicitly saying 'never invent or recall one', and the sibling 'list_codes' is a different operation (listing all vs. free-text search).

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 says 'Call this whenever you need a code' and provides a caution against inventing codes. It also mentions optional system restriction. However, it does not explicitly exclude scenarios or compare with sibling tools like 'list_codes' or 'get_coded_entries', so it loses one point.

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

resolve_referenceA

Resolve a FHIR reference (e.g. 'Patient/123', 'urn:uuid:...') to its target resource within the loaded bundle. For a contained reference ('#med1'), also pass parent_resource_id — the id of the resource the reference appears in.

Name	Required	Description	Default
`reference`	Yes
`parent_resource_id`	No

TDQS

A4.2/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. It discloses the behavior for contained references but does not mention error handling, what happens if the reference is not found, or any other side effects. Adequate but not comprehensive.

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 two sentences with no redundancy. The first sentence states the primary purpose, and the second covers a specific use case. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity and lack of output schema or annotations, the description covers the main use cases (absolute and contained references). It does not cover error scenarios or edge cases, but for a reference resolution tool it is reasonably complete.

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?

Schema description coverage is 0%, so the description must add meaning. It explains the 'reference' parameter with example formats ('Patient/123', 'urn:uuid:...') and clarifies that 'parent_resource_id' is needed for contained references. This adds significant value beyond parameter names.

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 clearly states the verb 'Resolve', the resource type (FHIR reference), and the context ('within the loaded bundle'). It distinguishes between absolute references and contained references, making the tool's purpose precise and well-defined.

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 explains when to use the tool and provides specific guidance for contained references (parent_resource_id). However, it does not explicitly exclude cases when not to use it or mention alternative tools from the sibling list.

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

validate_resourceA

Validate a FHIR resource (JSON object) against the spec, including required value-set bindings. Call this after constructing or editing FHIR JSON yourself; read issues[] (severity/diagnostics/expression) and correct the resource. Never raises.

Name	Required	Description	Default
`resource`	Yes
`resource_type`	No

TDQS

A3.9/5.0

Behavior3/5

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

No annotations exist, so description must cover behavioral traits. It states 'Never raises' (no exceptions) and mentions return format (issues[] with severity/diagnostics/expression). However, it does not disclose authentication needs, rate limits, or whether it is read-only.

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?

Two tightly written sentences: first defines purpose, second gives usage and output structure. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description explains return value (issues[]). It is sufficient for a validation tool with simple output. Sibling context suggests no further explanation needed.

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

Parameters2/5

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

Schema coverage is 0%, so description must compensate. It explains the 'resource' parameter subtly by referring to a 'FHIR resource (JSON object)', but does not detail the optional 'resource_type' parameter. Minimal added value over schema.

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?

Clearly states verb 'Validate', resource 'FHIR resource', and scope 'against the spec, including required value-set bindings'. This distinguishes it from sibling tools like build_resource or get_resources.

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?

Gives explicit when to use: 'Call this after constructing or editing FHIR JSON yourself'. Also instructs what to do with output: 'read issues[] and correct the resource'. Missing explicit when not to use or alternatives.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

8 tool updatesv0.1.0Jul 28, 2026
- First observedbuild_resource
- First observedget_coded_entries
- First observedget_resources
- First observedlist_codes
- First observedload_bundle
- First observedlookup_code
- First observedresolve_reference
- First observedvalidate_resource

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.2/5.0

Scored 2026-07-28 09:35 across 8 tools

Disambiguation5/5

Each tool has a clear, distinct purpose: building, validating, loading, retrieving, resolving references, and terminology lookup. No two tools overlap in functionality.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using lowercase and underscores, e.g., build_resource, load_bundle, get_resources, lookup_code. This makes the API predictable.

Tool Count5/5

With 8 tools, the set is well-scoped for a FHIR utility server, covering essential operations without being bloated or too sparse.

Completeness4/5

The set covers building, validating, loading, and reading FHIR resources, as well as reference resolution and terminology lookup. Minor gaps like missing update/delete tools or limited build resource types prevent a perfect score.

Maintenance

ActivityMaintained

ResponsivenessResponsive

Resources

Related MCP Connectors

K01 Synthetic Health Data
is.k01
Privacy-preserving synthetic health data generation. FHIR R4/R5 compliant.
Biology & Medicine Research & Data Health & Wellness
21
https://mcp.k01.is/mcp
Anpheros FHIR AOAuth
com.anpheros
HL7 FHIR R4 health-data API for AI agents: free sandbox, 30 synthetic patients, AI-ready context.
Biology & Medicine Health & Wellness
1
https://platform.anpheros.com/mcp
mcpOAuth
com.medplum
Securely access and manage FHIR healthcare data stored in Medplum.
Biology & Medicine Databases
22,760
https://api.medplum.com/mcp/stream
healthclaw-guardrails A
io.github.aks129
Guardrailed FHIR access for AI agents: PHI redaction, audit trail, step-up auth, tenant isolation
Biology & Medicine Security Databases
231
https://mcp-server-production-5112.up.railway.app/mcp

Related MCP Servers

FHIR MCP Server
Biology & Medicine RAG Systems
the-momentum
A
license
A
quality
D
maintenance
Enables LLM-based agents to interact with FHIR healthcare data through natural language prompts, providing full CRUD operations on FHIR resources, document processing, and semantic search capabilities.
Updated a year ago (2025-10-23 13:06 UTC)
13
102
MIT
FhirMCP
Biology & Medicine Databases Security
xSoVx
A
license
Not graded
quality
B
maintenance
Enables LLMs to securely interact with FHIR healthcare servers and HL7 terminology services. Provides comprehensive healthcare data operations with built-in PHI protection, audit logging, and SMART on FHIR authentication.
Updated a month ago (2026-09-13 19:15 UTC)
MIT
FHIR MCP Server
Biology & Medicine Search Databases
wso2
A
license
A
quality
C
maintenance
Provides seamless integration with FHIR APIs, enabling AI/LLM tools to search, retrieve, and analyze clinical healthcare data with support for SMART-on-FHIR authentication and multiple transport protocols.
Updated 13 days ago (2026-10-12 09:41 UTC)
7
681 PyPI
137
Apache 2.0
FHIR MCP Server
Biology & Medicine RAG Systems
sarac083
F
license
Not graded
quality
A
maintenance
Enables LLM-based agents and MCP-compatible clients to query and manipulate FHIR resources through full CRUD tools, with document ingestion, semantic search, LOINC terminology lookup, and OAuth2-authenticated FHIR API integration.
Updated 8 days ago (2026-10-16 18:07 UTC)
-