Skip to main content
Glama

Compare child care benefit options

compare_care_options
Read-onlyIdempotent

Compare three ways to give staff child care places, for one number of staff children under 5 in Texas or New York: reserved places at nearby providers, a shared center with other employers, and an on-site center. Each option shows first-year and later-year cost, the estimated federal Section 45F credit (40 percent of qualified spending, up to 500,000 USD a year; 50 percent and 600,000 USD for an eligible small business) and the cost after that estimate. Compares the modelled employer payment with the 2026 7,500 USD per employee dependent care limit. Pass worksiteZip or state, and annualPrices from real quotes when known. Educational estimate, not tax advice.

Input Schema

NameRequiredDescriptionDefault
stateNoState when no ZIP is known
ageMixNoShare of enrolled children by age group, such as {infant: 0.3, toddler: 0.3, preschool: 0.4} (default)
childrenYesStaff children under 5 the benefit should serve; use staff.likelyEnrolments.mid from scan_childcare_slots
worksiteZipNoWorksite ZIP in Texas or New York; sets the state price table
annualPricesNoFull-time annual price per child in USD from real provider quotes; replaces the area defaults
employerShareNoShare of tuition the employer pays, 0 to 1 (default one third)
smallBusinessNoTrue only if the business says it meets the 45F small business test (average gross receipts of 32 million USD or less over the 5 prior years, related businesses counted together); raises the credit rate and cap

Output Schema

NameRequiredDescriptionDefault
stateNo
ageMixNo
creditYes
noticeYes
statusYes
optionsYes
sourcesNo
childrenNo
headlineYes
nextStepsNo
assumptionsNo
eligibilityYes
annualPricesNo
dependentCareNo
lowestFiveYearNetCostNo
employerShareOfTuitionNo
blendedAnnualPricePerChildNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / examples
      Added value: +[
      +  {
      +    "children": 40,
      +    "worksiteZip": "77030"
      +  }
      +]
  2. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the bar is lower; the description still adds real value by disclosing the modelled output fields (first-year and later-year cost, 45F credit estimate with rates and caps, post-credit cost), the 2026 $7,500 dependent care limit comparison, and the 'not tax advice' caveat. It does not cover precision/rounding of estimates, which keeps it below a 5.

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?

Front-loaded with the three options compared, then the output contents, then the input/usage line and disclaimer — a sensible order. The middle sentence is dense with parenthetical tax figures but each clause carries decision-relevant information; nothing is filler.

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 7-parameter modelling tool with nested objects, an output schema, and full annotations, the description supplies everything the agent needs: what is compared, what each option returns, the tax-credit assumptions, the input alternatives, and the legal caveat. No material gap remains for correct invocation or result framing.

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?

With 100% schema description coverage the baseline is 3, but the description adds the one thing the schema does not state: that worksiteZip and state are alternatives ('Pass worksiteZip or state'), and that default area price tables are replaced by annualPrices when quotes are known. The remaining parameters (ageMix, employerShare, smallBusiness, children) are only echoed, not enriched.

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?

States a specific verb (Compare) with a precisely enumerated resource: three named delivery models (reserved places, shared center, on-site center) for staff children under 5 in TX or NY. This is instantly distinguishable from siblings like scan_childcare_slots (which finds supply) and index_tools, since it is explicitly a cost-model comparison.

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?

Gives concrete input guidance ('Pass worksiteZip or state, and annualPrices from real quotes when known') and frames the output as an educational estimate rather than tax advice, which tells the agent how to present results. It stops short of explicit when-not-to-use or naming alternatives, but the operating context is clear.

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.