This MCP server helps San Francisco families find and evaluate ELFA-subsidized childcare by combining official DEC eligibility rules, live CareWait program search, and CCLD licensing records, then ranking options with TypeSafe Jev.
Check ELFA eligibility (check_elfa_eligibility): given family size, income, and child age, returns the income tier (Free Tuition 0–110% AMI, Full Credit 111–150% AMI, Half Credit 151–200% AMI), exact monthly subsidy amount, and co-pay rules.
Search SF childcare (search_sf_childcare): query 500+ licensed CareWait programs by age, language immersion, program type, schedule, financial aid accepted, zip codes, and current openings, with pagination.
Get provider details (get_childcare_details): fetch a provider's classrooms, age limits, tuition rate tables by age group, contact info, and ELFA subsidy notes by entityId.
Get smart recommendations (get_smart_recommendations): combines age, income/benefit tier, budget, language, schedule, and home zip to compute net out-of-pocket costs and return a Jev-ranked shortlist (plus over-budget stretch options), with commute, licensing, budget-fit, and immersion ratings.
Retrieve official rates and rules (get_elfa_rates_and_rules): authoritative DEC FY 2026–2027 reimbursement rates, income ceilings for families of 1–12, and program rules with source citations.
Look up state licensing records (get_state_licensing_record): CCLD inspection history, capacity, complaint visits, substantiated allegations, and Type A/B violations by license number, with a citable public facility URL.
Compare reasoning approaches (compare_llm_vs_jev): an A/B matrix contrasting generative LLM narrative reasoning against TypeSafe Jev's deterministic probability scoring for human evaluation of recommendations.
Guide families through intake: the family_intake_interview prompt runs a two-round interview (age, potty training, family size, zip, schedule, daycare type; then income, budget, language) and maps answers to tool parameters.
Note: ranking features require a TYPESAFE_API_KEY; without it, recommendations return an error. Results are estimates and not an official DEC, CareWait, or CCLD product.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@SF Early Learning For All (ELFA) & CareWait MCP Server Find full-time Spanish immersion preschools in 94110 under $1500/month after ELFA subsidies."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An independent Model Context Protocol (MCP) server for San Francisco's Early Learning For All (ELFA) childcare assistance. It checks a family's eligibility against the Department of Early Childhood (DEC) tables, searches licensed programs in SF's CareWait listings, checks each one's state licensing record, and ranks the results with TypeSafe Jev.
Code gathers and verifies the facts. Jev (System One) then rates each verified program on commute, licensing record, budget fit, and language immersion, and recommendations are ranked by the weighted composite of those ratings.
Not official. This project is not affiliated with or endorsed by DEC, CareWait, or the California Community Care Licensing Division (CCLD), and it is not an authoritative source. Its costs and rankings are estimates: confirm eligibility with DEC, and tuition, openings, and ELFA participation with each provider.
Live CareWait Search: Search 500+ licensed San Francisco preschools and child care centers with real-time filters for age, language immersion, facility type, schedule (full-time vs part-time), and subsidy programs.
FY 2026–2027 SF DEC Rules: Embedded rate tables, HUD AMI / California SMI ceilings, age bracket definitions (Infant, Toddler, Preschool), and strict co-pay limits, with citations to the DEC source documents.
Net Out-of-Pocket Estimates: Applies the applicable credit to a published tuition rate, uses the conservative end of a known range for budget fit, and leaves blank or incomplete rates unverified.
Jev-Ranked Recommendations: TypeSafe Jev System One rates every verified program through TypeSafe's JavaScript SDK, using typed score and choice questions, and recommendations are ranked by the weighted composite. Requires TYPESAFE_API_KEY; without it, get_smart_recommendations returns an error rather than ranking programs another way. Jev's ratings are model judgments over verified facts; they do not replace CCLD records, DEC's eligibility rules, or a provider's confirmation.
Related MCP server: kealu-benefits-navigator
Tier | Household Income (HUD AMI) | Infant (0–24 mo) | Toddler (24–36 mo) | Preschool (3–5 yr) | Co-pay Rules |
Free Tuition | 0% – 110% AMI (≤$160,500/yr for family of 3) | $3,027 / mo | $2,306 / mo | $2,115 / mo | No co-pays or fees allowed |
Full Tuition Credit | 111% – 150% AMI ($160,501–$218,850/yr for family of 3) | $3,027 / mo | $2,306 / mo | $2,115 / mo | Co-pay = Tuition − credit |
Half Tuition Credit | 151% – 200% AMI ($218,851–$291,800/yr for family of 3) | $1,514 / mo | $1,153 / mo | $1,058 / mo | Family pays remaining tuition |
Credits are a percentage of DEC's full-time reimbursement rate, so they are the same for part-time care. DEC lists part-time rates only to calculate funding gaps between state vouchers and ELFA rates. Income ceilings for families of 1–12 are in DEC's income eligibility sheet; see Sources.
check_elfa_eligibilityComputes exact ELFA financial assistance tier, monthly credit amount, and co-pay rules given family size (1–12), income, and child age, and returns the DEC documents it relies on in sources.
search_sf_childcareQueries the live SF CareWait database with rich filters:
ageYears: e.g., 2.1
programType: licensedCenter (preschool center), licensedFamilyChildCare (home daycare), or any
financialAid: ["halfCreditELFA"], ["freeTuitionELFA"], ["cctr"], ["csppFullDay"], etc.
language: Spanish, Mandarin, Cantonese, French, Japanese, etc.
schedule: partTime, fullTime
openingsOnly: Boolean filter for programs with immediate vacancies.
zipCodes: List of San Francisco zip codes.
get_childcare_detailsFetches complete provider details by entityId: licensed classrooms, age limits in months, full infant/toddler/preschool tuition rate schedules, contact info (phone, email, and the provider's website), and DEC contract notes.
get_smart_recommendationsThe recommendation engine checks every CareWait match across San Francisco, fetches its details and CCLD record, and uses TypeSafe Jev to score every program that passes the fact checks. It takes child age, budget, language, schedule, income or benefit tier, daycare type (licensedCenter, licensedFamilyChildCare, or any; centers when omitted), and optional potty-training status. Code applies the checks described in How Recommendations Are Made. The family's home zip affects distance and Jev's commute rating; it does not limit the search. Both Jev-ranked lists (recommendations within budget and stretchOptions over it) are sorted by Jev's composite. Verification candidates follow in the order described by the skill.
Results contain at most 10 provider rows per page to keep each tool response below common client display limits; this is response pagination, not a cap on the search or result set. Clients must read every page through totalPages to access every matching program. Pass page (1-based, default 1) to read later pages; listTotals, totalPrograms, and totalPages describe the full search. Detail, processing, and search-page failures are also paged in chunks of 10, even when a page contains no provider rows. Summary counts, priceSummary, jevScoring, and coverage.complete are stable across pages. Per-program CCLD and Jev failure details appear on the page containing that program. Global failure counts remain stable. Each program carries a jev block (composite, 0–3 ratings, recommendation with a plain-language label, and probabilities). coverage reports the CareWait total, how many programs were checked, exclusions, and any detail, CCLD, or Jev failures.
A large search runs in the background so each MCP call stays below the client's 60-second timeout. If the tool returns status: "in_progress", call it again with the same search parameters; it joins the existing search and reports progress or the finished page. The completed result is cached for 30 minutes, so requesting another page does not repeat the search or Jev calls. Requires TYPESAFE_API_KEY. Missing provider aid data never becomes an assumed credit, and the DEC documents behind the credit amounts are returned in subsidySources.
get_elfa_rates_and_rulesReturns the FY 2026–2027 rate schedules, income ceilings (families of 1–12), and program rules as published by the Department of Early Childhood, with the DEC source documents in sources.
get_state_licensing_recordDirect integration with the California Community Care Licensing Division (CCLD) transparency database: retrieves inspection histories, capacity, complaint visits, substantiated allegations, Type A/B violations, and licensing conditions by license number. Each record includes ccldFacilityUrl, the facility's public CCLD page, for citation.
family_intake_interviewA two-round family interview generated from src/family-intake.js:
First round, asked together: child age in years and months, potty training, family size, neighborhood or zip, schedule, and daycare type (licensed center, family child care home, or either).
Follow-up round: household income, monthly budget, and language preference.
Each answer is mapped to a tool parameter. For example, "not sure" about potty training omits childIsPottyTrained, and "either" daycare type becomes programType: "any". Income is offered as dollar ranges for the family's household size, taken from the FY 2026–2027 ceilings, never as AMI percentages.
Facts stay in deterministic code; Jev makes the judgment calls.
Gather and verify (code): The search works outward from the family's zip code, as described above, and loads each program's CareWait details and CCLD records. A program must then pass these checks:
Current CCLD license status and complete inspection data. Missing or incomplete records are unknown, not clean. Providers with several licenses (e.g. separate infant and preschool licenses) are checked on every license, and the most severe finding is reported.
Facility type matching (dedicated commercial center vs in-home).
Exact classroom age compatibility in months. Missing age data is surfaced for review.
Published rate and provider-confirmed ELFA tier before placement in verified recommendations. Diapering accommodation is reported per provider (diaperingFitStatus) as a question for parents to confirm on tours, but is excluded from code-enforced gating and Jev composite scoring because CareWait provider records rarely populate the field (<2%). A missing aid list or rate note that conflicts with the provider's tier list is routed for verification.
Per-provider monthlySubsidyCredit is the credit listed for that provider and tier; monthlySubsidyCreditAppliedToRate is the amount actually subtracted. Already post-credit rates show zero subtracted to prevent double-discounting. scheduledMonthlySubsidyCredit is the DEC schedule reference when provider acceptance is not confirmed.
Programs that fail a check are listed for follow-up (unverifiedSafetyCandidates, unverifiedRateCandidates, unverifiedAgeCandidates) and are never sent to Jev, which is not asked to rate missing data.
Score (Jev): Every program that passes the fact checks goes to TypeSafe Jev System One, six calls at a time, with up to four SDK retries for transient failures. Successful judgments are cached for 30 minutes by program and family profile. Jev rates each one on a 0–3 rubric:
Commute: straight-line distance from the home zip code, when one is given.
Licensing record: the verified CCLD citations, complaint visits, and substantiated allegations.
Budget fit: the net monthly cost against the family's budget.
Language immersion: depth of immersion in the requested language, when one is given.
Jev also picks an overall recommendation (top_tier, strong_alternative, caution_flagged, unsuitable, or needs_verification), with probabilities.
Rank (composite): Each rating is divided by 3 and weighted, with the weights renormalized over the criteria that apply:
With a location: Location 30%, Safety 30%, Budget 25%, Immersion 15%.
Without a location: Safety 40%, Budget 35%, Immersion 25%.
With no language preference, immersion drops out and the other weights scale up.
A missing Jev answer lowers compositeCoverage instead of counting as zero. A program Jev could not score stays in its list, after the scored ones, with jev.status: "failed"; its error appears in coverage.jevFailed. jevScoring.candidatesNotScored is zero unless a Jev call fails. Cached judgments do not add their old token usage to the current search's totals.
Full-city search time and Jev cost scale with the number of matches. In the September 26, 2026 benchmark, fetching details and CCLD records for 516 programs took 25.2 seconds with 16 requests in flight. Jev averaged about 1,500 input and 125 output tokens per program; scoring 250 programs uses roughly 375,000 input tokens. coverage.complete is true only when all matches were retrieved and checked and no stage failed.
CareWait's 100 / 25 accommodation evidence values are ordinal signals, not likelihoods: 100 means that specific accommodation is explicitly listed and 25 means it is not confirmed. Diaper changes and potty-training support use separate values; a potty-training flag never confirms diaper changing.
Node.js >= 22.0.0 (CI tests Node 22 and 24 LTS)
git clone https://github.com/pmerlin1/sf-early-learning-mcp.git
cd sf-early-learning-mcp
npm install
npm testPull requests and pushes to main run npm ci, the test suite, and an npm dependency audit in GitHub Actions. Dependabot checks npm packages and pinned GitHub Actions weekly. To publish a source release, push a v<package.json version> tag (for example, v1.0.0); the release workflow reruns the checks, packages the project, and attaches the tarball to a GitHub Release. The project has no hosted runtime or deployment target, so this release workflow publishes a downloadable package rather than deploying a service.
Recommendations need a TypeSafe AI API key (see the TypeSafe docs). Set TYPESAFE_API_KEY in the MCP server's environment as shown below. The eligibility, search, details, and licensing tools work without it.
opencode.json)Add to your opencode.json (global ~/.config/opencode/opencode.json or project-local ./opencode.json):
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"sf-early-learning": {
"type": "local",
"command": [
"node",
"/absolute/path/to/sf-early-learning-mcp/src/index.js"
],
"enabled": true,
"environment": {
"TYPESAFE_API_KEY": "{env:TYPESAFE_API_KEY}"
}
}
}
}Add to your claude_desktop_config.json:
{
"mcpServers": {
"sf-early-learning": {
"command": "node",
"args": ["/absolute/path/to/sf-early-learning-mcp/src/index.js"],
"env": {
"TYPESAFE_API_KEY": "your-typesafe-key-here"
}
}
}
}Once configured in your AI client (OpenCode, Claude, Cursor), try these copy-paste prompts. Before recommending, the agent asks whatever the prompt leaves out (age in months, potty training, household size, schedule, daycare type, income range, budget, and language), then returns tables ranked by Jev.
"I have a 2-year-old child, and live in San Francisco zip 94102. Walk me through the Early Learning For All (ELFA) options, check my eligibility, and recommend preschools based on my budget and language immersion."
"We have the ELFA Half Tuition Credit for our 2-year-old and live in North Beach (94133). Which licensed centers (not home-based) near us offer Cantonese immersion for under $1,200 a month out of pocket?"
"We are a family of 4 living in San Francisco with a gross monthly income of $15,000. Do we qualify for ELFA Free Tuition or the Full Credit? What is our monthly voucher amount for a 2-year-old toddler and a 4-year-old preschooler?"
"Our 3-year-old has the ELFA Full Tuition Credit and we live in the Mission (94110). Rank Spanish immersion programs, centers or family child care, that would cost us under $500 a month, and show the Jev ratings behind each ranking: commute, licensing record, budget fit, and immersion."
Examples for a toddler (24–36 months) in the Half Tuition Credit tier ($1,153/month credit):
What CareWait publishes for the toddler age group | Estimated net monthly cost |
A gross tuition range of $0–$1,383 | $230 ($1,383 − $1,153; the upper end of the range is used for budget fit) |
An amount the provider's notes say is charged after the ELFA credit, e.g. $0–$1,153 | Up to $1,153 (the credit is not subtracted a second time) |
A blank rate, or only a preschool rate | Unknown; the rate is unverified until confirmed on the provider's own site or by the provider |
Any rate, with the family in the Free Tuition tier (0–110% AMI) | $0, conditional on an approved ELFA award and an available funded slot |
The credit applies only at providers whose CareWait financial-aid list includes the family's ELFA tier. It is the same for part-time care.
DEC figures and rules come from these FY 2026–2027 documents, published July 1, 2026 and accessed September 24, 2026:
Early Learning For All Rates – Fiscal Year 2026–2027: reimbursement rates and monthly credit amounts. Its footnote says part-time rates are listed only to calculate funding gaps between state vouchers and ELFA rates.
FY 2026–2027 San Francisco Family Income Eligibility: State CCTR/CSPP and ELFA income ceilings for families of 1–12.
Eligibility for free or low-cost preschool and child care (SF.gov): tier definitions and co-pay rules.
DEC posts both FY 2026–2027 sheets on its rates page. The older legacy.sfdec.org page still shows FY 2025–2026 figures. Provider tuition comes from CareWait, and licensing records from the California CCLD transparency API.
TypeSafe Credential: Jev requires TYPESAFE_API_KEY in the environment. The CareWait API key is a public client credential used by the provider's browser-facing service.
Dependency Audit: Verified with npm audit (0 vulnerabilities).
CI Checks: GitHub Actions runs the unit tests and dependency audit on pull requests and pushes to main.
Dependency Updates: Dependabot checks npm packages and GitHub Actions weekly, with a cooldown for routine version updates.
Secret and SAST Scanning: No repository-managed scanner is configured yet; add one before treating the CCSF standard's security scanning guidance as fully met.
Deterministic Logic: Income brackets and credit arithmetic are executed in code; unknown prices and incomplete licensing records remain explicitly unverified.
Run unit tests and verification suite:
npm testRun headlessly via OpenCode:
opencode run "Using the sf-early-learning MCP, check ELFA eligibility for a family of 3 with monthly income of $18000 and a 2.1-year-old child"MIT © 2026 Paul Merlin
Calculate San Francisco Early Learning For All (ELFA) financial assistance eligibility, income tier (Free 0-110% AMI, Full Credit 111-150% AMI, Half Credit 151-200% AMI), exact monthly subsidy amounts, and co-pay rules for a family.
| Name | Required | Description | Default |
|---|---|---|---|
| familySize | Yes | Total number of family members (parents/caregivers and dependent children under 18) | |
| annualIncome | No | Gross annual household income before taxes | |
| childAgeYears | No | Age of the child in years (e.g., 2.1 for 2 years and 1 month) | |
| monthlyIncome | No | Gross monthly household income before taxes and deductions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the calculations performed but does not state that it is a read-only operation, what assumptions are made (e.g., which income field is used when both annualIncome and monthlyIncome are provided), or what happens if required inputs are missing. It does not contradict annotations (none exist), but it is not fully transparent about behavioral constraints.
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 sentence that is concise and front-loads the primary purpose. It efficiently lists the key outputs without unnecessary detail, though the sentence is slightly long due to the enumeration of tiers and amounts.
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?
The description covers the main outputs (eligibility, tier, subsidy, co-pay) but lacks guidance on input requirements, such as whether annualIncome or monthlyIncome is needed, or if both are accepted. Given there is no output schema, more explicit usage context would be helpful. The description is adequate but not fully complete for a calculation tool with multiple optional parameters.
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 already provides detailed descriptions for all four parameters (100% coverage). The tool description does not add additional semantic detail beyond the schema, such as how parameters interact or which are required for a valid calculation. It remains at the baseline level expected when schema coverage is high.
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 verb 'calculate' and the specific resource (San Francisco Early Learning For All financial assistance eligibility), and enumerates the exact outputs (income tier, monthly subsidy amounts, co-pay rules). This distinguishes it from sibling tools like get_elfa_rates_and_rules, which likely provides general rate information rather than per-family calculations.
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 implies usage (for calculating a family's eligibility) but does not explicitly compare with alternatives or state when not to use it. No mention of exclusions or conditions for choosing this tool over siblings like get_elfa_rates_and_rules, leaving the agent to infer from tool names and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A/B comparison between Generative LLM narrative reasoning (Claude, GPT, Gemini) and TypeSafe Jev System One deterministic probability decision scoring for human evaluation of preschool recommendations.
| Name | Required | Description | Default |
|---|---|---|---|
| familySize | No | Family size (default 3) | |
| benefitTier | No | ELFA benefit tier (default halfCreditELFA) | |
| homeZipCode | No | Family home zip code (e.g. 94121) to calculate distance and score location convenience | |
| childAgeYears | No | Age of the child in years (default 2.1) | |
| candidateCount | No | Number of candidates to evaluate in the A/B matrix (default 5) | |
| preferredLanguage | No | Preferred language immersion (e.g. Spanish, Mandarin, French) | |
| targetBudgetMonthly | No | Target monthly budget (default 1200) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the conceptual comparison but doesn't disclose what the tool actually does operationally: does it call external LLM APIs? Does it return a side-by-side table? Does it make network calls or cost money? Does it have rate limits? The description is abstract about the mechanism and output, leaving the agent uncertain about side effects and requirements.
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 sentence that packs in the core concept, but it's dense and jargon-heavy ('TypeSafe Jev System One deterministic probability decision scoring'). It front-loads the comparison concept but the sentence is long and could be clearer with a brief mention of what the output looks like. It's not overly verbose, but it's not optimally scannable.
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 tool with 7 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the A/B comparison produces (a report? a score? a recommendation?), whether it requires external API access, or how the parameters influence the comparison. An agent would struggle to know what to expect from the tool's output or how to interpret the 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 description coverage is 100%, so the schema already documents all 7 parameters. The description adds no additional parameter-level meaning beyond the schema. Baseline 3 is appropriate since the schema does the heavy lifting and the description doesn't need to compensate.
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 tool's purpose: an A/B comparison between LLM narrative reasoning and TypeSafe Jev System One deterministic scoring for preschool recommendations. It names the specific systems being compared and the domain (preschool recommendations). However, it doesn't explicitly distinguish it from sibling tools like get_smart_recommendations, which might also produce recommendations, though the comparison aspect is unique.
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 implies the tool is used when a user wants to compare two different recommendation approaches, but it doesn't explicitly state when to use this tool versus alternatives like get_smart_recommendations or search_sf_childcare. There's no explicit 'use this when' or 'instead of' guidance, so the usage context is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve complete details for a specific SF childcare or preschool center by its entityId, including exact tuition rates table by age group, programs, schedule, languages, contact info, and ELFA subsidy notes.
| Name | Required | Description | Default |
|---|---|---|---|
| entityId | Yes | The entityId of the provider |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only retrieve operation, but does not explicitly state safety, side effects, error handling, or any prerequisites. It also does not mention whether the returned data is comprehensive or if there are limitations. Given no annotations, this 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence that front-loads the verb and resource, then lists the included content. It is concise with no filler, though it is somewhat long due to the enumerated details. The structure is effective and easy to parse, earning a 4 rather than 5 for slight density.
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 tool with one parameter and no output schema, the description is quite complete. It enumerates exactly what data will be returned (tuition rates table, programs, schedule, languages, contact info, ELFA subsidy notes). However, it lacks information about error handling, null returns, or any prerequisites, which a thorough description might include. Given the tool's simplicity, this is a 4.
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% with the entityId parameter described as 'The entityId of the provider'. The description adds minimal extra meaning beyond confirming that the entityId is used to retrieve details, but it does not provide format, type, or validation information beyond what the schema already gives. Since coverage is high, a baseline of 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 clearly states the verb 'Retrieve' and the resource 'specific SF childcare or preschool center by its entityId', listing exact content like tuition rates, programs, schedule, languages, contact info, and ELFA subsidy notes. This is a specific, unambiguous purpose that distinguishes it from sibling tools like search_sf_childcare (search) and get_elfa_rates_and_rules (rates focus).
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 no guidance on when to use this tool versus alternatives, nor any conditions or exclusions. It does not mention that it is the tool to use when complete details are needed, nor does it reference sibling tools. An agent would have to infer usage from the purpose alone, which is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get authoritative San Francisco Department of Early Childhood (DEC) official FY 2026-2027 reimbursement rates, income eligibility tables, and program rules.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It conveys that the tool is a read-only retrieval of official rates, tables, and rules ('Get'), but it does not disclose output format, data source behavior, update cadence, or access requirements. This is minimally viable but not richly transparent.
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 front-loaded sentence with no wasted words. It packs in the jurisdiction, department, fiscal year, and three content types without repetition or tangential 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?
For a no-parameter retrieval tool, the description is mostly complete, but the absence of an output schema means the description has to carry return-value meaning. It names the content areas but not the structure or format, and it does not clarify how this tool relates to check_elfa_eligibility despite the overlapping income eligibility language.
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?
There are zero parameters and the schema is an empty object, so the input schema already fully documents the call signature. The description correctly adds no parameter details; the 0-parameter baseline of 4 applies.
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 ('Get') and a concrete resource: San Francisco DEC official FY 2026-2027 reimbursement rates, income eligibility tables, and program rules. This clearly distinguishes it from sibling tools like check_elfa_eligibility and search_sf_childcare, which focus on checking eligibility or searching childcare options.
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 gives no explicit when-to-use or when-not-to-use guidance, and it does not mention alternatives. It leaves the relationship to check_elfa_eligibility ambiguous, especially since both involve income eligibility content. The intended usage is only implied by the tool's purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Intelligent recommendation engine: combines child age, family size, income/known benefit tier, max out-of-pocket budget, language immersion preferences, and facility type to calculate net out-of-pocket costs and produce a tailored shortlist of preschool centers.
| Name | Required | Description | Default |
|---|---|---|---|
| schedule | No | Schedule preference | |
| familySize | No | Total number of family members | |
| maxResults | No | Number of top recommendations to return (default 10) | |
| benefitTier | No | Pre-known ELFA benefit tier if already determined | |
| homeZipCode | No | Family home zip code (e.g. 94121) to prioritize immediate neighborhood facilities and calculate exact commute distance | |
| programType | No | Default is licensedCenter (dedicated preschool center) | |
| annualIncome | No | Gross annual household income | |
| childAgeYears | Yes | Age of the child in years (e.g., 2.1) | |
| monthlyIncome | No | Gross monthly household income | |
| preferredLanguage | No | Preferred language immersion (e.g. "Spanish", "Mandarin", "Cantonese", "French") | |
| targetBudgetMonthly | No | Maximum desired out-of-pocket monthly cost (e.g. 1200 or 0) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the transparency burden. It does disclose the main computation (combining child/family/financial/language inputs to calculate net costs and rank a shortlist), but it says nothing about output format, failure modes, missing-data behavior, or whether it is read-only.
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 sentence conveys a lot of information without wasted words, and the outcome is stated clearly. It lists many inputs, making it slightly dense, but no sentence or clause is extraneous.
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?
This is an 11-parameter tool with no output schema and no annotations, yet the description only gives a high-level summary. An agent is left without guidance on the shortlist's return fields, how optional income/benefit inputs interact, defaults, or what to do when only childAgeYears is provided.
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 already documents 100% of the parameters, so the baseline applies. The description adds conceptual meaning by grouping several parameters into a cost-calculation and tailoring workflow, but it doesn't define formats or interplay beyond 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 names a concrete deliverable—a tailored shortlist of preschool centers with calculated net out-of-pocket costs—and states the inputs used. It stops short of explicitly contrasting itself with sibling search tools, so it doesn't fully earn a 5, but the core action and resource are unambiguous.
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 implies when to use the tool: when a personalized, cost-aware recommendation is needed rather than a plain directory search. It gives no explicit when-not-to-use guidance or pointer to siblings like search_sf_childcare or check_elfa_eligibility.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve official California Community Care Licensing Division (CCLD) state inspection history, capacity, complaint visits, substantiated allegations, Type A/B violations, and official comments for a child care facility by license number.
| Name | Required | Description | Default |
|---|---|---|---|
| licenseNumber | Yes | The California child care facility license number (e.g. "384001291") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden of behavioral disclosure. It does a good job enumerating the data categories returned, but it omits any statement about auth requirements, read-only behavior, error cases, freshness, or what happens for an invalid license number. 'Retrieve' implies a read operation, but the description could be more explicit about operational behavior.
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, well-structured sentence with the most important information front-loaded. Every phrase contributes specific value, and there is no filler, repetition, or unnecessary qualification.
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 single-parameter get-by-license-number tool with no output schema, the description is largely complete: it states the required input, the jurisdiction, the record type, and the key data elements returned. It does not describe response format or error handling, but these are minor gaps given the tool's simplicity.
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 schema already documents licenseNumber with 100% coverage and includes an example. The description only says 'by license number,' adding little semantic meaning beyond the schema, so the baseline score of 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 a specific verb (Retrieve) and a specific resource: official California CCLD state licensing record data for a child care facility by license number. It enumerates concrete content areas (inspection history, capacity, complaint visits, substantiated allegations, Type A/B violations, official comments), making it clearly distinct from the sibling tools like get_childcare_details or search_sf_childcare.
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 gives clear context: use this when you need official California CCLD licensing history or related regulatory data for a child care facility and you have its license number. It does not explicitly name alternatives or state when not to use it, but the license-number requirement and the official-state-record framing provide sufficient routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the official San Francisco CareWait database of over 500 licensed early care and preschool programs with real-time filters.
| Name | Required | Description | Default |
|---|---|---|---|
| skip | No | Pagination offset (default 0) | |
| take | No | Number of results to return (default 20, max 50) | |
| hours | No | Specific hours (e.g., daytimeCare, schoolHours, beforeCare, afterCare) | |
| ageYears | No | Age of the child in years (e.g. 2 for 2-year-old) | |
| language | No | Language taught or immersion language (e.g. "Spanish", "Mandarin", "Cantonese", "French", "Japanese") | |
| schedule | No | Schedule preference: partTime or fullTime | |
| zipCodes | No | List of San Francisco zip codes to restrict search to | |
| programType | No | Type of program: licensedCenter (preschool center), licensedFamilyChildCare (in-home), or any | |
| financialAid | No | Financial assistance types accepted (e.g., ["halfCreditELFA"], ["freeTuitionELFA"], ["fullCreditELFA"], ["cctr"], ["headStart"], ["csppFullDay"]) | |
| openingsOnly | No | If true, only returns programs that currently have open spots |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the burden of behavioral context. It adds 'official... database' and 'real-time filters,' which help set expectations about freshness and scope, but it does not disclose output characteristics, pagination, or edge cases like empty results or invalid filter combinations.
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 with no filler. It communicates the resource, scope, and capability efficiently, and every phrase contributes value.
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?
The tool has 10 optional parameters and no output schema, so the description's scope-setting sentence is helpful but not fully complete. An agent still depends on the parameter descriptions for effective usage and has no guidance about what the result set looks like beyond 'programs.'
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 description coverage is 100%, so the description does not need to re-explain parameters. It adds only the general 'real-time filters' framing, which aligns with the schema but does not add meaningful detail beyond it.
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 is specific and actionable: it names the exact resource (official San Francisco CareWait database), the resource type (licensed early care and preschool programs), and the operation (search with real-time filters). It also conveys the tool's profile sufficiently to distinguish it from siblings like get_childcare_details and check_elfa_eligibility.
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 implies a general search-and-filter use case but does not explicitly state when to use this tool versus alternatives such as get_childcare_details or get_smart_recommendations. It gives clear context about what it searches but no exclusion criteria or sibling routing.
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.
v1.0.0check_elfa_eligibilitycompare_llm_vs_jevget_childcare_detailsget_elfa_rates_and_rulesget_smart_recommendationsget_state_licensing_recordsearch_sf_childcareScored across 7 tools
Most tools have clearly distinct purposes: rates/rules, eligibility, search, details, recommendations, comparison, and licensing records. The only potential confusion is between get_elfa_rates_and_rules and check_elfa_eligibility, but their descriptions are specific enough to separate reference data from calculation.
Tool names mostly follow a consistent get_/check_/search_/compare_ verb pattern with descriptive noun phrases. Minor inconsistency: compare_llm_vs_jev uses an abbreviation-heavy name and doesn't follow the get_/search_ convention, but the pattern is still readable and predictable.
Seven tools is well-scoped for a domain covering ELFA eligibility, childcare search, recommendations, and licensing. Each tool addresses a distinct user need without redundancy or bloat.
The set covers the core workflow: eligibility check, search, details, recommendations, and licensing verification. Minor gaps include no tool for applying for ELFA or managing a CareWait waitlist, but the informational and decision-support surface is largely complete.
DayPlay MCP — verified SF Bay Area places, events & walkable itineraries for AI agents. Free.
California school data for AI agents — scores, profiles, comparisons, feeder paths, UC pipelines.
Search US grants + federal contracts (Grants.gov + SAM.gov) from any LLM.
LLM SEO and Agent Discoverability for B2B SaaS. Pricing, fit assessment, audit requests.
