divux

Kids: recalls for baby and child gear

check_kids

Read-only

Returns official recall notices for up to 6 baby or child items in one call: cribs, sleepers, strollers, high chairs, toys, furniture (CPSC), infant formula and baby food (FDA), and car seats. Each item comes back with any recalls, what the notice says to do (stop using, refund, repair kit) and a status. An empty result means no notice was found. Car seats are not searched by name, so they come back as 'check model' with the official recall and rating pages. Safe-sleep and furniture tip-over guidance is included only when the items or the child's age match. A single car that is not a car seat, and a product that is not baby or child gear, are outside this list. Applies to questions about whether baby or child items have recall notices. Results report what the official sources say and are not a safety assessment. Not medical 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": {
      "items": "<items>"
    },
    "name": "check_kids"
  }
}

Input Schema

Name	Required	Description
`ages`	No	The children's ages, e.g. 'newborn, 3 years'; used only to decide whether safe-sleep guidance applies
`items`	Yes	Up to 6 things, brand plus product, one per entry: 'Fisher-Price Rock n Play', 'Similac formula', 'IKEA Malm dresser', 'Graco 4Ever car seat'
`country`	No	Country whose notices are searched: United States (default), United Kingdom, Canada or an EU/EEA country

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 1, 2026

changedInput schema / properties / country / description

Previous value: -"Where the family lives: United States (default), United Kingdom, Canada or an EU/EEA country"New value: +"Country whose notices are searched: United States (default), United Kingdom, Canada or an EU/EEA country"

AddedOct 28, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare read-only/open-world/no-destruct, so the bar is lower, yet the description still discloses meaningful behavior: empty results mean no notice was found, car seats return a 'check model' status with official pages instead of a name search, and safe-sleep/tip-over guidance only appears when items or child age match. It also correctly frames the output as sourced notices rather than a safety assessment.

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?

Purpose and scope are front-loaded in the first clause, and every sentence carries information an agent needs (empty-result semantics, car-seat behavior, conditional guidance, disclaimers). It is a single dense paragraph with repeated framing about coverage limits that could be tightened slightly, but there is no filler.

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

Completeness5/5

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

With three parameters, no output schema, and open-world retrieval, the description covers the return shape (per-item recalls, recommended action, status), the empty case, the car-seat special case, and the non-medical-advice caveat. An agent has everything needed to decide and to interpret the result without an output schema.

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

Parameters4/5

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

Schema description coverage is 100%, so the baseline is 3, but the description adds real meaning: the 6-item ceiling, that each entry is brand-plus-product, and that a child's age gates whether safe-sleep guidance is returned (explaining why 'ages' exists). The 'country' parameter's effect is only implied by the CPSC/FDA sourcing mention rather than stated directly.

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?

Starts with a specific verb and resource ('Returns official recall notices') and then enumerates the exact product classes covered along with their source agencies (CPSC, FDA). Scope limits ('up to 6 baby or child items', 'car seats are not searched by name') let an agent distinguish it from siblings like check_car or check_food without opening any schema.

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

Usage Guidelines4/5

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

States the triggering question type ('Applies to questions about whether baby or child items have recall notices') and gives explicit exclusions: a single non-car-seat vehicle and non-baby/child products are out of scope. It does not name the sibling tools that should handle those excluded cases, so routing to check_car or check_food is left implicit rather than spelled out.

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

All divux 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?