healthcovered-mcp

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

With no annotations provided, the description carries the full burden. It adds the important temporal constraint ('2026'), but omits other behavioral details such as whether this is a calculation/estimation, error conditions for invalid income ranges, or data freshness guarantees.

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

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

The description is optimally concise at two sentences: the first establishes purpose and scope, the second specifies required inputs. No redundancy or wasted words.

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

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

Given the simple 2-parameter structure and existence of an output schema, the description is appropriately complete. It covers all necessary inputs and purpose without needing to describe return values, though it could briefly mention the output indicates subsidy eligibility level.

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

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

With 0% schema description coverage, the description compensates effectively by explaining both parameters: household_size is clarified as 'number of people' and annual_income as 'estimated' and in 'dollars', providing necessary semantic context missing from the schema.

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

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

The description clearly states the specific action ('Check if someone qualifies'), resource ('ACA Marketplace health insurance subsidies'), and scope ('2026'), distinguishing it from sibling tools dealing with enrollment dates and contacts.

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

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

The usage is implied by the specific domain (ACA subsidies in 2026), but there is no explicit guidance on when to use this versus the sibling tools (get_enrollment_dates, get_healthcovered_contact) or prerequisites for invocation.

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

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

No annotations provided, so description carries full burden. It discloses what data is retrieved (2026 dates, SEP triggers) but lacks details on data freshness, caching, or output format specifics. Adequate but minimal for a lookup tool with no safety annotations.

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

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

Two sentences with zero waste. First sentence front-loads the action and scope; second provides usage context. No redundant information.

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

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

Tool has output schema present, so return values need not be described. For a parameterless lookup tool, the description adequately covers intent, scope (2026), and usage triggers. No gaps given the simplicity of the tool.

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

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

Zero parameters in schema. Per guidelines, 0 params establishes baseline of 4. No parameter description needed or provided.

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

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

Description uses specific verb 'Get' with clear resources (ACA Open Enrollment dates, Special Enrollment Period triggers) and temporal scope (2026). It distinguishes from siblings 'check_aca_eligibility' (eligibility logic) and 'get_healthcovered_contact' (contact info) by focusing on temporal enrollment data.

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

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

Explicitly states when to use: 'when a user asks when they can sign up or if they missed enrollment.' Lacks explicit 'when not to use' or named alternatives, but the sibling tools have distinct purposes (eligibility vs. contact) making the usage context clear.

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

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

With no annotations provided, the description carries the full disclosure burden. It adds valuable business context (free service, subsidy focus) but omits operational behaviors like authentication requirements, rate limits, idempotency, or read-only nature that agents need to know.

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

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

The description is a single, efficient sentence that front-loads the core action ('Get contact information') and appends essential context without waste. Every word earns its place.

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

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

Given the tool's simplicity (zero parameters) and existence of an output schema, the description adequately covers the tool's purpose and domain context. It appropriately omits return value details since the output schema handles that responsibility.

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

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

The input schema contains zero parameters, establishing a baseline of 4 per the scoring guidelines. No parameter description is necessary or expected.

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

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

The description clearly states the specific action ('Get contact information') and target resource ('HealthCovered.org'), distinguishing it from siblings check_aca_eligibility and get_enrollment_dates by focusing on contact retrieval rather than eligibility checks or date queries.

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

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

The description provides domain context explaining what HealthCovered.org does (ACA enrollment assistance), which implies when to use it, but lacks explicit guidance on when to choose this over siblings or prerequisites for invocation.

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