Loading ToolBench
A Model Context Protocol (MCP) server that provides seamless, standardized access to Fast Healthcare Interoperability Resources (FHIR) data from any compatible FHIR server. Designed for easy integration with AI tools, developer workflows, and healthcare applications, it enables natural language and programmatic search, retrieval, and analysis of clinical data.
FHIR MCP Server presents 8 well-named tools with explicit JSON Schema input definitions and clear descriptions. Naming follows verb_noun conventions (get_*, search_*, create_*, update_, delete_*, perform_*). All tools have descriptions of 100+ characters. Input parameters are typed with descriptions. However, there are critical gaps in error handling guidance, no explicit output schema documentation, missing parameter constraints (enums, ranges), and no evidence of security patterns like permission gates or audit logging. The server uses fastmcp with Streamable HTTP transport (current spec). Tool definitions are directly visible in server.py, so no inference penalty applies.
Creates a new FHIR resource. The resource must conform to the FHIR specification for the given resource type.
Deletes a FHIR resource by its resource type and ID. This operation is irreversible.
Retrieves metadata about a specified FHIR resource type, including its supported search parameters and custom operations. This tool MUST always be invoked before performing any resource operation (such as search, read, create, update, or delete) to discover the valid searchParams and operations permitted for that resource type. Do not use this tool to fetch actual resources.
Retrieves the authenticated user's profile information from the FHIR server based on the fhirUser claim in the ID token. This tool extracts the user's resource type and ID from the authentication token and retrieves their profile data.
Performs a custom FHIR operation on a resource or system level. Operations are defined by the FHIR server's CapabilityStatement.
Retrieves a specific FHIR resource by its resource type and ID.
No output schemas documented for any tool. LLM cannot know what fields to expect from search_resources, read_resource, create_resource results, forcing trial-and-error extraction or context waste.
Resource type parameters (in get_capabilities, search_resources, read_resource, create_resource, update_resource, delete_resource, perform_operation) accept free-form strings with no enum constraint. LLM can hallucinate invalid FHIR types (e.g., 'Patien', 'Patient123'). Should declare enum of valid FHIR resource types or at least document the constraint in parameter description.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 71 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Searches for FHIR resources using search criteria. Supports flexible search parameters including filtering, sorting, and resource inclusion. Returns a Bundle of resources matching the search criteria.
Updates an existing FHIR resource by replacing it with the provided resource. The resource ID must match the existing resource.
Error handling completely absent. No guidance on recovery strategies. E.g., search_resources yields no description of what happens if search_criteria is malformed, and no suggestion to call get_capabilities first. create_resource fails on validation errors with no hint on required fields. delete_resource may fail on permission denial with no guidance.
Security patterns missing. No evidence of permission gates, audit logging, or scope declarations. Destructive operations (delete_resource, update_resource) lack confirmation or dry-run patterns. No documented access control.
Generic 'resource' parameter in create_resource and update_resource accepts any JSON object with no schema validation. Should constrain input to valid FHIR JSON schema for the specified resource_type, or at least document required fields and structure in parameter description.
perform_operation's resource_id parameter is conditionally required (omitted for system-level ops) but description does not explicitly state this dependency. LLM may pass or omit based on assumption rather than clarity.
search_resources returns no pagination guidance. description states it 'Returns a Bundle' but does not document result limits, offset/page parameters, or total count fields. LLM cannot plan multi-page queries or know when results are truncated.
get_user_profile depends on OAuth token with fhirUser claim, but no error guidance if token is missing, invalid, or token lacks fhirUser claim. Description does not explain fallback or recovery.