LabscoMCP early access ↗
wso2MCP SERVER · OFFICIAL PROJECT

FHIR MCP Server

Search, read and write FHIR resources from an MCP client — SMART-on-FHIR authorization, and FHIRPath filters to keep bundles from swamping the context.

by wso2 ↗Biomedical: Genomics & Clinical Data✓ Official

LABSCO SUMMARY

Full read and write against FHIR, with a filter that keeps bundles readable.

Most FHIR integrations stall on the same two things: the payloads are enormous and the authorization dance is specific to each vendor. This one answers both — FHIRPath expressions travel with the request so a search can return two fields instead of a bundle, and the SMART-on-FHIR path is demonstrated end to end against the Epic sandbox rather than described. Note that create, update and delete are in the tool list: the scopes you grant are what decides whether an assistant can write to a chart, so scope the client narrowly before you point it at anything real.

What it is

An MCP server from WSO2 that sits between an assistant and a FHIR API server. It speaks stdio, SSE or streamable HTTP, authenticates against the FHIR server using SMART-on-FHIR, and covers the standard interactions — capability discovery, search, read, create, update and delete — for any resource type the server supports. The README demonstrates it against both a public HAPI FHIR server with no authorization and the Epic sandbox with the full OAuth 2.0 authorization code flow.

What you get

  • get_capabilities — what a resource type supports: its search parameters and custom operations
  • search — a standard FHIR search on a resource type, returning the matching bundle
  • read — one resource instance by type and id, optionally narrowed with search parameters or a custom operation such as $everything
  • create — persist a new resource from a JSON payload
  • update — replace an existing instance's content with a complete payload
  • delete — remove a specific resource instance
  • get_user — the authenticated user's own FHIR resource, returned as a short profile with fields such as id, name and birthDate
  • Response filtering with FHIRPath: search and read accept response_filter_fhirpaths, so a request can come back as Patient.name and Patient.birthDate instead of whole resources

Requirements

Python 3.8+, uv, and a reachable FHIR API server. FHIR_SERVER_BASE_URL is the one variable you must set. Authorization is on by default and expects FHIR_SERVER_CLIENT_ID, FHIR_SERVER_CLIENT_SECRET and FHIR_SERVER_SCOPES; against a public server such as HAPI you instead set FHIR_SERVER_DISABLE_AUTHORIZATION to True, which is also what the README asks for when running locally through Docker or Docker Compose. FHIR_SERVER_ACCESS_TOKEN bypasses the OAuth flow with a token you already hold — the README limits that to local stdio use and warns against it once the server is reachable over a network. Transport defaults to streamable-http on FHIR_MCP_HOST and FHIR_MCP_PORT, out of the box localhost and 8000, and --transport switches to stdio or sse. Package fhir-mcp-server (0.10.0) on PyPI, run with uvx, from source, or as a container. Apache 2.0.

Setup effort

One command plus credentials — uvx fhir-mcp-server, then supply credentials