BackPR youth program data

Calculate staff needed

calculate_staff_needed

Read-onlyIdempotent

Work out the minimum number of staff a licensed childcare center needs for a group of children in one US state, from that state's staff-to-child ratio for 3-year-olds, 4-year-olds or school-age children. Returns staff needed (children divided by the ratio, rounded up), the ratio, the maximum group size where the state sets one, caveats and backpr.com links. If BackPR couldn't confirm a ratio for that age group, it says so instead of guessing. General information, not legal advice.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "state": "<state>",
      "age_group": "<age_group>",
      "children": "<children>"
    },
    "name": "calculate_staff_needed"
  }
}

Input Schema

Name	Required	Description
`state`	Yes	US state name or 2-letter code, case-insensitive, such as "Texas" or "TX". "DC" and "District of Columbia" also work.
`children`	Yes	Number of children in the group, from 1 to 1000.
`age_group`	Yes	"3_year_olds", "4_year_olds" or "school_age" (children enrolled in school).

Output Schema

Name	Required	Description
`ages`	No	The state's label for this age band
`ratio`	Yes	Children per adult; null if BackPR couldn't confirm it
`state`	Yes
`caveats`	Yes
`checked`	Yes
`cite_as`	Yes
`children`	Yes
`age_group`	Yes
`source_url`	Yes	The ratios section of the state's backpr.com rules page
`state_code`	Yes
`ratio_label`	No	For example "1:15"
`national_url`	No
`staff_needed`	Yes	Minimum staff: children divided by the ratio, rounded up
`calculator_url`	No
`max_group_size`	No
`minimum_groups`	No	Fewest groups the children must be split into under the maximum group size

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 22, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds real behavioral context: the rounding-up rule, the explicit refusal to guess when a ratio cannot be confirmed ('it says so instead of guessing'), and the 'general information, not legal advice' disclaimer.

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?

Two sentences that are front-loaded with the purpose, followed by outputs and the disclaimer. The middle enumeration of return fields (staff needed, ratio, max group size, caveats, links) is somewhat list-heavy and partly redundant with the output schema, but nothing is padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a 3-parameter, read-only tool with an output schema, the description supplies the computation logic, the unconfirmed-ratio fallback and a scope disclaimer, so an agent can call it correctly and interpret results. The only shortfall is usage routing against sibling tools, which the output schema cannot compensate for.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and all three parameters (state, children, age_group) are fully documented with formats, ranges and the enum values. The description restates the age groups but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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 precise verb and resource ('work out the minimum number of staff a licensed childcare center needs') plus the exact input domain (one US state, group of children, ratio for 3-year-olds/4-year-olds/school-age). It is easy to distinguish from siblings like get_state_rules, which returns raw rules rather than a computed headcount.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the framing ('for a group of children in one US state'), so an agent can infer this is the calculator rather than a raw-rules lookup. However, there is no explicit when-to-use statement, no named alternative (e.g., use get_state_rules for the underlying regulation text), and no stated exclusions or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All BackPR youth program data tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?