Loading ToolBench
Healthcare Model Context Protocol server that extends MCP with sampling capability for clinical data workflows, patient data access, and EMR integration
This server has severe definition quality issues. Of 9 tools listed, 4 are sampling handlers with completely generic/vague descriptions that do not clearly explain what they do or when to use them. Tool names are inconsistent and ambiguous (e.g., handle_*_sampling vs verb_noun patterns). Input schemas are generic and do not describe actual parameters, they reference abstract types like 'CreateMessageRequestParams' without expanding what fields agents actually need to pass. No output schemas are documented. Error handling is absent. The server conflates sampling (a deprecated MCP pattern) with regular tool invocation, which indicates foundational misunderstanding of MCP tool semantics. Several tools (handle_emr_writeback_sampling, handle_patient_data_sampling) appear twice with nearly identical names, signaling poor tool organization.
Clean up and close connection to an HMCP server
Connect to an HMCP server via HTTP transport with optional authentication
Send a message to an HMCP server and receive a sampling result. Supports conversation context and optional message history.
Handle EMR writeback requests. Processes clinical data and patient information, requiring patient_id to be present before confirming successful EMR updates.
Handle EMR writeback requests with LLM-powered responses. Uses GPT-4o to dynamically generate context-aware responses for clinical data validation and processing.
Handle gateway requests. Processes messages and returns acknowledgment responses from the standalone server.
Handle patient data access requests with LLM-powered responses. Uses GPT-4o to generate dynamic responses for patient identifier lookups and patient database queries.
Sampling handlers (5 tools) use vague 'handle_*_sampling' names that do not follow verb_noun pattern. Names like 'handle_emr_writeback_sampling' are generic; 'send_emr_update' or 'query_patient_data' would be clearer. LLMs cannot infer action intent from 'handle' + 'sampling'.
Tool input schemas are completely empty/generic. Tools reference 'CreateMessageRequestParams' type without documenting what parameters agents should actually pass. No descriptions of individual fields (e.g., what fields exist in 'params', what 'context' contains). Agents cannot infer valid inputs.
No output schemas documented. Tools return types.CreateMessageResult but agents do not know what fields are present, what format to expect, or how to extract relevant data. LLMs must guess structure.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 37 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Handle patient data access requests. Retrieves patient identifiers from a patient database based on patient name queries.
List all available tools from a connected HMCP server
Duplicate tool names (handle_emr_writeback_sampling appears twice, handle_patient_data_sampling appears twice) with only description variants. LLM cannot distinguish between the two versions, will arbitrarily choose one. Indicates poor tool organization.
Sampling handlers leak implementation details into tool definitions. Sampling is a deprecated MCP pattern (server-initiated LLM calls); these should be regular tools that agents invoke explicitly. Conflating the two indicates the server misunderstands MCP semantics.
Descriptions for sampling tools are under 100 characters and do not explain WHEN to use the tool or WHAT it returns. E.g., 'Handle patient data access requests. Retrieves patient identifiers from a patient database based on patient name queries.', lacks context on expected input parameters or output structure.
No error handling guidance. Tools do not document what errors can occur, whether they are retryable, or what the LLM should do on failure. E.g., if 'patient_id' is invalid, does the tool return a 404, 400, or timeout? How should the agent recover?
Tool 'connect' exposes 'url' parameter without validation. Agents could pass arbitrary URLs; no mention of whether the server validates endpoints or prevents SSRF. Security risk if this tool is exposed to untrusted agents.
Tools like 'create_message' accept 'model_params' as an untyped object. No schema definition, enum constraints, or documentation of valid keys/values. Agents will hallucinate arbitrary parameters.