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 Score Discussions Admin

Python

Hybrid

PyPI Version Stars Downloads

License Python Versions Build Status AI-Assisted Development DOI

Substack Discord

Agents read clinical data fine — writing it back correctly is the hard part, and generic agent frameworks don't check it. HealthChain gives any model or agent typed, validated FHIR tools they can trust: the right code from the right system, on the right patient, with a valid status. Plus real-time EHR connectivity and production deployment — so what you build holds up outside the demo.

Installation

pip install healthchain

Related MCP server: FHIR MCP Server

Quick Start

# Scaffold a FHIR Gateway project
healthchain new my-app -t fhir-gateway
cd my-app

# Run locally
healthchain serve

Edit app.py to add your model, and healthchain.yaml to configure deployment settings.

See the CLI reference for all commands.

Core Features

The quickest way for AI developers and researchers to ship healthcare AI — everything you need out of the box, built to scale with you.

Why HealthChain?

Every serious healthcare AI project builds the same integration infrastructure from scratch. Whether you're deploying a logistic regression, a 70B-parameter model, or an agentic workflow, the wall between a trained model and a live clinical system is the same: real FHIR APIs, validated writes, multi-site deployments, auditable governance. No off-the-shelf solution exists, and engineers who understand both AI and healthcare protocols are scarce and hard to retain.

HealthChain handles that complexity so you can focus on what actually matters: the model and the patient.

Optimized for real-time - Connect to live FHIR APIs and integration points instead of stale data exports
Validation built in - Type-safe FHIR resources and validation reports that catch broken data before it ships — including spec-invalid clinical codes that type checks alone let through
No invented facts - Helpers never add clinical claims you didn't pass: no auto-generated timestamps, no guessed statuses — what enters the record is exactly what your model produced
Bring any model or agent - LLMs, agents, or classical ML — and output validated FHIR
Works with your existing stack - Integrates with FastAPI, MCP, and LangChain
Production-ready foundations - Dockerized deployment, configurable security, and an architecture built for NHS and HIPAA environments

🏆 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

🤝 Partnerships & Production Use

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

Creating a Gateway [Docs]

from healthchain.gateway import HealthChainAPI, FHIRGateway
from healthchain.fhir.r4b import Patient

# Create healthcare application
app = HealthChainAPI(title="Multi-EHR Patient Data")

# Connect to multiple FHIR sources
fhir = FHIRGateway()
fhir.add_source("epic", "fhir://fhir.epic.com/r4?client_id=epic_client_id")
fhir.add_source("cerner", "fhir://fhir.cerner.com/r4?client_id=cerner_client_id")

@fhir.aggregate(Patient)
def enrich_patient_data(id: str, source: str) -> Patient:
    """Get patient data from any connected EHR and add AI enhancements"""
    bundle = fhir.search(
        Patient,
        {"_id": id},
        source,
        add_provenance=True,
        provenance_tag="ai-enhanced",
    )
    return bundle

app.register_gateway(fhir)

# Available at: GET /fhir/transform/Patient/123?source=epic
# Available at: GET /fhir/transform/Patient/123?source=cerner

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

Giving 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 straight from the terminal, no code:

healthchain mcp --bundle patient_bundle.json

Building 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

🔒 Security foundations — API-key authentication, audit logging, and TLS, configured via healthchain.yaml and enforced by the gateway middleware
📋 Governance as config — clinical safety, data access agreements, and compliance standards for NHS/HIPAA deployments as a first-class deployment artifact in healthchain.yaml
🔌 Deeper EHR connectivity — more FHIR sources, live data patterns, and real-world integration examples from pilot deployments
📊 Observability — deployment telemetry and audit trails for healthcare systems
🤖 A toolkit for clinical AI agents — typed FHIR tools with validation and terminology built in, served over MCP and LangChain

🤝 Contributing

HealthChain is built by and for the next generation of healthcare developers — researchers moving models from retrospective data into live systems, AI developers who don't want to spend months learning FHIR before they can ship anything. The best contributions come from people who have hit a real problem and have something specific to say about it.

Get started:

Working with healthcare or research data? Contribute a cookbook — bring your use case, 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.

See also groundeval — the open-source eval harness for healthcare AI agents.

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.

ParametersJSON Schema

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').

ParametersJSON Schema

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.

ParametersJSON Schema

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.

ParametersJSON Schema

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).

ParametersJSON Schema

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.

ParametersJSON Schema

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.

ParametersJSON Schema

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.

ParametersJSON Schema

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.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

ResponsivenessWithin a week

Resources

GitHub Repository

Need Help?

Related Servers

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
2
mcpOAuth
com.medplum
Securely access and manage FHIR healthcare data stored in Medplum.
Biology & Medicine Databases
22,670
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
230
SnipgetOAuth
ai.snipget
300+ deterministic data utilities for AI agents: validate, normalize, parse, match, redact.
Developer Tools Data Platforms
1

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
98
MIT
FHIR MCP Server
Biology & Medicine Databases Search
sumithasb
-
license
Not graded
quality
Not graded
maintenance
Enables seamless integration with FHIR APIs for healthcare applications, allowing users to search, retrieve, create, update, and analyze clinical information through natural language interactions. Supports SMART-on-FHIR authentication and works with various healthcare systems like EPIC and HAPI FHIR servers.
Updated a year ago (2025-09-06 06:08 UTC)
-
FhirMCP
Biology & Medicine Databases Security
xSoVx
A
license
Not graded
quality
D
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 year ago (2025-09-12 20:20 UTC)
MIT
MCP FHIR Server
Biology & Medicine Databases
mrosata
F
license
A
quality
D
maintenance
Provides read/write access to any FHIR-compliant healthcare API with built-in validation, supporting resource management, search operations, and granular permissions through natural language.
Updated 10 months ago (2025-10-29 18:05 UTC)
5
1
-