Plain-language MedlinePlus health terms and a MyChart check for family caregivers. No PHI.
Scored across 2 tools
The two tools serve completely different purposes: one explains medical terminology via MedlinePlus, the other checks MyChart availability for a hospital. There is no overlap in function or input domain, so an agent can select between them unambiguously.
Both names are snake_case, but the conventions differ: explain_health_term is a clean verb_noun, while find_mychart_for_sahara embeds a brand and a server-specific qualifier ('for_sahara'). The pattern is readable but not uniform.
Two tools is thin for a server whose stated purpose is summarizing a parent's MyChart record for caregivers; the core workflow is implied rather than exposed. It is borderline rather than severely mismatched, since both tools are genuinely useful.
The central capability—producing a plain-language summary of a parent's MyChart record—is not represented by any tool; the surface only covers a glossary lookup and a connectivity check. An agent cannot complete the primary task from this tool set.
Plain-language explanation of a medical condition, medicine, lab test or procedure, from MedlinePlus (US National Library of Medicine), in English or Spanish. Useful for family caregivers trying to understand an aging parent's diagnosis, prescriptions or test results. Educational only, never a diagnosis or treatment advice. Pass only the term itself, never names or other personal details.
| Name | Required | Description | Default |
|---|---|---|---|
| term | Yes | The term, e.g. "atrial fibrillation", "metformin", "A1C test". | |
| language | No | en (default) or es for Spanish. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive, open-world behavior, so the description's added value is the source attribution, language coverage, and the explicit disclaimer that output is educational rather than diagnostic advice. That disclaimer materially shapes how an agent should present results, which annotations alone would not convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each carrying distinct load: what the tool returns and from where, who it is for, and the safety/input constraints. The purpose is front-loaded and nothing is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does tell the agent to expect a plain-language explanation sourced from MedlinePlus, and it covers language support and input hygiene. Return shape details (e.g., fallback when a term is not found) are not addressed, a minor gap for a simple two-parameter lookup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters are already documented, setting a baseline of 3. The description exceeds that by constraining the 'term' input to the term alone and prohibiting names or other personal details, which is a semantic constraint not present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource — a plain-language explanation of a medical condition, medicine, lab test or procedure — and names the authoritative source (MedlinePlus, US NLM) plus the supported languages. The only sibling is unrelated, so there is no ambiguity about which tool handles terminology lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear usage context (family caregivers interpreting an aging parent's diagnosis, prescriptions or test results) and an explicit boundary: educational only, never a diagnosis or treatment recommendation. It does not name any alternative tool or when-not-to-use case beyond that scope caveat, but the sibling set offers nothing to redirect to.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Checks whether a hospital or health system offers Epic MyChart that Sahara can connect to, and returns the link to connect. Sahara gives adult children caring for an aging parent a plain-language summary of the parent's MyChart record (with the parent's proxy access). The record is shown only on sahara.synodha.com, never in this chat.
| Name | Required | Description | Default |
|---|---|---|---|
| health_system | Yes | Hospital or health system name, e.g. "Kaiser", "Mayo Clinic". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description adds genuinely new context beyond annotations: that the output is a connect link, that proxy access by the parent is required, and that the record appears only on sahara.synodha.com and never in chat — a meaningful privacy/scope disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core purpose and return value are front-loaded in the first clause, with supporting scope context after. The two trailing sentences about Sahara's product and hosting are slightly tangential for a lookup tool but do earn their place by explaining what the returned link leads to.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, non-destructive lookup with no output schema, the description covers purpose, return value, and privacy scope adequately. It stops short of describing the negative case (what is returned or how to respond when the health system is not supported), which is the one remaining gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single parameter is documented with concrete examples ('Kaiser', 'Mayo Clinic'), so the schema carries the parameter semantics. The description adds no matching guidance (e.g., fuzzy matching or accepted name formats), so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: checks whether a hospital or health system offers Epic MyChart that Sahara can connect to, and says it returns a connect link. The only sibling, explain_health_term, is clearly a different function, so an agent can distinguish them without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the pre-connection lookup step ('returns the link to connect') and explains the surrounding workflow, but it never explicitly states when to call it, what to do with a negative result, or which tool handles the next step. Usage is inferable rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
explain_health_termfind_mychart_for_saharaThe adaptive health-messaging engine for apps and agents. Federally-sourced. Not medical advice.
Consent-gated tools that turn user health notes into non-diagnostic appointment-prep materials.
Household health records with source attribution. Read and add records with OAuth approval.
MyHealthfinder MCP — U.S. preventive-services & health-screening guidance from ODPHP / health.gov…
Add one secure layer between your agents and this server.