Loading ToolBench
Evidence-based medical information server providing verified, doctor-recommended medical information from patient.info, which complies with NHS Information Standard and NHS Standard for Creating Health Content
This server has three tools with well-structured input schemas, but suffers from significant gaps in parameter descriptions, output documentation, and error handling. All three tools are READ_ONLY (safe) and have basic descriptions, but fall short of production standards. Tool names follow verb_noun convention (good), but parameter descriptions are mostly absent. No output schemas are documented. The code shows competent implementation (Cheerio scraping, Zod validation), but the tool interface definitions lack the completeness needed for reliable LLM interaction.
On a given topic, get evidence-based medical articles and information from patient.info (highly trusted by doctors, up-to-date medical resource).
Return a list of the current available topics from patient.info, to receive evidence-based medical information which is highly trusted by doctors and kept up to date.
Return the full content for a given list of articles from patient.info (highly trusted by doctors, up-to-date medical resource).
Output schemas not documented. No description of what return_available_topics(), get_articles_for_topic(), or return_full_content_for_articles() actually return. LLMs cannot plan downstream tool usage or extract the right fields without knowing the response structure.
Parameter descriptions missing or minimal. The 'topic' parameter in get_articles_for_topic has only 'Topic to search for', no guidance on format, length, or what happens if the topic is not found. The 'article_urls' parameter has a description but no constraints on array size, URL format validation, or error handling for unreachable URLs.
Error handling responses are not documented. When article fetching fails (e.g., 404, timeout, parsing error), the tool logs to stderr but there is no specification of what error format is returned to the LLM or what recovery action is suggested. The code catches errors and returns 'Content not available' (a fallback), but the tool definition does not state this.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
No pagination or result limiting documented. get_articles_for_topic and return_available_topics may return large lists without documented limits. If a topic has 500+ articles, the response could exhaust context. No limit, offset, or cursor parameters are defined.
Tool naming: 'return_available_topics' uses the verb 'return' which is passive and API-internal. Standard verb pattern is 'list_topics' or 'get_topics'. Similarly, 'return_full_content_for_articles' is verbose; 'fetch_article_content' or 'get_article_content' is clearer.
No documentation of what makes a valid topic or article URL. The code uses Cheerio selectors to parse responses, but the tool definition does not explain the expected structure, valid topic domains, or what happens if a URL is malformed or points to a non-patient.info resource.