Azure AHDS FHIR MCP Server
The Azure AHDS FHIR MCP Server provides a Model Context Protocol (MCP) interface for interacting with Azure FHIR servers to perform healthcare data operations:
Search FHIR Resources: Perform searches on FHIR resources using specific search parameters via the
search_fhirtoolAccess Resource Collections: Retrieve collections of standard FHIR resources (Patient, Observation, Medication) via MCP resource protocol (e.g.,
fhir://Patient/)Access Specific Resources: Retrieve specific FHIR resources by ID (e.g.,
fhir://Observation/{id})Secure Authentication: Utilize OAuth2 for secure access with client ID, client secret, and tenant ID
Developer-Friendly: Supports local development environments with customizable logging levels
Allows loading configuration from .env files for development environments, supporting variables like fhirUrl, clientId, clientSecret, and tenantId.
Enables contributions through GitHub's pull request workflow, with specific guidance on forking and submitting changes.
Supports development setup with Linux-specific virtual environment creation commands.
Provides specific installation paths and configuration guidance for running on macOS systems.
Built on Python 3.13+, offering a Pythonic implementation of the MCP server for Azure FHIR integration.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Azure AHDS FHIR MCP Serversearch for patients with diabetes diagnosis"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
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.
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=falseKeep
HTTP_TRANSPORT=falseto use stdio transportUses 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.
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.After the app is created, capture the generated
Application (client) IDandDirectory (tenant) IDfor later use.Under Expose an API, select Set for the Application ID URI and accept the suggested value
api://{appId}. Add a scope nameduser_impersonationwith admin consent display/description also set touser_impersonation.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 serverclientSecretsetting.Under Authentication, add the following Web redirect URIs to support the FastMCP OAuth proxy:
http://localhost:9002/auth/callbackEnsure Default client type remains No so the app stays confidential.
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=trueRequires
HTTP_TRANSPORT=true
Start the MCP server with:
uv pip install -e .
uv run --env-file .env azure-fhir-mcp-serverUpdate 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 |
| Azure FHIR server base URL (include | - | Yes |
| Azure App registration client ID | - | Yes |
| Azure App registration client secret | - | Yes |
| Azure AD tenant ID | - | Yes |
| Enable FastMCP Azure OAuth proxy integration |
| No |
| Run the MCP server over HTTP transport (required for OAuth proxy) |
| No |
| Port exposed when |
| No |
| Override FHIR audience scope for the OBO flow (space-separated) |
| No |
| Public base URL of your FastMCP server |
| No |
| OAuth callback path appended to the base URL |
| No |
| Azure App registration Application ID URI |
| No |
| Space-separated scopes requested by the Azure provider |
| No |
| Optional space-separated scopes added to the authorize request | - | No |
| Logging level |
| No |
Available Tools 🔧
FHIR Resource Operations
search_fhir- Search for FHIR resources based on a dictionary of search parametersget_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 resourcesfhir://Patient/{id}- Access a specific Patient resourcefhir://Observation/- Access all Observation resourcesfhir://Observation/{id}- Access a specific Observation resourcefhir://Medication/- Access all Medication resourcesfhir://Medication/{id}- Access a specific Medication resourceAnd 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-server2 - Create and activate virtual environment:
Linux/macOS:
python -m venv .venv
source .venv/bin/activateWindows:
python -m venv .venv
.venv\Scripts\activate3 - Install dependencies:
pip install -e ".[dev]"4 - Copy and configure environment variables:
cp .env.example .envEdit .env with your settings:
fhirUrl=https://your-fhir-server.azurehealthcareapis.com/fhir
clientId=your-client-id
clientSecret=your-client-secret
tenantId=your-tenant-id5 - 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 -sContributions 🤝
Contributions are welcome! Please feel free to submit a Pull Request.
Fork the repository
Create your feature branch (
git checkout -b feature/AmazingFeature)Commit your changes (
git commit -m '✨ Add some AmazingFeature')Push to the branch (
git push origin feature/AmazingFeature)Open a Pull Request
License ⚖️
Licensed under MIT - see LICENSE.md file.
This is not an official Microsoft or Azure product.
Available Tools
1 toolsearch_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
| Name | Required | Description | Default |
|---|---|---|---|
| resource_type | Yes | ||
| search_params | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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
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.
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.
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.
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
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
- AlicenseNot gradedqualityDmaintenanceAn MCP server that provides healthcare tools for interacting with FHIR data and medical resources on EMRs like Cerner and Epic1MIT
- AlicenseNot gradedqualityDmaintenanceA 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.85MIT
- AlicenseNot gradedqualityDmaintenanceA server that implements the Model Context Protocol (MCP) with StreamableHTTP transport, enabling standardized interaction with model services through a RESTful API interface.3222MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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