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
Azure AHDS FHIR MCP 服务器🚀
Azure 健康数据服务 FHIR（快速医疗保健互操作性资源）的模型上下文协议 (MCP) 服务器实现。此服务提供与 Azure FHIR 服务器交互的标准化接口，支持通过 MCP 工具进行医疗保健数据操作。
设置🛠️
安装📦
需要 Python 3.13 或更高版本。
使用pip安装包：
pip install azure-fhir-mcp-serverMCP 配置⚙️
Claude桌面配置
1 - 编辑Claude桌面配置：
打开claude_desktop_config.json并添加以下配置。
在 MacOs 上，该文件位于此处： ~/Library/Application Support/Claude Desktop/claude_desktop_config.json 。
在 Windows 上，该文件位于此处： %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"
}
}
}
}以下是可用的环境配置变量表：
多变的 | 描述 | 默认 |
| 日志级别 |
|
| Azure FHIR 服务器 URL | 必需的 |
| OAuth2 客户端 ID | 必需的 |
| OAuth2 客户端密钥 | 必需的 |
| Azure AD 租户 ID | 必需的 |
2 - 重新启动 Claude Desktop。
可用工具🔧
FHIR 资源操作
search_fhir- 根据搜索参数字典搜索 FHIR 资源
资源访问
服务器通过 MCP 资源协议提供对所有标准 FHIR 资源的访问：
fhir://Patient/- 访问所有患者资源fhir://Patient/{id}- 访问特定的患者资源fhir://Observation/- 访问所有观察资源fhir://Observation/{id}- 访问特定的观察资源fhir://Medication/- 访问所有药物资源fhir://Medication/{id}- 访问特定的药物资源还有更多...
Related MCP server: Smart EHR MCP Server
发展💻
本地开发设置
1-克隆存储库：
git clone https://github.com/erikhoward/azure-fhir-mcp-server.git
cd azure-fhir-mcp-server2-创建并激活虚拟环境：
Linux/macOS：
python -m venv .venv
source .venv/bin/activate视窗：
python -m venv .venv
.venv\Scripts\activate3 - 安装依赖项：
pip install -e ".[dev]"4-复制并配置环境变量：
cp .env.example .env使用您的设置编辑 .env：
fhirUrl=https://your-fhir-server.azurehealthcareapis.com/fhir
clientId=your-client-id
clientSecret=your-client-secret
tenantId=your-tenant-id5 - Claude桌面配置
打开claude_desktop_config.json并添加以下配置。
在 MacOs 上，该文件位于此处： ~/Library/Application Support/Claude Desktop/claude_desktop_config.json 。
在 Windows 上，该文件位于此处： %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 - 重新启动 Claude Desktop。
贡献🤝
欢迎贡献代码！欢迎提交 Pull 请求。
分叉存储库
创建你的功能分支（
git checkout -b feature/AmazingFeature）提交你的更改（
git commit -m '✨ Add some AmazingFeature'）推送到分支（
git push origin feature/AmazingFeature）打开拉取请求
许可证⚖️
根据 MIT 许可 - 请参阅LICENSE.md文件。
这不是 Microsoft 或 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.
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
- 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