Skip to main content
Glama
erikhoward

Azure AHDS FHIR MCP Server

by erikhoward

Azure AHDS FHIR MCP Server 🚀

A Model Context Protocol (MCP) server implementation for Azure Health Data Services FHIR (Fast Healthcare Interoperability Resources). This service provides a standardized interface for interacting with Azure FHIR servers, enabling healthcare data operations through MCP tools.

License Python Version MCP

Setup 🛠️

Installation 📦

Requires Python 3.13 or higher and uv.

Install uv first.

Configuration ⚙️

See the FastMCP guidance on mcp.json here: https://gofastmcp.com/integrations/mcp-json-configuration

Client Credentials Flow (default):

  • Used for service-to-service authentication

  • Leave USE_FAST_MCP_OAUTH_PROXY=false

  • Keep HTTP_TRANSPORT=false to use stdio transport

  • Uses Azure AD client credentials flow

{
    "mcpServers": {
        "fhir": {
            "type": "stdio",
            "command": "uvx",
            "args": [
                "azure-fhir-mcp-server"
            ],
            "env": {
                "fhirUrl": "https://your-fhir-server.azurehealthcareapis.com/fhir",
                "clientId": "your-client-id",
                "clientSecret": "your-client-secret",
                "tenantId": "your-tenant-id"
            }
        }
    }
}

OAuth On-Behalf-Of Flow:

Create the Azure App Registration

The OAuth on-behalf-of flow requires a confidential Azure AD application that represents the MCP server.

  1. In the Azure portal, go to Microsoft Entra ID ➜ App registrations ➜ New registration. Give it a descriptive name such as FHIR-MCP-Server, set Supported account types to Single tenant, and leave the redirect URI unset for now.

  2. After the app is created, capture the generated Application (client) ID and Directory (tenant) ID for later use.

  3. Under Expose an API, select Set for the Application ID URI and accept the suggested value api://{appId}. Add a scope named user_impersonation with admin consent display/description also set to user_impersonation.

  4. Under Certificates & secrets, create a New client secret (for example FHIR-MCP-Secret-New). Copy the secret value immediately; it is required for the MCP server clientSecret setting.

  5. Under Authentication, add the following Web redirect URIs to support the FastMCP OAuth proxy:

    • http://localhost:9002/auth/callback Ensure Default client type remains No so the app stays confidential.

  6. Under API permissions, choose Add a permission ➜ APIs my organization uses, search for your Azure Health Data Services FHIR server, and add the delegated scopes required for your scenario. Grant admin consent so the FastMCP proxy can request tokens without an interactive prompt.

  • Environment variables:

    • Set USE_FAST_MCP_OAUTH_PROXY=true

    • Requires HTTP_TRANSPORT=true

  • Start the MCP server with:

uv pip install -e .
uv run --env-file .env azure-fhir-mcp-server
  • Update mcp.json:

{
    "mcpServers": {
        "fhir": {
            "type": "http",
            "url": "http://localhost:9002/mcp"
        }
    }
}

The following is a table of available environment configuration variables:

Variable

Description

Default

Required

fhirUrl

Azure FHIR server base URL (include /fhir)

-

Yes

clientId

Azure App registration client ID

-

Yes

clientSecret

Azure App registration client secret

-

Yes

tenantId

Azure AD tenant ID

-

Yes

USE_FAST_MCP_OAUTH_PROXY

Enable FastMCP Azure OAuth proxy integration

false

No

HTTP_TRANSPORT

Run the MCP server over HTTP transport (required for OAuth proxy)

false

No

FASTMCP_HTTP_PORT

Port exposed when HTTP_TRANSPORT=true

9002

No

FHIR_SCOPE

Override FHIR audience scope for the OBO flow (space-separated)

{fhirUrl}/.default

No

FASTMCP_SERVER_AUTH_AZURE_BASE_URL

Public base URL of your FastMCP server

http://localhost:9002

No

FASTMCP_SERVER_AUTH_AZURE_REDIRECT_PATH

OAuth callback path appended to the base URL

/auth/callback

No

FASTMCP_SERVER_AUTH_AZURE_IDENTIFIER_URI

Azure App registration Application ID URI

api://{clientId}

No

FASTMCP_SERVER_AUTH_AZURE_REQUIRED_SCOPES

Space-separated scopes requested by the Azure provider

user_impersonation

No

FASTMCP_SERVER_AUTH_AZURE_ADDITIONAL_AUTHORIZE_SCOPES

Optional space-separated scopes added to the authorize request

-

No

LOG_LEVEL

Logging level

INFO

No

Available Tools 🔧

FHIR Resource Operations

  • search_fhir - Search for FHIR resources based on a dictionary of search parameters

  • get_user_info - (OAuth only) Returns information about the authenticated Azure user

Resource Access

The server provides access to all standard FHIR resources through the MCP resource protocol:

  • fhir://Patient/ - Access all Patient resources

  • fhir://Patient/{id} - Access a specific Patient resource

  • fhir://Observation/ - Access all Observation resources

  • fhir://Observation/{id} - Access a specific Observation resource

  • fhir://Medication/ - Access all Medication resources

  • fhir://Medication/{id} - Access a specific Medication resource

  • And many more...

Related MCP server: Smart EHR MCP Server

Development 💻

Local Development Setup

1 - Clone the repository:

git clone https://github.com/erikhoward/azure-fhir-mcp-server.git
cd azure-fhir-mcp-server

2 - Create and activate virtual environment:

Linux/macOS:

python -m venv .venv
source .venv/bin/activate

Windows:

python -m venv .venv
.venv\Scripts\activate

3 - Install dependencies:

pip install -e ".[dev]"

4 - Copy and configure environment variables:

cp .env.example .env

Edit .env with your settings:

fhirUrl=https://your-fhir-server.azurehealthcareapis.com/fhir
clientId=your-client-id
clientSecret=your-client-secret
tenantId=your-tenant-id

5 - Claude Desktop Configuration

Open claude_desktop_config.json and add the following configuration.

On MacOs, the file is located here: ~/Library/Application Support/Claude Desktop/claude_desktop_config.json.

On Windows, the file is located here: %APPDATA%\Claude Desktop\claude_desktop_config.json.

{
    "mcpServers": {
        "fhir": {
            "command": "uv",
            "args": [
                "--directory",
                "/path/to/azure-fhir-mcp-server/repo",
                "run",
                "azure_fhir_mcp_server"
            ],
            "env": {
                "LOG_LEVEL": "DEBUG",
                "fhirUrl": "https://your-fhir-server.azurehealthcareapis.com/fhir",
                "clientId": "your-client-id",
                "clientSecret": "your-client-secret",
                "tenantId": "your-tenant-id"
            }
        }
    }
}

6 - Restart Claude Desktop.

Running Tests

# Run all tests
python -m pytest tests/ -v

# Run with coverage
pytest tests/ --cov=src/azure_fhir_mcp_server

# Run specific test
pytest tests/test_fastmcp_metadata.py::TestFastMCPMetadata::test_fastmcp_server_discovery -v

# Run with detailed output
pytest tests/test_fastmcp_metadata.py::TestFastMCPMetadata::test_output_detailed_metadata -v -s

Contributions 🤝

Contributions are welcome! Please feel free to submit a Pull Request.

  1. Fork the repository

  2. Create your feature branch (git checkout -b feature/AmazingFeature)

  3. Commit your changes (git commit -m '✨ Add some AmazingFeature')

  4. Push to the branch (git push origin feature/AmazingFeature)

  5. Open a Pull Request

License ⚖️

Licensed under MIT - see LICENSE.md file.

This is not an official Microsoft or Azure product.

Available Tools

1 tool
search_fhirA

Search FHIR resources using comprehensive Azure FHIR search capabilities.

Supports resource-specific and common search parameters, modifiers, prefixes, chained searches, and result management. Returns paginated results in FHIR searchset bundles.

Key Features: • Resource-specific and common search parameters (_id, _lastUpdated, _tag, etc.) • Search modifiers (:missing, :exact, :contains, :text, :not, etc.) • Prefixes for ordered parameters (gt, lt, ge, le, etc.) • Chained searches (e.g., Encounter?subject:Patient.name=Jane) • Reverse chained searches using _has parameter • Include and revinclude searches (_include, _revinclude) • Result parameters (_count, _sort, _elements, _summary, _total) • Composite search parameters for complex queries • Pagination support with configurable page sizes (max 1000)

Args: resource_type: FHIR resource type to search (e.g., 'Patient', 'Observation', 'Condition') search_params: Dictionary of FHIR search parameters. Common examples: • {"name": "Smith", "_count": 50} - Search patients by name, limit 50 results • {"birthdate": "gt1990-01-01", "_sort": "birthdate"} - Patients born after 1990, sorted • {"identifier": "12345", "_include": "Patient:general-practitioner"} - Include GP • {"code": "77386006", "_include": "Observation:subject"} - Pregnancy observations with patients • {"_lastUpdated": "gt2024-01-01"} - Resources updated after date ctx: MCP Context for logging and progress reporting

Returns: List of matching FHIR resources extracted from searchset Bundle

ParametersJSON Schema
NameRequiredDescriptionDefault
resource_typeYes
search_paramsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: it returns paginated results in FHIR searchset bundles, supports configurable page sizes (max 1000), and handles complex search capabilities. It doesn't mention authentication needs, rate limits, or error handling, but covers most operational aspects well for a search tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections (overview, key features, args, returns) and uses bullet points for readability. It's appropriately sized for a complex tool but could be slightly more concise—some bullet points are verbose. Overall, it's front-loaded with purpose and efficiently organized, with most sentences earning their place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (FHIR search with many features), no annotations, and an output schema present, the description is highly complete. It covers purpose, features, parameters with examples, and return values, compensating for the lack of annotations. The output schema means it doesn't need to detail return structures, and it provides enough context for effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, so the description must fully compensate. It excels by providing detailed parameter semantics: it explains 'resource_type' as 'FHIR resource type to search' with examples, and 'search_params' as a dictionary with comprehensive examples and common use cases. The 'Args' section adds significant value beyond the bare schema, making parameters clear and actionable.

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's purpose: 'Search FHIR resources using comprehensive Azure FHIR search capabilities.' It specifies the verb ('search'), resource ('FHIR resources'), and platform ('Azure FHIR'), making it highly specific. With no sibling tools, it doesn't need differentiation, but the description is comprehensive and unambiguous about what the tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context through its detailed feature list and examples, suggesting it's for complex FHIR queries. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., simpler queries or other FHIR operations). With no sibling tools, this is less critical, but it doesn't provide clear exclusions or prerequisites, leaving usage somewhat open-ended.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

TDQS

A4.1/5.0
Disambiguation5/5

With only one tool, there is no possibility of ambiguity or overlap between tools. The single tool 'search_fhir' has a clearly defined purpose focused on FHIR search operations.

Naming Consistency5/5

The naming follows a consistent snake_case pattern with a clear verb_noun structure ('search_fhir'). With only one tool, there is no inconsistency to evaluate.

Tool Count2/5

A single tool for an FHIR server is insufficient for comprehensive coverage of FHIR operations. FHIR domains typically require CRUD operations (create, read, update, delete) and other interactions beyond just search, making this server feel thin and incomplete for its purpose.

Completeness2/5

The tool surface is severely incomplete for an FHIR server. While the search functionality is detailed, there are significant gaps in basic FHIR operations like creating, reading, updating, or deleting resources, which are essential for full FHIR lifecycle management.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

  • Hosted MCP server for the Healthie EHR & telehealth API: patients, appointments, charting, tasks.

  • The Remote MCP server acts as a standardized bridge between LLM applications (like Claude, ChatGPT, and Cursor) and external services, enabling AI agents to access external tools and resources. Its primary capability is providing a centralized search tool to discover other MCP servers and their respective tools. Unlike local implementations, it runs remotely with OAuth authentication and permission controls for security.

  • The Mercado Pago MCP Server implements the Model Context Protocol to provide AI agents and LLMs with access to Mercado Pago's APIs and tools within compatible development environments. It acts as an intermediary that translates Mercado Pago resources into executable functions (tools) that AI applications can invoke to perform actions and automate flows. The server simplifies integration, enables using documentation to implement or improve code, and optimizes operations through natural language interactions without manual implementations.

  • The Stytch MCP server is a reference implementation that demonstrates remote MCP server authentication and authorization using Stytch Connected Apps. It provides OAuth 2.1-compliant authorization (including PKCE), Dynamic Client Registration, and validates Stytch-issued access tokens to enable AI agents to securely interact with external services through permissioned access, supporting scopes like openid, email, profile, and manage:project_data.

Related MCP Servers

  • A
    license
    Not graded
    quality
    D
    maintenance
    An MCP server that provides healthcare tools for interacting with FHIR data and medical resources on EMRs like Cerner and Epic
    1
    MIT
  • A
    license
    Not graded
    quality
    D
    maintenance
    A Model Context Protocol server that connects AI tools to Electronic Health Records using SMART on FHIR, allowing secure searching, querying, and analysis of patient data from compatible EHRs.
    85
    MIT
  • F
    license
    Not graded
    quality
    D
    maintenance
    A Model Context Protocol server that enables querying FHIR healthcare data using natural language, allowing doctors to retrieve patient information, medications, observations, and other healthcare records.
    1
  • A
    license
    Not graded
    quality
    D
    maintenance
    A server that implements the Model Context Protocol (MCP) with StreamableHTTP transport, enabling standardized interaction with model services through a RESTful API interface.
    322
    2
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/erikhoward/azure-fhir-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server