Loading ToolBench
An outpatient clinic system that exposes queue, charts, and prescriptions as WebMCP tools for clinician and patient agents. Implements pre-visit intake, triage, and queue management with human-in-the-loop approval for all care-affecting actions.
Patiently WebMCP demonstrates solid tool design with clear naming conventions (verb_noun pattern), comprehensive descriptions (avg 150+ chars), and well-structured schemas. All 10 tools have explicit input schemas with typed parameters and descriptions. Tool composition is clean, each tool has a single responsibility. However, output schemas are not documented in the source code, and error handling guidance is minimal. The trust boundary design (read → draft → commit) is architecturally sound but not reflected in tool descriptions. Parameter descriptions could be more prescriptive about constraints and dependencies.
Call the next patient in the queue for this department. Requires the admin password.
Mark this patient's visit as complete. Requires the admin password.
Tell the clinic's intake agent about the patient's symptoms, in any language. Use this to answer the intake questions on the patient's behalf. The clinic's own triage system reads every message independently and will alert staff if it detects a danger sign.
Compose a clinical note for this patient's visit. The note is unsigned and will be shown to the clinician for review and approval before it is filed.
Compose a prescription for this patient. The prescription is unsigned and will be shown to the clinician for review and approval before it is filed.
Mark intake as complete and send the structured chart to the doctor. Call this once the patient has answered all the intake questions and the agent is satisfied the chart is ready.
Output schemas not documented. Tools return data but LLMs cannot plan downstream calls without knowing response structure (e.g., what fields does get_previsit_chart return? Does list_patient_queue include patient IDs for chaining?)
Admin-gated tools (call_next, complete_ticket) lack error guidance. Description says 'Requires the admin password' but does not explain what happens if password is wrong, how to recover, or whether the operation is idempotent.
Parameter constraints not fully specified. 'ticket' param in get_previsit_chart accepts 'ticket number' OR 'patient name' but schema does not document this dual-mode behavior or how the system disambiguates.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 74 | 2026-07-28+ | v2 |
See what the clinic has captured so far for this visit and what is still missing, so the agent knows what to ask the patient next.
Read the pre-visit chart the intake agents prepared for one patient: chief complaint, history of present illness, what changed since their last visit, suggested questions, and differentials to consider. Read this before seeing the patient.
Check this patient's live place in the clinic queue: position, how long the wait is expected to be, and who is being seen now.
List patients currently waiting or in consultation, with queue position, expected wait, and any triage red flags. Use this first to see the clinic floor. Covers all departments unless one is named.
Tools with empty input schemas (get_queue_status, get_intake_progress, finish_intake, call_next, complete_ticket) lack context about which patient/ticket they operate on. Unclear whether context is implicit (from UI session) or must be passed as a parameter.
Destructive operations (finish_intake, complete_ticket) lack confirmation or dry-run support. Agents may irreversibly mark intake complete or close a ticket without explicit user approval, despite the stated trust boundary design.