Loading ToolBench
Model Context Protocol (MCP) server for OpenEHR integration with EHRbase
This server has moderately good descriptions but significant schema and error-handling gaps. Tool names follow verb_noun convention well (list, get, create). Descriptions are generally detailed (100-250 chars), exceeding the minimum. However, critical issues emerge: (1) The input schema for openehr_ehr_create uses a union type 'string|object' without proper JSON Schema definition, which LLMs cannot parse reliably. (2) Return types are undocumented, tools return JSON strings but the schema of those strings is never specified, forcing LLMs to guess at response structure. (3) Error handling is minimal, tools return generic error messages like 'Error listing templates: {str(e)}' with no recovery guidance. (4) Parameters lack explicit constraints (enums, ranges, patterns). (5) No tool annotations (readOnlyHint, destructiveHint) despite clear safety distinctions (5 READ_ONLY, 1 WRITE). Per-tool analysis: openehr_template_list and openehr_template_get have strong descriptions but no output schema; openehr_ehr_create has problematic parameter typing. Average per-tool score across 6 tools: 52.
Create a new EHR in the system. Creates a new Electronic Health Record (EHR) in the EHRbase server. An EHR is a container for all health data about a single patient. The optional ehr_status parameter can be used to provide additional metadata about the EHR.
Retrieve an EHR by its ID. Fetches an existing Electronic Health Record (EHR) from the EHRbase server using its unique identifier. The EHR contains metadata about the patient record but not the actual clinical data (which is stored in compositions).
List all available EHRs in the system. Retrieves a list of all Electronic Health Records (EHRs) available in the EHRbase server. This provides an overview of all patient records in the system without retrieving the detailed clinical data.
Generate an example openEHR composition based on a specific template. Creates a sample openEHR composition that adheres to the structure defined in the specified template. This includes mock data for all required fields and demonstrates the proper format for creating valid compositions. The current implementation uses the flat JSON representation (application/openehr.wt.flat.schema+json)
Retrieve a specific openEHR template by its unique identifier. Fetches the complete definition of an openEHR template, including all archetypes, constraints, and data point definitions. The template is returned in openEHR Web Template format, which can be used to understand the structure required for creating valid compositions based on this template.
Return types undocumented. All 6 tools return JSON strings, but the schema of the returned JSON (fields, types, structure) is never documented. LLMs cannot parse or plan downstream operations without knowing response structure.
Parameter schema malformed: openehr_ehr_create accepts 'ehr_status' as 'string|object' (union type) without proper JSON Schema definition. LLMs cannot reliably parse union types in tool schemas. Should be either a string with format/pattern constraints, or a separate object-type parameter with explicit properties.
Error handling lacks recovery guidance. All tools return generic errors like 'Error listing templates: {exception}' with no actionable next step. Per pattern:recovery-guide, errors must guide the LLM on retry, user action, or alternative tools.
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 | 27 | - | v1 |
List all available openEHR templates from the EHRbase server. Returns a JSON array of available openEHR templates with their metadata. These templates define the structure for clinical data compositions within the openEHR standard.
No tool annotations for safety. Five tools are marked READ_ONLY and one WRITE in the risk field, but this metadata is not exposed as tool annotations (readOnlyHint, destructiveHint, idempotentHint) in the MCP schema. LLMs cannot infer safety constraints.
Parameters lack explicit constraints. For example, 'template_id' in openehr_template_get has no enum, pattern, or format declared. 'ehr_status' in openehr_ehr_create is not described with structure or format. Free-form string parameters invite hallucinated values.
Tool descriptions lack dependency hints. For example, openehr_template_example_composition depends on knowing a valid template_id, but does not suggest 'Call openehr_template_list first to discover available templates.' This forces the LLM to infer tool sequences.
Parameters undocumented in schema. Input schemas are present but minimal (e.g., openehr_template_list has empty {}). None of the tools show parameter descriptions in the visible schema definition.