FHIR MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| FHIR_MCP_HOST | No | The hostname or IP address the MCP server should bind to (e.g., localhost for local-only access, or 0.0.0.0 for all interfaces). | localhost |
| FHIR_MCP_PORT | No | The port on which the MCP server will listen for incoming client requests. | 8000 |
| FHIR_SERVER_SCOPES | No | A space-separated list of OAuth2 scopes to request from the FHIR authorization server (e.g., user/Patient.read user/Observation.read). Add fhirUser openid to enable retrieval of user context for the get_user tool. | |
| FHIR_MCP_SERVER_URL | No | If set, this value will be used as the server's base URL instead of generating it from host and port. Useful for custom URL configurations or when behind a proxy. | |
| FHIR_SERVER_BASE_URL | No | The base URL of the FHIR server (e.g., https://hapi.fhir.org/baseR4). This is used to generate tool URIs and to route FHIR requests. | |
| FHIR_SERVER_CLIENT_ID | No | The OAuth2 client ID used to authorize MCP clients with the FHIR server. | |
| FHIR_MCP_REQUEST_TIMEOUT | No | Timeout duration in seconds for requests from the MCP server to the FHIR server. | 30 |
| FHIR_SERVER_ACCESS_TOKEN | No | The access token to use for authenticating requests to the FHIR server. If this variable is set, the server will bypass the OAuth2 authorization flow and use this token directly for all requests. | |
| FHIR_SERVER_CLIENT_SECRET | No | The client secret corresponding to the FHIR client ID. Used during token exchange. | |
| FHIR_SERVER_DISABLE_AUTHORIZATION | No | If set to True, disables authorization checks on the MCP server, allowing connections to publicly accessible FHIR servers. |
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
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_capabilitiesA | Retrieves metadata about a specified FHIR resource type, including its supported search parameters and custom operations. This tool MUST always be invoked before performing any resource operation (such as search, read, create, update, or delete) to discover the valid searchParams and operations permitted for that resource type. Do not use this tool to fetch actual resources. |
| searchA | Executes a standard FHIR |
| readA | Performs a FHIR |
| createA | Executes a FHIR |
| updateA | Performs a FHIR |
| deleteA | Execute a FHIR |
| get_userA | Retrieves the authenticated user's FHIR profile. Use this tool when you need to access the current user's demographic and contact details. |
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 7 tools
Each tool has a clearly distinct purpose aligned with FHIR operations: create, delete, get_capabilities, get_user, read, search, and update. There is no overlap in functionality; for example, read retrieves a single resource by ID, while search queries multiple resources, and get_capabilities fetches metadata rather than resources. The descriptions reinforce these boundaries, making misselection unlikely.
The naming is mostly consistent with a verb-based pattern (create, delete, read, search, update) and underscores for multi-word names (get_capabilities, get_user). However, get_capabilities and get_user deviate slightly from the simpler verb style of other tools, though they remain readable and follow a similar structure. This minor inconsistency prevents a perfect score.
With 7 tools, this server is well-scoped for FHIR operations, covering core interactions like CRUD (create, read, update, delete), search, metadata discovery (get_capabilities), and user context (get_user). Each tool earns its place without redundancy, and the count is typical for a domain-specific server, avoiding bloat or thin coverage.
The tool set provides complete coverage for FHIR interactions, including all essential CRUD operations (create, read, update, delete), search for queries, get_capabilities for metadata discovery, and get_user for authentication context. There are no obvious gaps; agents can perform full lifecycle management and queries without dead ends in this domain.