Loading ToolBench
A medical RAG (Retrieval-Augmented Generation) system for answering doctor queries and retrieving patient analytics using Azure Search and OpenAI
HOAgent presents a healthcare-focused MCP server with two tools for medical queries and patient analytics. However, there are significant quality gaps across naming, schema clarity, and output documentation. Tool names are moderately clear but descriptions, while detailed, lack the structured information that production agents need. Input schemas are visible and typed, but output schemas are entirely undocumented, a critical gap for agent planning. Error handling is absent from the code; no recovery guidance or error categorization is present.
Answers a medical query for a specific patient using a Retrieval-Augmented Generation (RAG) system powered by the OpenAI Chat Completions API. This function takes in the name of a patient and a natural language query related to that patient. It then interacts with an OpenAI language model integrated with an indexer and data source (commonly known as a Retrieval-Augmented Generation setup). The indexer retrieves relevant context-specific medical data or notes about the patient, which are combined with the query to generate a precise and context-aware response from the LLM.
Retrieves patient records from a MongoDB collection filtered by age range and units, then asynchronously processes each patient's data to determine if they meet a specified condition. The function performs the following steps: 1. Queries the MongoDB collection for patients whose age is between `start_range_age` and `end_range_age` and whose age unit matches `units` ("years" or "months") and has a similarity to the condition stated in the query.
Output schemas are entirely undocumented. Neither tool documents its return type, structure, or fields. LLMs cannot plan downstream tool calls or extract specific data without knowing what fields to expect.
get_patient_analytics has a compound name ('get' + 'patient' + 'analytics') and an ambiguous description. It is unclear whether it returns patient records, a boolean indicator, a count, or analytics summaries. The description says 'determine if they meet a specified condition' but does not specify what 'meet' means or what the return value is.
No error handling or recovery guidance. The code contains bare exception re-raises ('raise e') with no categorization of retryable vs. fatal errors. LLMs receive no guidance on what to do if the Azure Search API is down, MongoDB is unavailable, or the patient name is invalid.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 5 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 41 | - | v1 |
Parameter 'units' in get_patient_analytics lacks an enum constraint. The description says 'typically "years" or "months"', but LLMs may hallucinate values like 'weeks', 'days', or 'decades'. Should be an enum: ['years', 'months'].
No pagination support. If get_patient_analytics returns a large list of patients, there is no limit parameter, offset, or pagination hint. Large result sets risk context window exhaustion.
Credentials are embedded in environment variables and used in HTTP requests with no validation of timeout behavior or retry logic. The httpx timeout is set to 60 seconds with no backoff strategy for transient failures.