MCP FHIR Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| FHIR_BASE_URL | No | FHIR server base URL | http://localhost:8080/fhir |
| FHIR_ALLOW_READ | No | Enable GET operations | true |
| FHIR_AUTH_TOKEN | No | Bearer token for authentication | |
| FHIR_ALLOW_WRITE | No | Enable POST/PUT/PATCH/DELETE operations | true |
| FHIR_ALLOWED_METHODS | No | Comma-separated HTTP methods (overrides READ/WRITE). Examples: GET, POST, GET,POST, GET,POST,PUT |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Server capabilities have not been inspected yet.
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| write_fhir_resourceA | Write a FHIR resource to the FHIR server. This tool:
Args: resource: A FHIR resource as a JSON object (dict) custom_headers: Optional dictionary of custom HTTP headers to include in the request. For Zus servers, use {"Zus-Account": "builder-id"} for multi-tenant access. Returns: A status message indicating success or detailed error information |
| read_fhir_resourceA | Read a FHIR resource by type and ID from the FHIR server. Args: resource_type: The FHIR resource type (e.g., "Patient", "Observation") resource_id: The ID of the resource to read custom_headers: Optional dictionary of custom HTTP headers to include in the request. For Zus servers, use {"Zus-Account": "builder-id"} for multi-tenant access. Returns: The FHIR resource as JSON or an error message |
| search_fhir_resourcesB | Search for FHIR resources using query parameters. Args: resource_type: The FHIR resource type to search (e.g., "Patient", "Observation") search_params: Optional dictionary of search parameters (e.g., {"name": "Smith", "gender": "female"}) custom_headers: Optional dictionary of custom HTTP headers to include in the request. For Zus servers, use {"Zus-Account": "builder-id"} for multi-tenant access. Returns: A FHIR Bundle containing matching resources or an error message |
| get_patient_zus_upidA | Get the Zus UPID (Universal Patient ID) for a Patient resource from Zus FHIR server. This is a Zus-specific tool for working with Zus Health's FHIR API. Searches for a Patient by first and last name, optionally filtered by builderID, then extracts the Zus UPID from the Patient's identifiers. Args: first_name: Patient's first name last_name: Patient's last name builder_id: Optional Zus builder ID (string) to filter the search Returns: The Zus UPID value or an error message if not found |
| get_fhir_configB | Get the current FHIR server configuration. Returns: Current configuration settings |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 5 tools
Most tools have distinct purposes, but get_fhir_config overlaps slightly with general FHIR operations as it's a configuration tool rather than a core FHIR resource operation. The other tools (read, search, write, get_patient_zus_upid) are clearly differentiated by their specific actions and targets.
Tools follow a consistent verb_noun pattern (get_fhir_config, read_fhir_resource, search_fhir_resources, write_fhir_resource), with get_patient_zus_upid being a minor deviation due to its Zus-specific naming. Overall, the naming is predictable and readable.
Five tools is reasonable for a FHIR server, covering core operations like read, search, and write, plus configuration and a Zus-specific utility. It's slightly thin for full FHIR coverage but well-scoped for basic interactions.
The toolset covers read, search, and write operations, but lacks update and delete for full CRUD lifecycle management. The inclusion of get_fhir_config and a Zus-specific tool adds utility, but the absence of update/delete operations is a notable gap for FHIR resource management.