Loading ToolBench
MCP server for clinical charting with Claude - document patient visits directly into EMR
Server has three well-structured tools with complete JSON schemas and reasonable descriptions. All tools follow verb_noun naming convention and include parameter type definitions. However, descriptions lack depth and actionability, they read as functional overviews rather than LLM-optimized guidance. Parameter descriptions are present but sparse. Output schemas are not explicitly documented. Error handling is basic (tool execution failures return generic messages). The tools themselves are well-composed and cover a coherent clinical charting workflow, but lack the refinement and comprehensiveness expected of production-grade tools.
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"
Tool descriptions lack actionable context for LLM decision-making. Descriptions state WHAT tools do but omit WHEN to use them relative to sibling tools, prerequisites, and error recovery guidance. Example: search_patient says 'Find patients' but doesn't guide: 'Call this first before create_visit_note to obtain patient ID.' create_visit_note says 'documents a home health visit' but doesn't clarify when to use versus other visit types or whether vital signs are truly optional.
Output schemas are not documented. Tools return structured JSON responses but the schema is not specified in tool definitions. LLMs cannot plan downstream calls or extract chaining IDs without knowing output structure. Example: search_patient returns 'matching patient records' but nowhere in the schema is documented that responses include 'patientId' for use in create_visit_note.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 60 | <=2025-11-25 | v2 |
| 2026-03-09 | C | 63 | - | v1 |
Parameter descriptions are present but minimal. Many parameters have 1 - 2 sentence descriptions that lack format guidance, constraints, or examples. Example: vitalSigns.temperature has description 'Temperature', it doesn't specify units are controlled by temperatureUnit, acceptable range, or precision. LLMs cannot infer these constraints.
Error handling is generic and does not guide recovery. The tool executor in index.ts catches all exceptions and returns 'Tool execution failed: <error message>' with isError=true. This gives LLMs no actionable guidance (was it retryable? user-fixable? a service timeout?). No tool returns domain-specific error messages like 'Patient ID not found, call search_patient with patient name.'
No tool annotations present. create_visit_note and get_patient_history have side effects (write and read respectively) but neither declares readOnlyHint or destructiveHint. Tools should be annotated so agents understand which calls are safe to retry and which require confirmation.
Confirmation/dry-run pattern absent. create_visit_note is a destructive write operation (creates medical records) but offers no confirmation step or dry-run. Agents should be able to preview the note structure before committing to the EMR. Missing pattern:confirmation-request.
search_patient accepts a generic 'query' parameter with no format guidance. Rubric requires that when a parameter could be an ID, name, email, or phone, naming should suffix with the type (patient_id, patient_name, patient_phone) or provide separate parameters. The 'searchType' enum mitigates this partially, but the query field itself is ambiguous, LLMs cannot predict whether to pass 'Eleanor Thompson' or 'PT-10001' without trial.