Specialist fields

FHIR MCP Server: agents on any FHIR health data API

WSO2's server exposes any FHIR API to agents: search, read, create, update and delete resources, with SMART-on-FHIR auth and FHIRPath response filtering.

Project and installation docs

View project

https://github.com/wso2/fhir-mcp-server

When hospitals and health software exchange data, the standard is usually FHIR: patients, lab results and medications are standardized resources read and written over a REST API. WSO2’s FHIR MCP Server hands that API to an agent, so whether the backend is open-source HAPI FHIR or an EHR like Epic, the agent works through the same set of tools. It’s maintained by the integration company WSO2 and had about 140 stars as of 2026-10-06.

What it does

  • Capability discovery: get_capabilities lists the search parameters and custom operations a resource type supports, so the agent knows what it can ask.
  • Search and read: search takes FHIR search parameters, read fetches by ID, and both can call extended operations such as $everything.
  • Writes: create, update and delete map to FHIR’s own interactions.
  • Only the fields you need: response_filter_fhirpaths trims results with FHIRPath expressions, for example just Patient.name and Patient.birthDate, which saves a lot of context.
  • Auth: SMART-on-FHIR OAuth 2.0 authorization code flow, with a demo video against the Epic sandbox; get_user returns the signed-in user’s patient profile.

Who it’s for

  • Health IT teams who want an agent to query records in plain language on a test environment.
  • Developers of clinical AI apps who need one standard interface across several FHIR backends.

Setup

Needs Python 3.8+, uv and a reachable FHIR server. Set FHIR_SERVER_BASE_URL (plus client ID, secret and scopes for auth, or FHIR_SERVER_DISABLE_AUTHORIZATION=True), then start it; it listens on http://localhost:8000 by default:

uvx fhir-mcp-server

Point your client at the Streamable HTTP endpoint:

"servers": {
  "fhir": {
    "type": "http",
    "url": "http://localhost:8000/mcp"
  }
}

The repo’s docker-compose.yml brings up HAPI FHIR and PostgreSQL alongside it for local testing.

Our take

Of the FHIR servers we looked at, this is the most general: no vendor lock-in, tools that map straight onto standard FHIR interactions, and FHIRPath filtering that tames FHIR’s oversized responses. The main risk is write access. update and delete act on real clinical records, so grant read-only scopes before connecting a production system and turn on call confirmation in your client. Health records are sensitive personal data, so deployments have to meet local privacy law, and nothing the agent says counts as medical advice. Licensed Apache-2.0.