Skip to main content
Glama

clearcarepulse

ClearCarePulse: Healthcare price transparency and cost navigation API. AI-synthesized procedure price search, cash-pay alternatives, hospital quality scoring, out-of-pocket estimation, insurance negotiation scripts,

Coverage: Global

Endpoints: • search ($0.15): Procedure price search • hospital ($0.10): Hospital price lookup • episode ($0.15): Total episode cost breakdown • oop ($0.15): Out-of-pocket cost calculator • alternatives ($0.10): Lower-cost care site alternatives • negotiate ($0.10): Medical bill negotiation guide • dental ($0.10): Dental cost intelligence • cosmetic ($0.10): Cosmetic procedure cost intelligence • rights ($0.05): Medical-Bill Rights Check (quiz-first) • rights-letter ($5.00): Citation-Locked Medical-Bill Letter • rights-check ($0.25): Medical-Bill Letter Preview (agent tier)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
hsaNoHas HSA (true/false)
zipNoPatient zip code for geographic search
langNoResponse language (e.g., 'Spanish')
checkNoWhich check to run
actionYesWhich endpoint to call. Options: search | hospital | episode | oop | alternatives | negotiate | dental | cosmetic | rights | rights-letter | rights-check
incomeNoAnnual income in USD (for charity care eligibility)
radiusNoSearch radius in miles
insuredNoinsured
oop_maxNoAnnual out-of-pocket maximum in USD
hospitalNoHospital name — e.g., 'Cleveland Clinic', 'Stanford Medical Center'
locationNoCity or region for geographic adjustment
msn_dateNomsn: Medicare Summary Notice date
scenarioNosurprise: what happened
bill_dateNogfe: bill date (120-day window)
nonprofitNoassistance: is the hospital nonprofit
oop_spentNoOOP already spent this year in USD
plan_typeNoPlan type (Bronze, Silver, Gold, Platinum, employer)
procedureNoProcedure name in plain English — e.g., 'knee MRI', 'colonoscopy', 'hip replacement'
claim_typeNoappeal: claim type (decision windows differ)
deductibleNoAnnual deductible in USD
gfe_amountNogfe: the estimate
bill_amountNoBill amount in USD
coinsuranceNoPatient coinsurance % (default: 20)
denial_dateNoappeal: denial notice date
patient_nameNoPatient name (placeholder if omitted)
service_roleNosurprise: clinician role (never-waivable ancillary detection)
annual_incomeNoassistance: annual income (FPL math)
billed_amountNogfe: the bill
has_insuranceNohas_insurance
provider_nameNoProvider/plan/hospital name
balance_billedNosurprise: balance-billed amount
consent_signedNosurprise: did you sign a notice-and-consent form
deductible_metNoDeductible already met this year in USD
household_sizeNoassistance: household size (FPL math)
procedure_costNoKnown procedure cost in USD
current_settingNoWhere currently scheduled (default: hospital outpatient)
final_denial_dateNoappeal: final internal denial (external-review window)
first_statement_dateNoassistance: first post-discharge statement (ECA/application windows)

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed2 schema fields changed
    • changedInput schema / properties / action / description
      Previous value: -"Which endpoint to call. Options: search | hospital | episode | oop | alternatives | negotiate | dental | cosmetic | rights | rights-letter"New value: +"Which endpoint to call. Options: search | hospital | episode | oop | alternatives | negotiate | dental | cosmetic | rights | rights-letter | rights-check"
    • changedInput schema / properties / action / enum
      Previous value: -[
      -  "search",
      -  "hospital",
      -  "episode",
      -  "oop",
      -  "alternatives",
      -  "negotiate",
      -  "dental",
      -  "cosmetic",
      -  "rights",
      -  "rights-letter"
      -]New value: +[
      +  "search",
      +  "hospital",
      +  "episode",
      +  "oop",
      +  "alternatives",
      +  "negotiate",
      +  "dental",
      +  "cosmetic",
      +  "rights",
      +  "rights-letter",
      +  "rights-check"
      +]
  2. Changed17 schema fields changed
    • changedInput schema / properties / action / description
      Previous value: -"Which endpoint to call. Options: search | hospital | episode | oop | alternatives | negotiate | dental | cosmetic | rights | rights_letter"New value: +"Which endpoint to call. Options: search | hospital | episode | oop | alternatives | negotiate | dental | cosmetic | rights | rights-letter"
    • changedInput schema / properties / action / enum
      Previous value: -[
      -  "search",
      -  "hospital",
      -  "episode",
      -  "oop",
      -  "alternatives",
      -  "negotiate",
      -  "dental",
      -  "cosmetic",
      -  "rights",
      -  "rights_letter"
      -]New value: +[
      +  "search",
      +  "hospital",
      +  "episode",
      +  "oop",
      +  "alternatives",
      +  "negotiate",
      +  "dental",
      +  "cosmetic",
      +  "rights",
      +  "rights-letter"
      +]
    • addedInput schema / properties / annual_income
      Added value: +{
      +  "description": "assistance: annual income (FPL math)",
      +  "type": "string"
      +}
    • addedInput schema / properties / balance_billed
      Added value: +{
      +  "description": "surprise: balance-billed amount",
      +  "type": "string"
      +}
    • addedInput schema / properties / bill_date
      Added value: +{
      +  "description": "gfe: bill date (120-day window)",
      +  "type": "string"
      +}
    • changedInput schema / properties / check / description
      Previous value: -"surprise | gfe | assistance | appeal | msn"New value: +"Which check to run"
    • addedInput schema / properties / claim_type
      Added value: +{
      +  "description": "appeal: claim type (decision windows differ)",
      +  "type": "string"
      +}
    • addedInput schema / properties / consent_signed
      Added value: +{
      +  "description": "surprise: did you sign a notice-and-consent form",
      +  "type": "string"
      +}
    • changedInput schema / properties / denial_date / description
      Previous value: -"appeal: YYYY-MM-DD"New value: +"appeal: denial notice date"
    • addedInput schema / properties / final_denial_date
      Added value: +{
      +  "description": "appeal: final internal denial (external-review window)",
      +  "type": "string"
      +}
    • addedInput schema / properties / first_statement_date
      Added value: +{
      +  "description": "assistance: first post-discharge statement (ECA/application windows)",
      +  "type": "string"
      +}
    • addedInput schema / properties / household_size
      Added value: +{
      +  "description": "assistance: household size (FPL math)",
      +  "type": "string"
      +}
    • addedInput schema / properties / msn_date
      Added value: +{
      +  "description": "msn: Medicare Summary Notice date",
      +  "type": "string"
      +}
    • addedInput schema / properties / nonprofit
      Added value: +{
      +  "description": "assistance: is the hospital nonprofit",
      +  "type": "string"
      +}
    • changedInput schema / properties / provider_name / description
      Previous value: -"Provider/plan/hospital for the letter"New value: +"Provider/plan/hospital name"
    • changedInput schema / properties / scenario / description
      Previous value: -"surprise: emergency | oon_at_in_network | air_ambulance | ground_ambulance"New value: +"surprise: what happened"
    • addedInput schema / properties / service_role
      Added value: +{
      +  "description": "surprise: clinician role (never-waivable ancillary detection)",
      +  "type": "string"
      +}
  3. Changed9 schema fields changed
    • changedInput schema / properties / action / description
      Previous value: -"Which endpoint to call. Options: search | hospital | episode | oop | alternatives | negotiate | dental | cosmetic"New value: +"Which endpoint to call. Options: search | hospital | episode | oop | alternatives | negotiate | dental | cosmetic | rights | rights_letter"
    • changedInput schema / properties / action / enum
      Previous value: -[
      -  "search",
      -  "hospital",
      -  "episode",
      -  "oop",
      -  "alternatives",
      -  "negotiate",
      -  "dental",
      -  "cosmetic"
      -]New value: +[
      +  "search",
      +  "hospital",
      +  "episode",
      +  "oop",
      +  "alternatives",
      +  "negotiate",
      +  "dental",
      +  "cosmetic",
      +  "rights",
      +  "rights_letter"
      +]
    • addedInput schema / properties / billed_amount
      Added value: +{
      +  "description": "gfe: the bill",
      +  "type": "string"
      +}
    • addedInput schema / properties / check
      Added value: +{
      +  "description": "surprise | gfe | assistance | appeal | msn",
      +  "type": "string"
      +}
    • addedInput schema / properties / denial_date
      Added value: +{
      +  "description": "appeal: YYYY-MM-DD",
      +  "type": "string"
      +}
    • addedInput schema / properties / gfe_amount
      Added value: +{
      +  "description": "gfe: the estimate",
      +  "type": "string"
      +}
    • addedInput schema / properties / patient_name
      Added value: +{
      +  "description": "Patient name (placeholder if omitted)",
      +  "type": "string"
      +}
    • addedInput schema / properties / provider_name
      Added value: +{
      +  "description": "Provider/plan/hospital for the letter",
      +  "type": "string"
      +}
    • addedInput schema / properties / scenario
      Added value: +{
      +  "description": "surprise: emergency | oon_at_in_network | air_ambulance | ground_ambulance",
      +  "type": "string"
      +}
  4. First observed

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It adds some useful context, such as per-endpoint pricing and 'quiz-first' or 'Citation-Locked' behavior for certain endpoints, but it does not disclose side effects, authentication needs, rate limits, data handling, reliability, or output format. For a tool handling sensitive healthcare cost data, this is a significant gap.

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 well-structured with a clear summary, coverage line, and bulleted endpoint list with prices. It is longer than a one-liner but each endpoint line earns its place by indicating available actions and costs. It could be tightened by removing redundant phrases, but the structure supports quick scanning.

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

Completeness2/5

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

With 38 parameters, 11 endpoint actions, and no output schema, the description is not complete enough for correct invocation. It does not specify which parameters are required for each action, provide examples, or describe return structures. The endpoint list is high-level and leaves the agent to infer the relationships between actions and parameters from schema prefixes and names.

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 description coverage is 100%, so every parameter already has an individual description. The tool description lists endpoint names but does not map parameters to specific endpoints or explain how to combine them, except through prefixes in the schema like 'gfe:', 'surprise:', and 'appeal:'. Thus the description adds little beyond the schema's built-in parameter documentation.

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

Purpose4/5

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

The description clearly identifies this as a healthcare price transparency and cost navigation API, listing specific endpoints like 'Procedure price search', 'Hospital price lookup', and 'Out-of-pocket cost calculator'. It is not a tautology and is distinct from the many sibling 'pulse' tools by explicitly naming healthcare and medical billing focus. However, it is an umbrella description for 11 endpoints rather than a single verb+resource statement.

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

Usage Guidelines2/5

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

The description lists endpoints and their prices but provides no guidance on when to use this tool versus alternatives or how to choose among the 11 actions. It does not state exclusions, prerequisites, or typical scenarios for each endpoint. The only context is 'Coverage: Global', which is not usage direction.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3.2/5.0
Disambiguation4/5

Each tool has a unique domain prefix (e.g., airdroppulse, alphapulse, arbipulse) making them mostly distinguishable at a glance. A few adjacent verticals like careerpulse vs talentpulse or marketpulse vs dealpulse have overlapping themes, but their descriptions clarify the distinct focus. The utility tools (catalog_search, discover, get_openapi_spec, x402_troubleshoot) are also clearly distinct in role. However, the sheer number of similar 'pulse' names could still cause misselection without reading descriptions.

Naming Consistency4/5

The dominant naming convention is `<domain>pulse` (e.g., climatepulse, cryptopulse, edupulse), which is highly consistent and predictable. Exceptions like catalog_search, discover, get_openapi_spec, x402_troubleshoot, and stateedge break the pattern, but these are few and serve obvious utility purposes. Overall, the convention is clear and easily learnable.

Tool Count2/5

With 80 tools, the server presents an extremely large and potentially overwhelming surface. While each tool represents a distinct intelligence vertical and navigation aids exist (catalog_search, discover, get_openapi_spec), the count far exceeds the typical 3-15 range for coherent agent use and even the 'heavy' 16-25 range. The burden of selecting the correct vertical from 80 options is significant, despite clear naming.

Completeness5/5

The server offers an exceptionally broad and deep coverage of domains, from finance and health to agriculture and gaming. Each vertical includes multiple endpoints that address core operations for its domain, such as search, analysis, comparisons, deterministic checks, and even action-oriented tools like letter generators and physical mail. The presence of free discovery and troubleshooting tools fills potential gaps, leaving no obvious dead ends in the overall tool surface.