Loading ToolBench
PostgreSQL MCP Server Demo with Healthcare Data
This healthcare MCP server has solid structure with 11 well-defined tools, proper JSON Schema with types, and consistent naming conventions. All tools follow verb_noun pattern (get_, create_, update_). However, parameter descriptions are sparse and inconsistent, many lack context on format, constraints, or when to use them. Output schemas are not documented anywhere in the source, forcing LLMs to infer response structures. Security considerations for healthcare data (PII, HIPAA) are completely absent from documentation. Error handling guidance is not visible. The server demonstrates basic competence but lacks the depth needed for production healthcare systems.
Create a new patient record in the system.
Create a new therapy/consultation session.
Get all denied insurance claims with reasons. Option to include appealed claims.
Get all outstanding payments (pending, partially paid, or denied). Optionally filter by patient.
Get detailed information about a specific patient, including all their sessions and payment history.
Search and retrieve patient records. Can filter by name, email, or insurance status.
Retrieve payment records with filtering by session, type, and status.
Output schemas completely undocumented. No tool documents what fields are returned, making it impossible for LLMs to plan downstream operations or extract required data for chaining.
Parameter descriptions are minimal or missing context. Examples: 'searchTerm' (what format?), 'dateOfBirth' in create_patient (validation rules?), 'notes' in create_session (max length?). LLMs cannot reliably construct valid requests without detailed constraints.
No error handling guidance documented. Tools do not explain retryability, user-fixable errors, or recovery steps. An LLM cannot distinguish between 'patient not found' (ask user) vs 'database timeout' (retry).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 50 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 45 | - | v1 |
Retrieve provider records. Can filter by specialty.
Generate a revenue report showing total charges, payments received, and outstanding amounts. Can filter by date range.
Retrieve session records with flexible filtering by patient, provider, status, and date range.
Update the status of a payment (e.g., mark as paid, denied, or appealed).
Healthcare-specific security missing from documentation. No mention of HIPAA compliance, PII handling, audit logging requirements, or consent validation. Descriptions do not clarify what data is sensitive or how to handle it responsibly.
create_patient and create_session accept data but do not document idempotency or duplicate handling. If an agent retries due to ambiguous failure, will duplicate records be created? Tool descriptions must clarify this.
List/read tools lack pagination documentation. get_patients, get_providers, get_sessions accept 'limit' but no 'offset', 'cursor', or 'page' parameter. No mention of max results or what happens if result set exceeds limit.
Date/time parameter formats assumed but not validated in descriptions. 'sessionDate in ISO format' assumes LLM knows ISO 8601; better to specify '2024-01-15T14:30:00Z'.
Tool chaining support unclear. If create_session returns a sessionId, can it be passed to get_payments? What IDs do tools return? Response schema must document this.