Skip to main content
Glama

Check your coverage gap

check_coverage_gap
Read-onlyIdempotent

Computes how much life insurance a family needs, whether the coverage they have is enough, and which kind of life insurance fits their family. The computation is detailed and deterministic — the same engines as the Check and the calculator on clearlinefamily.com: a DIME coverage-gap computation over eight money facts (debts + years of pay to replace + mortgage + school costs, minus savings and coverage already held) and the Check's own kind scoring, which points to a product TYPE first (for example level term, convertible term, or a policy of your own alongside work coverage). Every money fact supplied flows into the gap figure, and the result shows the math line by line in plain words. The inputs are six situation answers and eight money numbers, and each one changes the computed number or the kind. The situation answers: household (just me / me and a partner / kids at home / kids grown and parents may need help); who would feel it if the pay stopped (my kids depend on it / mostly my partner / my partner earns and I run the home and the kids / no one depends on my income); what they want handled first (paying off debts / keeping household income going / the mortgage / school costs for the kids / final costs and loose ends); coverage already held (none / only through my job / through my job plus a policy of my own / a policy of my own); how long the protection must last (until the kids are grown / the next 20 to 30 years / my whole life / not sure yet); budget feel (lowest cost that truly covers the need / a middle path / build something long term). The money numbers, in dollars: their yearly pay, a partner's yearly pay, years of pay to replace (the Check's standard guess is 10 when they do not say), the mortgage still owed, other debts, school costs ahead, savings they could use, and the coverage amount already in place. Any fact not supplied is left out of the computation, and the result names what was not counted, money first. The result leads with the computed gap in the caller's own numbers and its method line. Education only, from a Washington practice: the tool names product types, never an insurance company or a specific policy, never says 'you should buy', asks nothing about health, and pitches nothing. Its closing lines separate Washington state rules from federal ones and name their public sources. It was written by an actuary in Redmond, Washington, whose Washington license is in progress. Nothing given to this tool is stored.

Input Schema

NameRequiredDescriptionDefault
horizonNoHow long the protection needs to last: until_kids_grown; next_20_to_30_years; whole_life; not_sure_yet. The slot that shapes the kind most. Note: until_kids_grown only applies when the household has kids at home, as on the site.
savingsNoSavings or cash they could use, in dollars. Comes off the need.
householdNoWho is in the household right now (the Check's question, same words): just_me = 'Just me'; me_and_partner = 'Me and a partner'; kids_at_home = 'Kids at home'; kids_grown_parents_may_need_help = 'Kids are grown. Parents may need help from me.' Changes the kind the Check points to.
budget_feelNoHow they think about the budget for this: lowest_cost = lowest cost that truly covers the need; middle_path; build_long_term = build something long term. Changes the kind for blend and permanent-leaning answers.
other_debtsNoOther debts to pay off, in dollars (cards, loans, anything but the mortgage).
coverage_nowNoLife insurance coverage they already have: none; only_through_my_job; job_plus_my_own = through my job, plus a policy of my own; a_policy_of_my_own. Strongly changes the kind: work-only coverage points to a policy of their own alongside it.
income_yearsNoYears of pay the coverage should replace. If not given, the Check's standard guess of 10 years is used and marked as a guess in the result.
school_costsNoSchool costs ahead they plan to pay, in dollars. Blank counts as $0.
who_feels_itNoIf their income stopped tomorrow, who would feel it: my_kids_depend_on_it; mostly_my_partner; partner_earns_i_run_the_home = 'My partner earns. I run the home and the kids.' (the stay-at-home caregiver case); no_one_depends_on_my_income. Changes the kind and flags the caregiver note.
annual_incomeNoTheir yearly pay in dollars, before tax is fine. The spine of the gap: pay times years to replace.
first_priorityNoWhat they would want handled first: paying_off_debts; keeping_income_going; the_mortgage; school_costs; final_costs_and_loose_ends. Sets which part of the DIME method line leads.
partner_incomeNoA partner's yearly pay in dollars, if a partner's pay also needs replacing.
mortgage_balanceNoMortgage still owed, in dollars.
existing_coverageNoCoverage amount already in place, in dollars (work plus their own). Comes off the need. If they only know a multiple of pay, multiply it out before calling: 2 times a $140,000 pay is $280,000.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the annotations (readOnly, idempotent, non-destructive, closed-world), the description discloses that the computation is deterministic and mirrors the site engines, that missing facts are omitted and named in the result, that the output leads with the gap and shows the math line by line, and that input is not stored. These are substantive behavioral traits the annotations do not cover.

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

Conciseness3/5

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

The purpose and method are front-loaded, but the body then re-lists all six situation answers and eight money numbers that the schema already documents field by field, inflating length. The actuarial-author and license-in-progress details add little to invocation decisions, so several sentences do not clearly earn their place.

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?

For a 14-parameter, no-required-field tool with no output schema, the description is thorough: it explains how inputs combine, how defaults are handled, what the result leads with and how the math is presented, and what is deliberately excluded. An agent has enough to call and interpret it correctly.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema by explaining the DIME relationship (pay times years to replace, fees/mortgage/school minus savings and existing coverage) and that any unmentioned fact is excluded and reported. Its restatement of the six situation and eight money fact categories somewhat duplicates the schema, keeping it below 5.

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 and resource: it 'computes how much life insurance a family needs, whether the coverage they have is enough, and which kind of life insurance fits their family.' It also names the exact method (DIME coverage-gap plus kind scoring), so an agent knows precisely what the tool produces 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?

It gives clear scoping context — education only, from a Washington practice, never a specific policy or company, no health questions, nothing stored — which tells the agent when this tool fits and its boundaries. There are no sibling tools to differentiate against, but it never explicitly states a 'use this when' trigger or when not to call it.

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.