Loading ToolBench
A Model Context Protocol server for querying and managing FHIR (Fast Healthcare Interoperability Resources) clinical data. Provides tools for patient search, encounter management, observations, conditions, medications, and other clinical resources with support for OAuth2 authentication.
Server has 16 tools with mostly complete schemas and descriptions. Strengths: clear verb-based naming (configure_, find_, get_, create_, update_), all tools have descriptions (10-500+ chars), all input parameters have type definitions and descriptions, structured FHIR domain-specific output. Weaknesses: (1) Tool #2 (aaa_clinical_system_rules) is a meta-instruction tool that should not be callable, it violates single-responsibility and confuses agent planning; (2) many tools lack documented output schemas, making it unclear what fields LLMs should expect for downstream composition; (3) parameter descriptions could be more explicit about constraints (enums for status values, date format specifications); (4) no explicit error recovery guidance in tool descriptions; (5) some tools accept mutually-exclusive-or-dependent parameters (patient_id OR encounter_id) but don't clearly state exclusivity rules in descriptions.
DO NOT CALL THIS TOOL. THIS IS A SYSTEM REFERENCE ONLY. Refer to the instructions below for handling IDs and workflows across all other tools. Contains critical system instructions for clinical data handling.
Update FHIR server configuration dynamically. Re-initializes the FHIR client with new connection details.
Create a new patient record in the FHIR server.
Search for Patients (환자) using various filters. You can search by Name/ID, OR by demographics (Gender, BirthDate), OR just list recently updated patients.
Get allergy and intolerance records for a patient.
Get care plans (treatment/management plans) for a patient.
aaa_clinical_system_rules is a meta-instruction tool that should not be callable. It violates single-responsibility principle and wastes agent reasoning deciding whether to invoke it. Move system rules to a prompt or server documentation.
Status and enumerated parameters across 14+ tools use free-form string descriptions instead of JSON Schema enum constraints. Examples: status in get_patient_encounters (should be enum: planned|arrived|in-progress|finished|cancelled), gender in find_patient and create_patient (should be enum: male|female|other|unknown), status fields throughout (active|inactive|completed, etc.). Free-form strings invite hallucinated values.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 63 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Get medical conditions/diagnoses for a patient. Returns active or historical conditions.
Get document references (medical records, reports) for a patient.
Get healthcare visits/Encounters (진료, 방문, 입원, 내원 이력). Requires patient_id or encounter_id
Get health goals/objectives for a patient.
Get immunization/vaccination records for a patient.
Get medication prescriptions/requests for a patient. Includes medication details, dosage, and status.
Get medication administration records/statements for a patient. Shows what medications were actually taken.
Get health observations (vital signs, lab results, etc.) for a patient or encounter. Use category to filter by type.
Get surgical or clinical procedures performed on a patient.
Update an existing patient record.
Output schemas are not documented for any of the 16 tools. LLMs cannot know what fields to expect in responses (patient_id, encounter_id, name, date, etc.), making it impossible to plan downstream tool chains or extract specific data. Example: does get_patient_encounters return encounter.id or encounterID? Does find_patient return patient.id or patient_id? Missing output schemas break composition.
Many tools accept mutually-exclusive parameters (patient_id OR encounter_id) but do not document this constraint. LLMs may pass both, or pass neither, causing ambiguous failures. Explicitly state: '(Provide either patient_id or encounter_id, not both)' in each affected tool's description.
Date/time parameters (dateFrom, dateTo, onsetDate, birth_date, last_updated) lack explicit format specifications in parameter descriptions. System rules mention YYYY-MM-DD but this is not evident in individual parameter docs. LLMs frequently misformat dates (e.g., MM-DD-YYYY or ISO8601 with timezone). Add '(format: YYYY-MM-DD)' to each date parameter.
No error recovery guidance in tool descriptions. None of the 16 tools explain what to do if a call fails (e.g., 'If patient_id not found, try find_patient()' or 'Status must be one of: active|inactive|completed'). Error handling is critical for agentic resilience.
create_patient and update_patient lack documented output schemas and error guidance. create_patient should explicitly state it returns the newly created patient_id. Both should clarify idempotency (is it safe to retry? What happens on name collision?). Irreversible operations need error recovery guidance.
Several parameters accept vague input formats: (1) vaccine_code in get_patient_immunizations says 'CVX or other' without clarifying what 'other' means; (2) code in get_patient_observations ('LOINC code or observation type', which is it?); (3) medication in get_patient_medication_requests/statements ('search term or FHIR ID', accepts both but no guidance on preference or fallback). These ambiguities force LLMs to guess or require multiple tries.