Skip to main content
Glama

Chia Health MCP Server

by health.chia

Check Eligibility

eligibility_check
Read-only

Pre-screen a patient's basic eligibility for telehealth prescription services. Required: age (18+) and state (where the patient resides). Optional: BMI (20+ required for GLP-1 / weight-loss products), biological sex, pregnancy status, and diagnosed conditions.

Only pass parameters that apply to this patient. pregnancy_status applies ONLY when biological sex is female — omit it entirely for males. Don't invent values to satisfy the schema; if you don't know, leave the parameter out and the server will return what is or isn't checkable.

If you already know the patient's age, sex, state, height/weight from prior conversation context, you may pre-fill — but read the values back to the patient and get explicit confirmation before calling this tool. Returns eligibility status, available medications, and any disqualifying reasons (MTC/MEN2 history, pregnancy, out-of-coverage state, etc.).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ageYesPatient's age in years (must be 18+). Confirm with the patient before submitting.
bmiNoPatient's Body Mass Index. Required for GLP-1 / weight-loss eligibility (must be 20+). Omit for longevity products. Compute from confirmed height + weight; don't ask the patient to compute it themselves.
sexNoPatient's biological sex. Pass 'female' when you'll also pass `pregnancy_status` (so the server knows pregnancy screening was considered). Pass 'male' to make it explicit that pregnancy screening doesn't apply. Omit if the patient hasn't been asked yet and the product doesn't require sex for eligibility.
stateYesUS state abbreviation (e.g. 'CA', 'NY') where the patient resides. Confirm before submitting.
client_ipNoClient IP address for rate limiting
conditionsNoList of diagnosed medical conditions the patient confirms they have. Disqualifiers include medullary thyroid carcinoma (MTC) and MEN2 syndrome. Omit if the patient has no diagnosed conditions or hasn't been asked yet.
pregnancy_statusNoPregnancy status. Use one of these exact values: 'not pregnant', 'currently pregnant', 'planning pregnancy', 'breastfeeding'. ONLY applies when sex == 'female'. OMIT this parameter entirely for biological males — do NOT ask males about pregnancy.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, so safety is clear. The description adds rich behavioral detail: it discloses that unknown parameters should be omitted rather than invented, that pre-filling requires explicit patient confirmation, and that the response includes eligibility status, available medications, and disqualifying reasons. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three short paragraphs, each earning its place: first states purpose, second gives parameter rules, third covers pre-fill behavior and return content. It is front-loaded with the purpose and avoids filler, making it easy for an agent to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter tool with output schema, the description is exceptionally complete: it explains parameter semantics, covers edge cases (biological sex/pregnancy), provides patient-confirmation policy, and describes return values (eligibility status, medications, disqualifiers). Even with the output schema present, this adds essential context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline would be 3, but the description significantly adds meaning: pregnancy_status only for females, BMI threshold for GLP-1 products, confirmation-before-prefill requirement, and omit-if-unknown guidance. This goes beyond the schema's property descriptions and clarifies how to interact with the server.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a clear verb phrase, 'Pre-screen a patient's basic eligibility for telehealth prescription services', which conveys exactly what the tool does and its scope. It distinguishes itself from sibling tools like 'medications_*' by focusing on eligibility pre-screening, and from 'intake_*' by being a read-only check.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides strong usage context: it is for pre-screening before prescription services, and it gives specific parameter-passing rules ('Only pass parameters that apply', 'omit it entirely for males'). It does not explicitly name an alternative tool for a when-not-to-use case, but the unique purpose and sibling list make the usage clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Chia Health MCP Server toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0
Disambiguation4/5

Most tools have distinct purposes with clear boundaries, such as auth_* for authentication, checkout_* for payment, and portal_* for patient portal actions. However, there is some overlap between checkout_status and auth_check_payment (both involve polling for payment status) and between portal_support and portal_message (both for communication), which could cause minor confusion.

Naming Consistency5/5

Tool names follow a highly consistent verb_noun pattern throughout, with clear prefixes grouping related tools (e.g., auth_, checkout_, consent_, intake_, medications_, order_, portal_, provider_). This predictable structure makes it easy to understand the tool set's organization and purpose.

Tool Count3/5

With 34 tools, the count is borderline high for a telehealth server, as it may feel heavy and complex for agents to navigate. While the tools cover a comprehensive workflow from authentication to patient portal, some consolidation (e.g., merging similar polling tools) could improve usability without losing functionality.

Completeness5/5

The tool set provides complete coverage for the telehealth domain, including authentication, eligibility checks, medication browsing, intake, consent, checkout, order management, and patient portal features. There are no obvious gaps; agents can handle the entire patient journey from start to ongoing care without dead ends.

Resources