Loading ToolBench
FHIR R4 MCP Server for healthcare AI agents - provides clinical data access and terminology services via MCP and REST protocols
This FHIR MCP server demonstrates solid foundation with well-structured tool definitions, proper Pydantic schemas, and comprehensive parameter descriptions. However, it has significant gaps in output schema documentation, error handling guidance, and some parameter constraint issues. 15 of 18 tools have excellent naming and descriptions (8-12 character verbs, 100-250 char descriptions), but critical tools like create_resource, update_resource, and delete_resource lack output schema documentation and proper error recovery guidance. Parameter validation is strong (enums, constraints visible in Pydantic models) but not all constraints are reflected in descriptions. The server follows the chat-data-model principle well (accepting multiple identifier types for patients), but lacks actionable error messages and confirmation patterns for destructive operations.
Create a new FHIR resource
Delete a FHIR resource
Assembles a comprehensive clinical summary for a patient (demographics, conditions, meds, etc.).
Returns the FHIR server CapabilityStatement including supported resources.
Search for ICD-10-CM diagnosis codes by keyword or specific code.
Search for LOINC lab/clinical codes by keyword or code.
Search for RxNorm medication codes by drug name or RxCUI.
Search for SNOMED CT clinical terms by keyword or concept ID.
Destructive operations (create_resource, update_resource, delete_resource) lack output schema documentation and confirmation/dry-run patterns. delete_resource description is critically brief (45 chars) and provides no recovery guidance.
Composite/summary tools (get_patient_summary, get_server_capabilities) have no documented output schemas. LLMs cannot plan downstream tool calls or extract required fields without knowing response structure.
No error handling guidance across any tools. Descriptions do not explain what to do if a search returns zero results, if a resource is not found, or if the FHIR server is unreachable. Missing recovery-guide pattern.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 49 | - | v1 |
Read a specific FHIR resource by type and ID
Search for patient allergies and intolerances.
Search for patient care plans.
Search for clinical conditions (diagnoses) for a patient. Supports ICD-10/SNOMED codes.
Search for patient clinical encounters (visits).
Search for medication requests/prescriptions. Supports RxNorm codes.
Search for clinical observations (vitals, labs). Supports LOINC codes and date ranges.
Search for patient records in the FHIR server. Supports name, birthdate, gender, and identifier.
Search for clinical procedures performed on a patient.
Update an existing FHIR resource
Terminology lookup tools (lookup_icd10, lookup_snomed, lookup_loinc, lookup_rxnorm) have generic descriptions (70 chars) and single string 'query' parameter. No guidance on whether to pass a code (e.g., 'I10') vs. natural language (e.g., 'hypertension'). Parameter description should clarify both modes are supported.
Some search tools have result count limits documented (e.g., count 1-100 in search_patients) but descriptions do not state whether results are paginated or truncated. No next_cursor or total_count guidance. Missing pagination documentation.
read_resource and generic CRUD tools use 'resource_type' as a free-form string parameter with no enum constraint. LLMs can hallucinate invalid resource types (e.g., 'Patint' instead of 'Patient'). Should validate against FHIR R4 resource type enum.
create_resource and update_resource accept a 'payload' parameter of type object with minimal guidance. Description should explain the expected FHIR resource structure, which fields are required, and which are auto-filled by the server. Currently, LLMs must guess the payload format.