Chia Health MCP

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

Name	Required	Description
`age`	Yes	Patient's age in years (must be 18+). Confirm with the patient before submitting.
`bmi`	No	Patient'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.
`sex`	No	Patient'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.
`state`	Yes	US state abbreviation (e.g. 'CA', 'NY') where the patient resides. Confirm before submitting.
`client_ip`	No	Client IP address for rate limiting
`conditions`	No	List 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_status`	No	Pregnancy 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

Name	Required	Description	Default
`result`	Yes

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the readOnlyHint and openWorldHint annotations, the description discloses important server behavior: 'if you don't know, leave the parameter out and the server will return what is or isn't checkable.' It also details return content and lists specific disqualifying reasons, adding valuable transparency without contradicting any annotations.

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

Conciseness4/5

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

The description is organized into three clear paragraphs: purpose and parameter summary, parameter selection rules, and pre-fill/return behavior. Every sentence carries essential information, with no filler. It's concise for the number of parameters covered, though slightly longer than absolutely necessary, making it a 4 rather than a 5.

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?

Given the tool's complexity (7 parameters, 2 required, conditional logic), the description is thorough: it covers required vs optional parameters, conditional use of pregnancy_status, handling of missing values, pre-fill confirmation, return values, and disqualifying conditions. The output schema exists, so return value details aren't required, but the description still provides a high-level summary, making it complete.

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

Parameters4/5

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

The schema already has 100% parameter description coverage, so the baseline is 3. The description adds meaningful meta-guidance beyond the schema: 'Only pass parameters that apply to this patient,' how to handle uncertainty, and when pre-filling is acceptable. This lifts it above baseline, but it doesn't significantly alter the meaning of individual parameters, so a 4 is appropriate.

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 opens with a specific verb 'Pre-screen' and identifies the resource 'a patient's basic eligibility for telehealth prescription services,' clearly distinguishing it from sibling tools like medications_availability or intake_submit. The title 'Check Eligibility' is reinforced with concrete operational context, making the tool's purpose unmistakable.

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 explicit guidance on when to call: pre-screen a patient's eligibility, pre-fill only with confirmation from prior context, and omit parameters you don't know rather than inventing values. It clearly states the rule for pregnancy_status based on biological sex. However, it doesn't explicitly name alternative tools or list exclusion scenarios, which prevents a 5.

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 tools Inspect

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

A3.9/5.0

Disambiguation5/5

Every tool targets a distinct resource and action within the telehealth workflow: auth, consent, eligibility, intake, medications, checkout, order, portal, and provider communication. Even the multiple medication tools (list, details, availability, pricing) have clearly separated purposes, and there is no overlap among the 34 tools.

Naming Consistency5/5

All tool names follow a consistent `domain_verb` or `domain_noun` snake_case pattern, prefixed by their domain (auth_, checkout_, consent_, intake_, medications_, order_, portal_, provider_). There are no mixed conventions or vague verbs, making the API predictable and easy to navigate.

Tool Count2/5

With 34 tools, the server exceeds the 25+ threshold for 'too many' and feels fragmented. Many tools could be consolidated (e.g., medication pricing and availability could fold into details, and consent list/status could be combined). While the scope is broad, the count is excessive for a well-scoped MCP server.

Completeness4/5

The tool surface covers the full patient lifecycle from authentication and consent through eligibility, intake, checkout, order management, and post-order portal features. Minor gaps include lack of order cancellation or order listing, and no explicit intake update mechanism, but these are workable and do not block core workflows.

Resources

Need Help?