Skip to main content
Glama

check_aca_eligibility

Check if someone qualifies for ACA Marketplace health insurance subsidies in 2026. Provide household size (number of people) and estimated annual household income in dollars.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
annual_incomeYes
household_sizeYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

TDQS

A4/5.0
Behavior2/5

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

No annotations are provided, so the description must carry the full burden. It only states the check action without disclosing side effects, whether it accesses external data, or whether the result is a final determination or estimate. This lack of behavioral detail 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.

Conciseness5/5

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

The description is two clear, front-loaded sentences with no filler. It states the purpose and immediately gives input instructions.

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?

Given the low complexity and the presence of an output schema, the description covers the tool's purpose and both required inputs well. Minor gap: it doesn't mention that actual ACA eligibility may depend on additional factors such as Medicaid eligibility or minimum essential coverage.

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 input schema only provides integer types and titles, while the description adds key meaning: household size is 'number of people' and annual income is 'estimated... in dollars.' This compensates well for the schema's 0% description coverage.

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 'Check if someone qualifies for ACA Marketplace health insurance subsidies in 2026,' providing a specific verb and resource with a clear time frame. This distinguishes it from sibling tools about enrollment dates and contact information.

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?

It instructs the user to 'Provide household size (number of people) and estimated annual household income in dollars,' establishing clear inputs and an eligibility-check context. However, it does not explicitly name alternatives or exclusions relative to sibling tools.

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

A4.2/5.0
Disambiguation5/5

Each tool has a distinct purpose: checking eligibility, getting enrollment dates, and obtaining contact info. There is no overlap or ambiguity between them.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern: check_aca_eligibility, get_enrollment_dates, get_healthcovered_contact. The 'get_' prefix is used consistently for two of them, and 'check_' for the third, which is a clear action verb.

Tool Count5/5

Three tools is a well-scoped size for this server's purpose of providing ACA information and contact. Each tool addresses a core need: eligibility, timing, and human assistance.

Completeness4/5

The server covers the key questions users would have: eligibility, enrollment timing, and how to get help. A minor gap is the lack of a plan comparison tool, but the contact tool fills that need by directing users to human assistance.