Loading ToolBench
MCP-compatible server for healthcare triage system that manages patient records, encounter history, and case management through a set of tools accessed via HTTP endpoints
This server presents a mixed picture. While all 5 tools have proper JSON Schema input definitions with typed parameters and descriptions, the overall quality is held back by: (1) incomplete parameter descriptions, many parameters lack guidance on valid ranges, formats, or constraints; (2) missing or underdocumented output schemas, no evidence of documented return types or structured response definitions; (3) vague tool descriptions that do not clearly indicate when to use each tool vs. alternatives, and lack clarity about side effects for write operations; (4) absence of error handling guidance, no indication of how tools fail or what recovery steps LLMs should take. Tools like `update_patient` and `create_case` (WRITE risk) have minimal documentation about their consequences. The server relies on the developer reading code rather than the tool definitions being self-documenting for an LLM. Average tool score is ~48, putting this in the 'poor' range typical of community servers.
Open a new triage case for a patient.
Retrieve a single patient using their ID.
Retrieve the encounter history for a patient.
Return a list of patients, optionally filtered by status.
Modify patient fields such as name, date of birth, or status.
Missing output schema documentation. No visible documentation of return types or field structure for any tool response. LLMs cannot plan multi-step sequences without knowing what fields are returned (e.g., does get_patient return patient_id, name, status? Does create_case return case_id for subsequent lookups?).
Underdocumented parameters. 'data' parameter in update_patient is defined as type 'object' with description 'Object containing fields to update (name, date_of_birth, status)', does not specify required fields, constraints, or validation rules. LLM must guess which fields are optional. 'urgency' in create_case has no enum constraint; description only suggests examples ('low', 'medium', 'high', 'urgent') without stating these are the only valid values.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 52 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Insufficient description of write operation consequences. update_patient and create_case modify state but their descriptions do not clarify: (1) Are these idempotent? (2) Can they be safely retried? (3) What happens on partial failure? (4) Are there any approval/confirmation steps? This is critical for agents making irreversible changes.
No error handling or recovery guidance. Tools have no documented error cases, valid error codes, or recovery paths. If create_case fails with 'patient not found', does LLM retry with a different patient_id, or call list_patients first? No guidance provided.
Ambiguous 'status' parameter in list_patients. Description says 'Optional status filter for patients' but does not enumerate valid status values or explain what statuses exist in the system. LLM must guess valid values or make discovery calls.
Missing pagination details in list_patients. Has a 'limit' parameter with default 20, but no 'offset', 'cursor', or 'page' parameter visible. No documentation of total count or whether there are more results. Large patient lists will be truncated without indication.