Loading ToolBench
WellSky patient outreach workflow interface. Use the reach_out_to_patients tool to register outreach jobs and retrieve a summary report.
The server defines 2 tools with reasonable naming conventions (verb-noun format: get_active_patient_census, reach_out_to_patients). Tool descriptions are present and moderately detailed (183-186 chars, within the 10-1024 baseline). Input schemas are properly defined with types and enums for the census tool. However, significant gaps exist: the reach_out_to_patients tool lacks enum constraints on the optional message parameter, the output schemas are not documented anywhere in the code, error handling is absent (no recovery guidance), and parameter descriptions lack detail about valid formats and constraints. The census filter enum is well-specified (all|high_risk|hospitalization_flag), but the outreach tool's patientIds array and message fields need more prescriptive guidance. Tool composition is adequate (each tool does one thing), but there is no documentation of what fields the responses contain, making it impossible for LLMs to plan downstream operations.
Retrieves the active home care patient census from WellSky. Returns all patients with open care plans, hospitalization flags, upcoming visits, caregiver assignments, and risk levels.
Sends outreach notifications for a list of patient IDs using an internal directory to auto-resolve names and contact information. Only patientIds and an optional message are required. Returns a summary.
Output schemas not documented. Code shows tool descriptions but no declaration of what fields are returned by either tool. LLMs cannot infer response structure and must guess how to extract data for downstream operations.
reach_out_to_patients lacks input validation guidance. The 'message' parameter is optional but has no description of format, length, template variables, or constraints. LLMs will hallucinate valid message templates.
No error handling or recovery guidance. If reach_out_to_patients fails (e.g. invalid patient ID, messaging service down), there is no error message telling the LLM what to do next. No categorization of retryable vs user-fixable errors.
patientIds parameter lacks validation guidance. Description says 'List of patient IDs to reach out to' but does not specify format (string pattern like 'WS-###'?), length limits, or what happens if an ID is invalid.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 74 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 51 | - | v1 |
get_active_patient_census filter parameter description is minimal. Does not explain what data is filtered, when to use each filter option, or whether filters are mutually exclusive. LLMs may misuse high_risk vs hospitalization_flag.