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 authoritative Model Context Protocol (MCP) server for navigating San Francisco's Department of Early Childhood (DEC) preschool network, Early Learning For All (ELFA) financial subsidies, and real-time CareWait database searches.
Includes a TypeSafe Jev System One decision engine and A/B evaluation matrix comparing deterministic probability scoring against generative LLM judgments (Claude, GPT, Gemini, etc.).
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.
Authoritative 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.
Automated Net Out-of-Pocket Calculation: Automatically calculates family subsidy discounts and estimates true monthly net tuition (Math.max(0, grossTuition - subsidy)).
TypeSafe Jev System One Integration: Leverages TypeSafe's Jev model (@typesafe-ai/sdk) for typed decision primitives (score, choice, noul) to rank options with calibrated confidence rather than hallucinated generative text.
A/B Human Evaluation Tool: Side-by-side comparison matrix of Generative LLM narrative recommendations vs Jev System One probability distributions.
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 |
check_elfa_eligibilityComputes exact ELFA financial assistance tier, monthly discount credits, and co-pay rules given family size, income, and child age.
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, and DEC contract notes.
get_smart_recommendationsAll-in-one recommendation engine: takes budget, language, schedule, and benefit tier, computes net out-of-pocket costs, and returns an affordably ranked shortlist of preschool centers.
compare_llm_vs_jev (alias: compare_gemini_vs_jev)Runs an A/B evaluation benchmark: feeds candidate options and family constraints to both a Generative LLM (narrative reasoning) and TypeSafe Jev System One (probabilistic decision model) to produce a structured human-evaluation comparison matrix.
get_elfa_rates_and_rulesReturns the raw authoritative FY 2026–2027 Department of Early Childhood rate schedules, income ceilings, and regulatory guidelines.
get_state_licensing_recordDirect integration with the California Community Care Licensing Division (CCLD) transparency database: retrieves official inspection histories, capacity, complaint visits, substantiated allegations, Type A/B violations, and licensing conditions by license number.
Rather than relying on free-form LLM guesswork, candidate centers are evaluated through a structured, multi-dimensional decision model:
Hard Requirements (Deterministic Gates):
Legally licensed status (STATUS === 'Licensed').
Facility type matching (dedicated commercial center vs in-home).
Age bracket compatibility (must legally accommodate child's age in months).
Graded Decision Scoring (TypeSafe Jev Primitives):
State Safety & Licensing Record (35%): Evaluated against CCLD Type A citations, Type B deficiencies, and substantiated complaints. A single minor resolved technical finding receives a slight ding rather than an outright disqualification, while centers with serious safety hazards are heavily penalized.
Net Budget Satisfaction (30%): Evaluates net out-of-pocket tuition against the family's strict budget ceiling.
Language Immersion Depth (25%): Scores authentic immersion vs bilingual support vs secondary exposure.
Toddler Development & Diapering (10%): Confirms Title 22 Toddler diaper changing facilities and supportive toilet learning (eliminating programs that demand unrealistic potty training for a 2-year-old).
Composite Verdict: Produces a calibrated recommendation choice (top_tier, strong_alternative, caution_flagged, unsuitable) with continuous confidence scoring.
Node.js >= 20.0.0
git clone https://github.com/your-username/sf-early-learning-mcp.git
cd sf-early-learning-mcp
npm install
npm testopencode.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:
"I have a 2-year-old child and live in San Francisco. Walk me through the Early Learning For All (ELFA) options, check my eligibility, and recommend preschools based on my budget and language preference."
"We have the ELFA Half Tuition Credit for our 2.1-year-old toddler. Can you find licensed preschool centers (not home-based) offering Spanish or Cantonese/Mandarin immersion where our out-of-pocket tuition is under $400/month?"
"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?"
"Run an A/B evaluation comparison between Generative LLMs and TypeSafe Jev System One for top Spanish immersion preschool centers in San Francisco with a target budget of $200/month."
Scenario | Child Age | Voucher Credit | Selected Center | Regular Tuition | Your Net Monthly Cost |
Spanish Immersion (Strict Budget) | 2.1 yo | $1,153 / mo (Half Credit) | Chibi Chan Too (Presidio) | $1,243 / mo | $90 / mo |
Spanish Immersion (Mission Center) | 2.1 yo | $1,153 / mo (Half Credit) | Mission Kids Co-op (Mission) | $1,383 / mo | $230 / mo |
Chinese Immersion (100% Covered) | 2.1 yo | $1,153 / mo (Half Credit) | Kai Ming Rainbow Center | $1,153 / mo | $0 / mo |
Free Tuition Tier (0-110% AMI) | Any | 100% Free | Any ELFA Center | Any | $0 / mo (Co-pays banned) |
Zero Hardcoded Secrets: Uses environment variables (TYPESAFE_API_KEY, optional CAREWAIT_API_KEY).
Dependency Audit: Verified with npm audit (0 vulnerabilities).
Pre-commit Hooks: Enforces automated secret scanning and unit test validation before any commit.
Deterministic Logic: All income brackets and voucher calculations are executed in code, preventing LLM hallucination of financial figures.
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.
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.
Agent-ready NYC public records. Hosted, source-backed civic data organized around durable anchors.
