Skip to main content
Glama
deenesjakoruzh
erikhoward

Azure AHDS FHIR MCP Server

by erikhoward
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Сервер Azure AHDS FHIR MCP 🚀

Реализация сервера Model Context Protocol (MCP) для Azure Health Data Services FHIR (Fast Healthcare Interoperability Resources). Эта служба предоставляет стандартизированный интерфейс для взаимодействия с серверами Azure FHIR, позволяя выполнять операции с данными здравоохранения с помощью инструментов MCP.

Лицензия Версия Python МКП

Настройка 🛠️

Установка 📦

Требуется Python 3.13 или выше.

Установите пакет с помощью pip :

pip install azure-fhir-mcp-server

Конфигурация MCP ⚙️

Конфигурация рабочего стола Клода

1 - Изменить конфигурацию рабочего стола Клода:

Откройте 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"
            }
        }
    }
}

Ниже приведена таблица доступных переменных конфигурации среды:

Переменная

Описание

По умолчанию

LOG_LEVEL

Уровень ведения журнала

INFO

fhirUrl

URL-адрес сервера Azure FHIR

Необходимый

clientId

Идентификатор клиента OAuth2

Необходимый

clientSecret

Секрет клиента OAuth2

Необходимый

tenantId

Идентификатор клиента Azure AD

Необходимый

2 — Перезапустите Claude Desktop.

Доступные инструменты 🔧

Операции с ресурсами FHIR

  • search_fhir — Поиск ресурсов FHIR на основе словаря параметров поиска

Доступ к ресурсам

Сервер обеспечивает доступ ко всем стандартным ресурсам FHIR через протокол ресурсов MCP:

  • fhir://Patient/ — Доступ ко всем ресурсам для пациентов

  • fhir://Patient/{id} — доступ к определенному ресурсу пациента

  • fhir://Observation/ - Доступ ко всем ресурсам Observation

  • fhir://Observation/{id} — доступ к определенному ресурсу Observation

  • 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-server

2 — Создайте и активируйте виртуальную среду:

Linux/macOS:

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

Окна:

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

3 - Установка зависимостей:

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-id

5 - Конфигурация рабочего стола Клода

Откройте 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.

Вклады 🤝

Вклады приветствуются! Пожалуйста, не стесняйтесь отправлять запрос на включение.

  1. Форк репозитория

  2. Создайте ветку функций ( git checkout -b feature/AmazingFeature )

  3. Зафиксируйте свои изменения ( git commit -m '✨ Add some AmazingFeature' )

  4. Отправка в ветку ( git push origin feature/AmazingFeature )

  5. Открыть запрос на извлечение

Лицензия ⚖️

Лицензия MIT — см. файл LICENSE.md .

Это не официальный продукт Microsoft или Azure.

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool updatev1.0.0
    • Changedsearch_fhir3 fields changed
      • removedInput schema / properties / resource_type / title
        Removed value: -"Resource Type"
      • removedInput schema / properties / search_params / title
        Removed value: -"Search Params"
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "result": {
+      "items": {
+        "additionalProperties": true,
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "result"
+  ],
+  "type": "object",
+  "x-fastmcp-wrap-result": true
+}
  2. 1 tool update
    • First observedsearch_fhir
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

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

Resources

Related MCP Connectors

  • Healthie MCP by usefulapiA
    io.usefulapi

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

    Biology & MedicineCalendar Management
    162
  • Remote MCPA
    com.remote-mcp.mcp

    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.

    Developer ToolsSearchAgent Orchestration
    13
  • Mercado PagoOAuth
    com.mercadopago.mcp

    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.

    FinanceE-commerce & RetailApp Automation
    2
  • StytchOAuth
    dev.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.

    SecurityAutonomous AgentsApp Automation
    2

Related MCP Servers

  • AgentCare

    Kartha-AI
    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

  • Smart EHR MCP Server

    jmandel
    A
    license
    Not graded
    quality
    F
    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.
    87
    MIT

  • HAPI-MCP

    ericmc21
    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
    -

  • OpenAPI MCP Server

    oneWalker
    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.
    730 npm
    2
    MIT

Appeared in Searches