Chia Health MCP Server

Create Order

order_create

Destructive

Create a new prescription medication order. The patient must have completed intake questionnaire and consent before ordering. Required: medication name, selected form (injectable, tablet, drops), plan duration (1, 4, or 6 months), shipping address. The order is reviewed by a licensed US healthcare provider who makes the final prescribing decision. If approved, medication is compounded at a US-licensed 503A pharmacy and shipped directly to the patient. Returns order ID, estimated provider review time, and expected delivery window. Payment is processed via Stripe Agentic Commerce Protocol (ACP). Requires authentication.

Input Schema

Name	Required	Description
`form`	Yes	Medication form: 'injectable', 'tablet', 'drops', 'nasal_spray' or 'cream'
`intake_id`	Yes	Approved intake ID from intake_submit
`medication`	Yes	Medication name (e.g. 'semaglutide') or its id from medications_list
`plan_months`	Yes	Plan duration in months (1, 4, or 6)
`bearer_token`	No	Authentication token for the patient session
`offering_slug`	No	The offering_slug medications_pricing returned for this plan. Pass it so the order is refused if a different plan went on sale since the quote.
`shipping_address`	Yes	Shipping address with keys: line1, city, state, zip, and optional line2

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 30, 2026

changedInput schema / properties / form / description

Previous value: -"Medication form: 'injectable', 'tablet', or 'drops'"New value: +"Medication form: 'injectable', 'tablet', 'drops', 'nasal_spray' or 'cream'"

changedInput schema / properties / medication / description

Previous value: -"Medication name to order"New value: +"Medication name (e.g. 'semaglutide') or its id from medications_list"

addedInput schema / properties / offering_slug

Added value: +{
+  "default": "",
+  "description": "The offering_slug medications_pricing returned for this plan. Pass it so the order is refused if a different plan went on sale since the quote.",
+  "title": "Offering Slug",
+  "type": "string"
+}

AddedApr 17, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=false; the description adds real context beyond that: licensed US provider review with final prescribing authority, 503A compounding, direct shipping, and Stripe ACP payment processing. It does not disclose duplicate-order behavior or whether an order can be cancelled (checkout_cancel exists), leaving a genuine gap for a destructive write.

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?

Front-loads the purpose in the first sentence and orders the workflow logically (prerequisites, inputs, fulfillment, return, payment). Slightly long, and the pharmacy/compounding detail is nice-to-have rather than decision-relevant.

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

Completeness4/5

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

For a complex, multi-step, authenticated write with nested address object, the description covers prerequisites, inputs, side effects, and outcome. Since an output schema exists, the return summary is a bonus; the remaining gap is failure/cancellation and duplicate-order semantics.

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

Parameters3/5

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

Schema coverage is 100%, so the baseline is 3. The description restates the required fields but omits intake_id from that list and narrows form to 'injectable, tablet, drops' while the schema also allows nasal_spray and cream, so it adds little and slightly risks misleading.

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?

Names a specific verb and resource ('Create a new prescription medication order') and frames the whole fulfillment pipeline, which separates it from siblings like checkout_create or order_status. An agent can identify the operation without opening the schema.

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?

States a hard prerequisite: intake questionnaire and consent must be completed first, which implicitly routes the agent to intake_submit/consent_submit before calling this. It stops short of naming alternatives or outlining when not to call it (e.g. existing order, refill path via portal_refill).

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

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.