Skip to main content
Glama
mrosata

MCP FHIR Server

by mrosata
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

MCP FHIR Server

A generic MCP server providing read/write access to any FHIR-compliant API with built-in validation.

This server works with any FHIR server, not just Zus Health. For Zus-specific features (like getting UPIDs), see the Zus Extensions section below.

Features

Core FHIR Features

  • FHIR resource validation using consolidated FHIR schemas

  • Create and update resources (POST/PUT)

  • Read resources by type and ID

  • Search resources with query parameters

  • Granular permissions via environment configuration

  • Bearer token authentication

  • Custom HTTP headers for multi-tenant or vendor-specific requirements

  • Detailed error messages for debugging and LLM-based correction

Zus Health Extensions (Optional)

  • Zus UPID lookup - Get Universal Patient IDs from Zus FHIR servers

  • Intelligent name matching - Find best patient match when multiple results exist

  • Builder ID support - Multi-tenant access via Zus-Account header

Related MCP server: FHIR MCP Server

Installation

Prerequisites

  • Python 3.13+

  • uv (recommended) or pip

Setup

# Clone the repository
git clone <repository-url>
cd mcp-fhir

# Install dependencies (production only)
uv sync

# For development (includes test tools, linter, etc.)
uv sync --extra dev

# Or with pip
pip install -e .

Note: The make commands will automatically install development dependencies when needed, so you can also just run make test directly after cloning.

Configuration

Environment File

The server can load environment variables from a file using the --env-file command line flag:

# Load environment variables from a specific file
uv run fastmcp run server.py --env-file /path/to/your/.env

# Or for development
uv run fastmcp dev server.py --env-file /path/to/your/.env

If no --env-file flag is provided, the server will use system environment variables only.

Create a .env file:

cp .env.example .env

Environment Variables

Variable

Default

Description

FHIR_BASE_URL

http://localhost:8080/fhir

FHIR server base URL

FHIR_ALLOW_READ

true

Enable GET operations

FHIR_ALLOW_WRITE

true

Enable POST/PUT/PATCH/DELETE operations

FHIR_AUTH_TOKEN

(empty)

Bearer token for authentication

FHIR_ALLOWED_METHODS

(empty)

Comma-separated HTTP methods (overrides READ/WRITE)

Permission Model

Option 1: Simple Read/Write (default)

FHIR_ALLOW_READ=true   # Enables GET
FHIR_ALLOW_WRITE=true  # Enables POST, PUT, PATCH, DELETE

Option 2: Granular Methods (takes precedence)

FHIR_ALLOWED_METHODS=GET,POST  # Only read and create

Examples:

  • GET - Read-only

  • POST,PUT - Create and update only (no reads)

  • GET,POST - Read and create (no updates)

  • GET,POST,PUT - Full access

Running

Development

# Using make (recommended)
make dev

# Or directly
uv run fastmcp dev server.py

Production

# Using make (recommended)
make run

# Or directly
uv run fastmcp run server.py

Claude Desktop Integration

Edit your Claude Desktop config file:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json Windows: %APPDATA%\Claude\claude_desktop_config.json Linux: ~/.config/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "fhir": {
      "command": "uv",
      "args": [
        "--directory",
        "/absolute/path/to/mcp-fhir",
        "run",
        "fastmcp",
        "run",
        "server.py",
        "--env-file",
        "/absolute/path/to/mcp-fhir/.env"
      ]
    }
  }
}

Alternative: You can also set environment variables directly in the config:

{
  "mcpServers": {
    "fhir": {
      "command": "uv",
      "args": [
        "--directory",
        "/absolute/path/to/mcp-fhir",
        "run",
        "fastmcp",
        "run",
        "server.py"
      ],
      "env": {
        "FHIR_BASE_URL": "https://your-fhir-server.com/fhir",
        "FHIR_ALLOW_READ": "true",
        "FHIR_ALLOW_WRITE": "true",
        "FHIR_AUTH_TOKEN": "your-token-here"
      }
    }
  }
}

Restart Claude Desktop after editing.

Tools

Core FHIR Tools

These tools work with any FHIR-compliant server:

write_fhir_resource

Create or update a FHIR resource.

Parameters:

  • resource (object): FHIR resource JSON

  • custom_headers (object, optional): Custom HTTP headers for the request

    • For Zus servers: {"Zus-Account": "builder-id"} for multi-tenant access

    • For other servers: Any vendor-specific headers your FHIR server requires

Behavior:

  1. Validates resource against FHIR schema

  2. Uses POST if no id field (create), PUT if id exists (update)

  3. Returns validation errors for correction if invalid

  4. Returns server response on success (if FHIR_ALLOW_READ=true)

Example:

{
  "resourceType": "Patient",
  "name": [{"family": "Smith", "given": ["John"]}],
  "gender": "male"
}

Note: If validation schema fails to load, validation is skipped (server-side validation still applies).

read_fhir_resource

Read a resource by type and ID.

Parameters:

  • resource_type (string): e.g., "Patient", "Observation"

  • resource_id (string): Resource ID

  • custom_headers (object, optional): Custom HTTP headers for the request

Returns: JSON resource or error message

search_fhir_resources

Search resources with query parameters.

Parameters:

  • resource_type (string): Resource type to search

  • search_params (object, optional): Query parameters

    • Example: {"name": "Smith", "gender": "female"}

  • custom_headers (object, optional): Custom HTTP headers for the request

Returns: FHIR Bundle with matching resources

get_fhir_config

View current configuration.

Returns: Configuration summary including base URL, permissions, and allowed methods.

Zus Health Extensions

These tools are specific to Zus Health FHIR servers and will not work with other FHIR implementations.

get_patient_zus_upid

Get the Zus UPID (Universal Patient ID) for a Patient resource from Zus FHIR server.

Parameters:

  • first_name (string): Patient's first name

  • last_name (string): Patient's last name

  • builder_id (string, optional): Zus builder ID to filter the search

Behavior:

  1. Searches for Patient resources using name parameter (concatenated first and last name)

  2. Optionally filters by Zus builderID parameter if provided

  3. Extracts Zus UPID from Patient's identifiers with system https://zusapi.com/fhir/identifier/universal-id

  4. When multiple patients are found, uses intelligent name matching to find the best match

  5. Returns the Zus UPID value or appropriate error message

Example usage:

get_patient_zus_upid("John", "Smith")
get_patient_zus_upid("John", "Smith", "builder-123")

Response formats:

  • Single patient found: Zus UPID: zus-upid-12345

  • Multiple patients with good name match: Zus UPID: zus-upid-12345 (Best match: John Smith) + other matches if any

  • Multiple patients with no clear match: Lists all found patients with their Zus UPIDs

  • No patients found: Error: No Patient found with name 'John Smith'

  • No Zus UPID: Error: No Zus UPID found for Patient(s) with name 'John Smith'

Name Matching Logic:

  • Exact name matches get highest priority (score 1.0)

  • Partial matches (e.g., "John" matching "Johnny") get medium priority (score 0.7 for given name)

  • Family name matches are weighted more heavily than given name matches

  • Partial matches are permissive: shorter names can match longer ones (e.g., "John" matches "Johnny")

  • If the best match has a score ≥ 0.5, it's returned as the primary result

  • Other decent matches (score ≥ 0.3) are listed as alternatives

Technical Details

HTTP Headers

All requests include:

Content-Type: application/fhir+json
Accept: application/fhir+json
Authorization: Bearer {token}  (if FHIR_AUTH_TOKEN set)

Custom Headers: You can provide additional custom headers via the custom_headers parameter in any tool. This is useful for:

  • Multi-tenant systems (e.g., Zus's Zus-Account header)

  • Vendor-specific authentication or routing headers

  • Any other FHIR server-specific requirements

Example (Zus):

{"Zus-Account": "builder-123"}

Timeouts

All requests timeout after 30 seconds.

Error Handling

The server returns detailed errors for:

Code

Description

400

Invalid request/validation error

401

Authentication failed

403

Insufficient permissions

404

Resource or endpoint not found

422

Business rule violation

Timeout

Connection timeout (30s)

Errors include full server response when available for debugging.

Validation

Resources are validated using the fhir-validator library before submission:

  • Checks FHIR spec compliance

  • Validates required fields and data types

  • Verifies resource structure

If validation schema loading fails at startup, a warning is logged and validation is bypassed (server-side validation still occurs).

Development

Testing

# Run tests (automatically installs dev dependencies if needed)
make test

# With coverage
make test-cov

# Watch mode
make test-watch

Or directly:

uv run pytest
uv run pytest --cov=. --cov-report=term-missing

Note: All make commands automatically install development dependencies when needed, so new developers can simply run make test after cloning the repository.

Code Quality

make lint    # Run linter (automatically installs dev dependencies)
make format  # Format code (automatically installs dev dependencies)
make check   # Lint + format check (automatically installs dev dependencies)

Project Structure

mcp-fhir/
├── server.py          # Generic MCP FHIR server implementation
├── zus_extensions.py  # Zus Health-specific tools (optional)
├── fhir_validator.py  # FHIR validation logic
├── pyproject.toml     # Dependencies
├── .env.example       # Example configuration
└── tests/             # Test suite

Architecture

The server is designed with modularity in mind:

  • server.py: Contains generic FHIR operations that work with any FHIR server

  • zus_extensions.py: Contains Zus Health-specific functionality (UPID lookup, etc.)

  • Generic tools accept custom_headers for flexibility with different FHIR vendors

  • Zus tools use builder_id for Zus-specific multi-tenancy

This separation allows you to:

  1. Use the generic tools with any FHIR server

  2. Add your own vendor-specific extensions by following the zus_extensions.py pattern

  3. Keep the core FHIR functionality clean and standards-compliant

License

[Add license information]

Contributing

[Add contribution guidelines]

Available Tools

5 tools
get_fhir_configB

Get the current FHIR server configuration.

Returns: Current configuration settings

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns configuration settings, but lacks details on permissions needed, rate limits, error handling, or whether it's a read-only operation. For a tool with no annotation coverage, this is a significant gap in transparency.

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 brief and front-loaded, stating the purpose in the first sentence and the return in the second. There's no wasted text, but the structure could be slightly improved by integrating the return statement more seamlessly or adding minimal context.

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

Completeness3/5

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

Given the tool has 0 parameters, 100% schema coverage, and an output schema exists, the description is adequate but minimal. It explains what the tool does and what it returns, but lacks context on usage, behavioral traits, or how it fits with siblings, making it incomplete for optimal agent understanding.

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

Parameters4/5

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

The input schema has 0 parameters with 100% coverage, so the schema fully documents the lack of inputs. The description doesn't need to add parameter details, but it implicitly confirms no parameters are required by not mentioning any. This meets the baseline for zero-parameter tools, though it could briefly note the absence of inputs for clarity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/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 with a specific verb ('Get') and resource ('current FHIR server configuration'), making it immediately understandable. However, it doesn't differentiate this tool from its siblings (like 'read_fhir_resource' or 'search_fhir_resources'), which might also retrieve configuration-related data, so it doesn't reach the highest score.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any context, prerequisites, or exclusions, such as whether this is for administrative settings versus patient data access, leaving the agent to infer usage from tool names alone.

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

get_patient_zus_upidA

Get the Zus UPID (Universal Patient ID) for a Patient resource from Zus FHIR server.

This is a Zus-specific tool for working with Zus Health's FHIR API. Searches for a Patient by first and last name, optionally filtered by builderID, then extracts the Zus UPID from the Patient's identifiers.

Args: first_name: Patient's first name last_name: Patient's last name builder_id: Optional Zus builder ID (string) to filter the search

Returns: The Zus UPID value or an error message if not found

ParametersJSON Schema
NameRequiredDescriptionDefault
first_nameYes
last_nameYes
builder_idNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden. It discloses that the tool searches for a Patient and extracts the UPID, and mentions it returns 'an error message if not found.' However, it lacks details on authentication needs, rate limits, or what specific error messages might be returned, leaving behavioral gaps.

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

Conciseness5/5

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

The description is well-structured and front-loaded with the core purpose, followed by context, parameters, and returns. Every sentence adds value: the first states the purpose, the second provides context, the third explains the search logic, and the last two detail parameters and returns, with no wasted words.

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

Completeness4/5

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

Given the tool's moderate complexity (3 parameters, no annotations, but with an output schema), the description is fairly complete. It covers purpose, context, parameters, and return behavior. However, it could improve by addressing authentication or error specifics, though the output schema may handle return values.

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

Parameters4/5

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

Schema description coverage is 0%, so the description must compensate. It adds meaning by explaining each parameter's purpose: 'first_name: Patient's first name', 'last_name: Patient's last name', and 'builder_id: Optional Zus builder ID (string) to filter the search.' This clarifies semantics beyond the bare schema, though it doesn't detail format constraints or examples.

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: 'Get the Zus UPID (Universal Patient ID) for a Patient resource from Zus FHIR server.' It specifies the exact action (get), resource (Zus UPID), and distinguishes it from siblings by focusing on extracting UPIDs rather than general FHIR operations like read_fhir_resource or search_fhir_resources.

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

Usage Guidelines4/5

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

The description provides clear context for when to use this tool: 'This is a Zus-specific tool for working with Zus Health's FHIR API' and 'Searches for a Patient by first and last name.' It implies usage for Zus-specific UPID extraction but doesn't explicitly state when not to use it or name alternatives among siblings.

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

read_fhir_resourceA

Read a FHIR resource by type and ID from the FHIR server.

Args: resource_type: The FHIR resource type (e.g., "Patient", "Observation") resource_id: The ID of the resource to read custom_headers: Optional dictionary of custom HTTP headers to include in the request. For Zus servers, use {"Zus-Account": "builder-id"} for multi-tenant access.

Returns: The FHIR resource as JSON or an error message

ParametersJSON Schema
NameRequiredDescriptionDefault
resource_typeYes
resource_idYes
custom_headersNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.9/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden. It discloses the tool reads resources (non-destructive) and mentions error handling ('or an error message'), but lacks details on authentication needs, rate limits, or server-specific behaviors beyond the Zus headers example. It adds some context but is incomplete for a mutation-free read operation.

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 a clear purpose statement, parameter explanations, and return information. It uses bullet-like formatting under 'Args:' and 'Returns:' for readability. Some minor verbosity exists (e.g., repeating 'FHIR' could be trimmed), but overall it's efficient and front-loaded.

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

Completeness4/5

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

Given the tool has an output schema (returns JSON), the description needn't detail return values. It covers the core purpose, parameters, and a key usage note (Zus headers). For a read operation with no annotations, it provides adequate context, though it could benefit from more behavioral details like error types or access requirements.

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

Parameters4/5

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

Schema description coverage is 0%, so the description must compensate. It explains all three parameters: 'resource_type' with examples ('Patient', 'Observation'), 'resource_id' as the target ID, and 'custom_headers' with a specific use case for Zus servers. This adds meaningful semantics beyond the bare schema, though it doesn't cover all possible header formats or constraints.

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 specific action ('Read a FHIR resource') with the target ('by type and ID from the FHIR server'), distinguishing it from sibling tools like 'search_fhir_resources' (which searches) and 'write_fhir_resource' (which writes). The verb+resource combination is precise and unambiguous.

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 for retrieving specific resources by type and ID, but does not explicitly state when to use this versus alternatives like 'search_fhir_resources' for broader queries or 'get_patient_zus_upid' for patient-specific IDs. No exclusions or prerequisites are mentioned, leaving usage context somewhat open-ended.

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

search_fhir_resourcesB

Search for FHIR resources using query parameters.

Args: resource_type: The FHIR resource type to search (e.g., "Patient", "Observation") search_params: Optional dictionary of search parameters (e.g., {"name": "Smith", "gender": "female"}) custom_headers: Optional dictionary of custom HTTP headers to include in the request. For Zus servers, use {"Zus-Account": "builder-id"} for multi-tenant access.

Returns: A FHIR Bundle containing matching resources or an error message

ParametersJSON Schema
NameRequiredDescriptionDefault
resource_typeYes
search_paramsNo
custom_headersNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.2/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the return type ('A FHIR Bundle containing matching resources or an error message') and a specific use case for 'custom_headers' in Zus servers, but does not cover critical aspects like authentication requirements, rate limits, error handling details, or whether this is a read-only operation. This leaves significant gaps for an agent to understand behavioral traits.

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 appropriately sized and front-loaded, starting with the core purpose. It uses a structured format with 'Args:' and 'Returns:' sections, making it easy to parse. While efficient, the 'custom_headers' explanation is slightly verbose but adds necessary context, so it earns its place without significant waste.

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

Completeness3/5

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

Given the complexity (3 parameters, 0% schema coverage, no annotations, but with an output schema), the description is partially complete. It covers parameter basics and return values, but lacks details on authentication, error scenarios, and behavioral constraints. The output schema likely handles return structure, reducing the need for description there, but overall gaps remain for safe and effective tool invocation.

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

Parameters3/5

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

Schema description coverage is 0%, so the description must compensate. It adds meaning by explaining each parameter: 'resource_type' with examples ('Patient', 'Observation'), 'search_params' as an optional dictionary with examples, and 'custom_headers' with a specific use case. However, it does not fully detail all possible values, constraints, or formats beyond basic examples, leaving some ambiguity for the agent.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/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 for FHIR resources using query parameters.' It specifies the verb ('search') and resource ('FHIR resources'), making it understandable. However, it does not explicitly differentiate from sibling tools like 'read_fhir_resource' or 'write_fhir_resource', which could involve similar resources but different operations.

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 through examples (e.g., searching for 'Patient' or 'Observation'), but does not explicitly state when to use this tool versus alternatives like 'read_fhir_resource' for specific resource retrieval. It provides context for 'custom_headers' in multi-tenant scenarios, but lacks clear guidance on exclusions or prerequisites for general use.

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

write_fhir_resourceA

Write a FHIR resource to the FHIR server.

This tool:

  1. Validates the FHIR resource using fhir-validator

  2. Determines the appropriate endpoint based on resource type

  3. POSTs or PUTs the resource to the FHIR server

  4. Returns validation errors or server errors for correction

Args: resource: A FHIR resource as a JSON object (dict) custom_headers: Optional dictionary of custom HTTP headers to include in the request. For Zus servers, use {"Zus-Account": "builder-id"} for multi-tenant access.

Returns: A status message indicating success or detailed error information

ParametersJSON Schema
NameRequiredDescriptionDefault
resourceYes
custom_headersNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/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 and does well by detailing steps like validation, endpoint determination, and error handling. It discloses behavioral traits such as validation using fhir-validator and handling of errors, which are beyond basic functionality. However, it misses some details like rate limits or authentication requirements, preventing a perfect score.

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 bullet points and sections for Args and Returns, making it easy to scan. It's appropriately sized with no redundant information, but the bullet points could be more concise, and some sentences are slightly verbose (e.g., 'Returns validation errors or server errors for correction').

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

Completeness4/5

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

Given the tool's complexity (write operation with validation and custom headers), no annotations, and an output schema present, the description is mostly complete. It covers purpose, steps, parameters, and returns, but could benefit from more details on error types or success conditions, especially since the output schema exists but isn't described in the text.

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

Parameters4/5

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

Schema description coverage is 0%, so the description must compensate. It adds meaning by explaining that 'resource' is a FHIR resource as a JSON object and 'custom_headers' is optional with a specific example for Zus servers. This provides practical context beyond the schema's basic types, though it could elaborate more on resource structure or header constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool writes a FHIR resource to a FHIR server, specifying the action (write) and resource (FHIR resource). It distinguishes from sibling tools like read_fhir_resource and search_fhir_resources by focusing on creation/update. However, it doesn't explicitly differentiate from potential siblings like update_fhir_resource or create_fhir_resource if they existed, keeping it at 4 instead of 5.

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 for writing FHIR resources, with a note about Zus servers for multi-tenant access, suggesting context-specific application. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., no mention of when to use POST vs. PUT or how it differs from sibling tools like read_fhir_resource). The guidance is present but not comprehensive.

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

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0
Disambiguation4/5

Most tools have distinct purposes, but get_fhir_config overlaps slightly with general FHIR operations as it's a configuration tool rather than a core FHIR resource operation. The other tools (read, search, write, get_patient_zus_upid) are clearly differentiated by their specific actions and targets.

Naming Consistency4/5

Tools follow a consistent verb_noun pattern (get_fhir_config, read_fhir_resource, search_fhir_resources, write_fhir_resource), with get_patient_zus_upid being a minor deviation due to its Zus-specific naming. Overall, the naming is predictable and readable.

Tool Count4/5

Five tools is reasonable for a FHIR server, covering core operations like read, search, and write, plus configuration and a Zus-specific utility. It's slightly thin for full FHIR coverage but well-scoped for basic interactions.

Completeness3/5

The toolset covers read, search, and write operations, but lacks update and delete for full CRUD lifecycle management. The inclusion of get_fhir_config and a Zus-specific tool adds utility, but the absence of update/delete operations is a notable gap for FHIR resource management.

Maintenance

ActivityInactive
ResponsivenessSyncing

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

Related MCP Servers

  • FHIR MCP Server

    the-momentum
    A
    license
    A
    quality
    D
    maintenance
    Enables LLM-based agents to interact with FHIR healthcare data through natural language prompts, providing full CRUD operations on FHIR resources, document processing, and semantic search capabilities.
    13
    98
    MIT

  • FHIR MCP Server

    sumithasb
    -
    license
    Not graded
    quality
    Not graded
    maintenance
    Enables seamless integration with FHIR APIs for healthcare applications, allowing users to search, retrieve, create, update, and analyze clinical information through natural language interactions. Supports SMART-on-FHIR authentication and works with various healthcare systems like EPIC and HAPI FHIR servers.

  • FhirMCP

    xSoVx
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables LLMs to securely interact with FHIR healthcare servers and HL7 terminology services. Provides comprehensive healthcare data operations with built-in PHI protection, audit logging, and SMART on FHIR authentication.
    MIT

  • FHIR MCP Server

    wso2
    A
    license
    A
    quality
    C
    maintenance
    Provides seamless integration with FHIR APIs, enabling AI/LLM tools to search, retrieve, and analyze clinical healthcare data with support for SMART-on-FHIR authentication and multiple transport protocols.
    7
    134
    Apache 2.0

Appeared in Searches

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/mrosata/mcp-fhir'

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