A
licenseNot graded
qualityD
maintenanceAn MCP server that provides healthcare tools for interacting with FHIR data and medical resources on EMRs like Cerner and Epic
1
MIT
Azure AHDS FHIR MCP Server
by erikhoward
Servidor MCP FHIR de Azure AHDS 🚀
Implementación de un servidor de Protocolo de Contexto de Modelo (MCP) para Azure Health Data Services FHIR (Recursos de Interoperabilidad Rápida para la Atención Médica). Este servicio proporciona una interfaz estandarizada para interactuar con servidores de Azure FHIR, lo que permite la gestión de datos de atención médica mediante herramientas MCP.
Configuración 🛠️
Instalación 📦
Requiere Python 3.13 o superior.
Instale el paquete usando pip :
pip install azure-fhir-mcp-serverConfiguración de MCP ⚙️
Configuración del escritorio de Claude
1 - Editar la configuración del escritorio de Claude:
Abra claude_desktop_config.json y agregue la siguiente configuración.
En MacOs, el archivo se encuentra aquí: ~/Library/Application Support/Claude Desktop/claude_desktop_config.json .
En Windows, el archivo se encuentra aquí: %APPDATA%\Claude Desktop\claude_desktop_config.json .
{
"mcpServers": {
"fhir": {
"command": "azure-fhir-mcp-server",
"env": {
"LOG_LEVEL": "INFO",
"fhirUrl": "https://your-fhir-server.azurehealthcareapis.com/fhir",
"clientId": "your-client-id",
"clientSecret": "your-client-secret",
"tenantId": "your-tenant-id"
}
}
}
}La siguiente es una tabla de variables de configuración de entorno disponibles:
Variable | Descripción | Por defecto |
| Nivel de registro |
|
| URL del servidor FHIR de Azure | Requerido |
| ID de cliente de OAuth2 | Requerido |
| Secreto de cliente OAuth2 | Requerido |
| Identificador de inquilino de Azure AD | Requerido |
2 - Reinicie Claude Desktop.
Herramientas disponibles 🔧
Operaciones de recursos de FHIR
search_fhir: búsqueda de recursos FHIR basándose en un diccionario de parámetros de búsqueda
Acceso a recursos
El servidor proporciona acceso a todos los recursos FHIR estándar a través del protocolo de recursos MCP:
fhir://Patient/- Acceso a todos los recursos para pacientesfhir://Patient/{id}- Acceder a un recurso específico del Pacientefhir://Observation/- Acceda a todos los recursos de Observaciónfhir://Observation/{id}- Acceder a un recurso de observación específicofhir://Medication/- Acceda a todos los recursos sobre medicamentosfhir://Medication/{id}- Acceda a un recurso de medicación específicoY muchos más...
Related MCP server: Smart EHR MCP Server
Desarrollo 💻
Configuración de desarrollo local
1 - Clonar el repositorio:
git clone https://github.com/erikhoward/azure-fhir-mcp-server.git
cd azure-fhir-mcp-server2 - Crear y activar entorno virtual:
Linux/macOS:
python -m venv .venv
source .venv/bin/activateVentanas:
python -m venv .venv
.venv\Scripts\activate3 - Instalar dependencias:
pip install -e ".[dev]"4 - Copiar y configurar variables de entorno:
cp .env.example .envEdite .env con su configuración:
fhirUrl=https://your-fhir-server.azurehealthcareapis.com/fhir
clientId=your-client-id
clientSecret=your-client-secret
tenantId=your-tenant-id5 - Configuración del escritorio de Claude
Abra claude_desktop_config.json y agregue la siguiente configuración.
En MacOs, el archivo se encuentra aquí: ~/Library/Application Support/Claude Desktop/claude_desktop_config.json .
En Windows, el archivo se encuentra aquí: %APPDATA%\Claude Desktop\claude_desktop_config.json .
{
"mcpServers": {
"fhir": {
"command": "python",
"args": [
"-m",
"fhir_mcp_server.server"
],
"cwd": "/path/to/azure-fhir-mcp-server/repo",
"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 - Reinicie Claude Desktop.
Contribuciones 🤝
¡Agradecemos sus contribuciones! No dude en enviar una solicitud de incorporación de cambios.
Bifurcar el repositorio
Crea tu rama de funciones (
git checkout -b feature/AmazingFeature)Confirme sus cambios (
git commit -m '✨ Add some AmazingFeature')Empujar a la rama (
git push origin feature/AmazingFeature)Abrir una solicitud de extracción
Licencia ⚖️
Con licencia MIT - consulte el archivo LICENSE.md .
Este no es un producto oficial de Microsoft o Azure.
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
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| resource_type | Yes | ||
| search_params | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v1.0.0- Changed
search_fhir3 fields changed- removed
Input schema / properties / resource_type / titleRemoved value: -"Resource Type" - removed
Input schema / properties / search_params / titleRemoved value: -"Search Params" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "result": { + "items": { + "additionalProperties": true, + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "result" + ], + "type": "object", + "x-fastmcp-wrap-result": true +}
1 tool update
- First observed
search_fhir
TDQS
A4.1/5.0
Scored across 1 tool
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
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.
- StytchOAuthdev.stytch.mcp
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 gradedqualityFmaintenanceA 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.87MIT
- FlicenseNot gradedqualityDmaintenanceA 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-
- AlicenseNot gradedqualityDmaintenanceA server that implements the Model Context Protocol (MCP) with StreamableHTTP transport, enabling standardized interaction with model services through a RESTful API interface.730 npm2MIT