Loading ToolBench
MCP server for clinical charting with Claude - document patient visits directly into EMR
Three tools with complete JSON schemas and reasonable descriptions. Tool naming follows verb_noun convention (search_, create_, get_). Descriptions explain WHAT and WHEN, include prerequisites, and mention required vs. recommended fields. However, descriptions lack discovery guidance and alternative paths. Parameter descriptions are present but some lack format constraints or range limits. Output schemas are not documented, LLMs cannot infer what fields to expect from responses. No tool annotations (readOnlyHint, destructiveHint). Error handling guidance is absent from descriptions. Security considerations (audit trails, permission scopes) are not declared.
Create a visit note for a patient in the PointCare EMR system. This tool documents a home health visit including vital signs, assessment, and care plan. Use search_patient first to get the patient ID. Required fields: patientId, visitType, visitDate, timeIn, timeOut Recommended fields: vitalSigns, subjective, objective, assessment, plan
Retrieve visit history for a patient from the PointCare EMR system. Returns a list of previous visits with dates, types, and key information. Use this to review patient history before creating a new visit note. Use search_patient first to get the patient ID.
Search for a patient in the PointCare EMR system by name, ID, or phone number. Returns matching patient records with basic information. Use this tool to find patients before creating visit notes or retrieving history. Examples: - Search by name: "Eleanor Thompson" - Search by ID: "PT-10001" - Search by phone: "555-0101"
No documented output schemas. Tools declare inputs but not return types. LLMs cannot infer what fields to expect, forcing guesswork about response structure and breaking tool chaining.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). create_visit_note is a WRITE operation but the tool definition lacks a destructiveHint annotation. Agents cannot distinguish safe reads from risky writes without inspecting implementation.
Parameter format constraints missing or incomplete. E.g., visitDate accepts 'YYYY-MM-DD' but lacks a JSON Schema pattern or minLength/maxLength. timeIn/timeOut are described as 'HH:MM format, 24-hour' but not formally constrained. LLMs frequently generate invalid formats without explicit enum or regex constraints.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | <=2025-11-25 | v2 |
create_visit_note description does not mention error recovery or failure modes. If a visit note creation fails, the agent has no guidance on retry strategy, permission prerequisites, or what to try next.
No scope or permission declarations. Tools do not state what permissions they require (read:patient, write:visit, etc.). This makes least-privilege agent configuration impossible and breaks audit trail clarity.
search_patient accepts a 'query' string and optional 'searchType' enum, but the description uses examples ('Eleanor Thompson', 'PT-10001', '555-0101') rather than formalizing how the system resolves ambiguous inputs. If searchType='all', which field takes priority if multiple match?