IVF prices US clinics post, cited cost estimates, state IVF insurance laws, grants open now.
Scored across 5 tools
Each tool targets a distinct user question: employer-specific benefit documents, a cited cost estimate, clinic-posted self-pay prices, open grants, or state insurance law. The potential overlap between employer coverage and state insurance rules is clearly separated by employer-specific documents versus statutory requirements.
All names use readable snake_case, but the convention is mixed: estimate_ivf_cost and find_ivf_clinic_prices are verb-first, while employer_ivf_coverage, ivf_grants_open_now, and ivf_insurance_rules are noun-first. This is still understandable but not a predictable verb_noun pattern throughout.
Five tools fit the server's narrow reference purpose well, with each tool covering a distinct pillar: cost estimate, clinic prices, employer coverage, state insurance rules, and grants. There is no obvious redundancy or missing count-driven expansion.
The surface covers the stated domain comprehensively: IVF cost estimates, clinic self-pay prices, employer benefit coverage, state insurance mandates, and currently open grants. For a read-only US IVF information server, there are no obvious dead ends in the core workflows.
Whether a US employer's own benefit documents say it covers IVF or fertility treatment, with the dollar or cycle limit, who runs the benefit, and a verbatim quote and link to the document. Covers the large employers IVFcost.co has read; says so when an employer publishes nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| employer | Yes | The employer's name, for example Walmart or Google. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only/idempotent annotations, the description discloses that coverage is based on the employer's own documents, what details are returned, and that it reports when an employer publishes nothing. It does not explain behavior for an employer that is entirely absent from IVFcost.co's coverage, which is a minor gap.
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 dense sentences, with the core purpose front-loaded and the coverage caveat immediately after. There is no filler, and every clause adds either output detail or scope.
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?
For a one-parameter read-only lookup without an output schema, the description explains the return content and the main coverage limitation well. The one missing piece is explicit behavior when the employer is not in the dataset at all, as opposed to merely publishing no benefit document.
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?
Schema coverage is 100%, so the baseline is 3, but the description adds useful domain constraints: the employer must be a US employer and must be among the large employers IVFcost.co has read. It does not add input-format details beyond the schema's Walmart/Google examples.
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 states a specific verb and resource: whether a US employer's own benefit documents cover IVF or fertility treatment. It also lists the exact outputs (dollar/cycle limit, administrator, verbatim quote, link), which clearly separates it from sibling tools about clinic prices, grants, cost estimates, and general insurance rules.
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 scope implies when to use it: for a named US employer's own benefit documents, especially large employers IVFcost.co has read. However, it does not explicitly name alternatives or say when to prefer this over ivf_insurance_rules or estimate_ivf_cost.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A US IVF cost estimate built only from cited line items (the base cycle, medications, anesthesia, embryo freezing, a frozen transfer, genetic testing and other add-ons), with a low, typical and high figure per cycle and for several cycles, and the source of each line.
| Name | Required | Description | Default |
|---|---|---|---|
| cycles | No | How many egg retrieval cycles to plan for (default 1). | |
| include | No | Optional line items to count beside the base cycle. Leave out for the usual set (medications, anesthesia, freezing and a frozen transfer). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower, and the description still adds real substance. So the description adds real substance: the estimates are built *only* from cited line items, every figure carries its source, and the return contains per-cycle and multi-cycle low, typical, and high values. This tells the agent where the figures come from, but not whether they are cached or updated, and does not address rate limits.
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?
It is a single sentence with no filler, front-loaded on the core claim and followed by the component and output detail. The long nested parenthetical makes it denser than it needs to be, but nothing is wasted.
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?
For a two-parameter, read-only estimator with no output schema, the description carries the return-value burden well by specifying the low, typical, and high figures, their per-cycle and multi-cycle scope, and per-line source attribution. The main omission is a note that figures are national aggregates rather than clinic-specific, which matters given the neighboring clinic-price 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?
Schema coverage is 100%, so the schema already fully documents both `cycles` and `include`; the description adds only incidental color. Its parenthetical list (medications, anesthesia, embryo freezing, frozen transfer, genetic testing, add-ons) roughly echoes the `include` enum and its default set, and "for several cycles" hints at the `cycles` multiplier, but neither parameter is explained beyond that.
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?
It clearly states what the tool produces (a US IVF cost estimate) and names the exact components and output shape (low, typical, high per cycle and multi-cycle, with a cited source per line). The only gap is that it never distinguishes itself from siblings like find_ivf_clinic_prices, leaving it implicit that this is a generic national model rather than a specific clinic's pricing.
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?
Usage is only implied by the word "US" and the generic, line-item-based approach; the description never says when to choose this over find_ivf_clinic_prices, ivf_insurance_rules, or employer_ivf_coverage, nor does it state any exclusions. An agent can infer this tool suits ballpark planning, but the inference is not stated anywhere.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The self-pay IVF cycle prices that US fertility clinics post on their own websites, for one state (optionally one city), with what each price includes, the clinic's own page as the source, and the date it was read. Clinics are listed by name, not ranked. Many clinics post no price; the answer says how many do.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | Optional city to narrow the list (for example Houston). | |
| state | Yes | A US state: its two-letter code (TX) or its name (Texas). DC counts as a state here. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds useful context beyond them: data provenance (clinic websites), what each result includes (price inclusions, source page, read date), ordering (listed by name, not ranked), and coverage honesty (many clinics post no price, and the answer reports how many do).
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 tightly written sentences front-load the core purpose, then add essential caveats about ranking and coverage. Every sentence contributes useful information without waste.
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?
For a simple location-based lookup with no output schema, the description supplies enough return-value context (inclusions, source page, read date, coverage count) and safety is covered by annotations. An agent has what it needs to call the tool correctly.
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?
Schema coverage is 100%, so both the state and optional city parameters are already documented in the schema. The description confirms the state/city scoping but adds no syntax or semantic detail beyond what the schema provides, making the baseline 3 appropriate.
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 states a specific resource—self-pay IVF cycle prices posted on US fertility clinics' own websites—and scopes it to one state with an optional city. It is clearly distinct from siblings like employer coverage or insurance rules, though it does not explicitly name an alternative tool.
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?
Usage is implied by the state/city scoping and the focus on clinic-posted self-pay prices, but the description gives no explicit when-to-use guidance or comparison to siblings such as estimate_ivf_cost or employer_ivf_coverage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
US IVF and fertility grant programs that take applications today, open year-round, or open soon, each with its award, application fee, who can apply and its current window and deadline as the program posts it. Optionally only grants open to residents of one state.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | Optional: only grants open to residents of this state (code or name). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, non-open-world behavior, so the safety profile is fully covered elsewhere. The description adds genuine value by disclosing return contents (award, fee, eligibility, window, deadline) and the caveat 'as the program posts it', flagging that the data reflects each program's own publishing. It does not describe result volume, sorting, or what happens when no grants are open.
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?
A single front-loaded sentence puts the resource and scope first, then the returned fields and the optional filter. It is dense but each clause carries information; only the slightly sprawling return-field list costs it a perfect score.
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?
With one optional parameter, no output schema and full annotation coverage, the description supplies what the structured data cannot: what each result contains and the freshness caveat. The main omission is any clarification of borderline cases such as 'open soon' timing or empty results.
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?
Schema coverage is 100% and there is only one optional parameter, so everything needed (name/code, optionality) is already in the schema. The description's 'optionally only grants open to residents of one state' merely restates the schema filter without adding format or edge-case detail, which is the baseline-3 expectation.
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 names the resource precisely (US IVF and fertility grant programs) and its scope (taking applications today, open year-round, or opening soon), which clearly separates it from the cost/coverage/clinic siblings. The verb is implicit rather than stated ('programs that...'), so it stops just short of a 5.
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 single 'Optionally only grants open to residents of one state' clause implies usage for the state filter, and the enumeration of qualifying statuses implicitly defines the selection criteria. However, there is no explicit when-to-use guidance, no exclusions (e.g., how this differs from checking employer coverage), and no routing to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Whether a US state's law requires health plans to cover IVF, infertility treatment or fertility preservation, what the law requires as RESOLVE summarizes it, the statute, and which plans a state law cannot reach (self-funded employer plans).
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | A US state: its two-letter code (TX) or its name (Texas). DC counts as a state here. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, closed-world, non-destructive, so the safety profile is covered. The description adds genuine context beyond that: it discloses the substance of the answer (what the law requires, the underlying statute, and explicitly the self-funded employer plan carve-out where state law cannot reach), which sets expectations for a legal-information lookup.
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?
One sentence with no filler, and the core purpose is front-loaded. It is dense — three distinct payloads (RESOLVE summary, statute, unreachable plans) packed into a single clause chain — but every clause contributes 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?
A simple, single-parameter read tool with no output schema, and the description usefully previews what the response contains rather than needing a return-value section. It does not mention how to handle a state with no mandate (empty result vs. negative answer), which is the one gap an agent might hit.
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?
Schema coverage is 100% and the single `state` parameter already documents accepted forms (two-letter code or name, DC included). The description only reinforces that this concerns a US state's law, adding no format or validation detail beyond the schema. Baseline 3 is appropriate.
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 names the resource precisely (a US state's insurance mandate for IVF, infertility treatment, and fertility preservation) and states the outputs: the RESOLVE summary, the statute, and which plans fall outside state law. Scope is distinctive enough to separate it from employer_ivf_coverage, though it never names that sibling explicitly and reads as a noun phrase rather than a verb-led statement of what the tool does.
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?
Usage is only implied — an agent can infer this is the state-law lookup, and the parenthetical about self-funded employer plans hints at a boundary. But there is no explicit when-to-use, when-not, or routing to employer_ivf_coverage for employer-specific questions, which is the most likely confusion given the siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
employer_ivf_coverageestimate_ivf_costfind_ivf_clinic_pricesivf_grants_open_nowivf_insurance_rulesUS fertility and IVF clinics from the CDC's public data.
Search US hospital prices, compare costs, and find insurance-negotiated rates.
Cash-pay MRI prices at 5,419 US hospitals.
US drug price benchmarks — what a pharmacy PAYS and what Medicare PAYS OUT.
Add one secure layer between your agents and this server.
