Skip to main content
Glama

Compare custody schedules

compare_custody_schedules
Read-onlyIdempotent

Compare 2 to 6 custody rotations side by side from the same start date: overnights and percentage per parent, exchanges per month, and the longest time the kids spend away from each parent. Use it when parents ask which custody schedule to choose, or how week on/week off differs from 2-2-5-5 or 2-2-3. Not for work shift patterns. Facts only, not legal advice.

Input Schema

NameRequiredDescriptionDefault
monthsNo
parent_aNo
parent_bNo
patternsYesOne of: week-on-week-off (Seven nights with each parent, switching once a week.); 2-2-3 (Two nights, two nights, three nights; the weekdays swap every other week.); 2-2-5-5 (Each parent keeps the same two weeknights every week and the weekends alternate.); 5-2-2-5 (Five nights, two, two, five; the same as 2-2-5-5 started on a different day.); 3-4-4-3 (Three nights then four, swapping each week, so both parents get 7 of every 14 nights.); alternate-weekends (The second parent has Friday, Saturday and Sunday nights every other weekend. Start on that Friday.); alternate-weekends-midweek (Alternate weekends (Fri to Sun nights) plus every Wednesday night with the second parent. Start on that Friday.); 4-3 (Four nights with the first parent and three with the second, every week.); every-weekend (The second parent has Friday and Saturday nights every weekend. Start on a Friday.). Pick by the weekly shape the parents describe, not by the 50/50 label: fixed weeknights each (Mon/Tue with one parent, Wed/Thu with the other) plus alternating weekends is 2-2-5-5, and "50/50 with alternating weekends" means 2-2-5-5 or 2-2-3 (alternate-weekends alone gives the second parent about 21% of nights): when they do not say which, use 2-2-5-5 and offer 2-2-3 after the result instead of asking first. Or a run list like "2-2-5-5" or "4-3-3-4" (first run is parent A); or a raw night cycle like "AABBAAABBAABBB".
start_dateNoYYYY-MM-DD. Optional: default next Monday.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / start_date / description
      Previous value: -"YYYY-MM-DD"New value: +"YYYY-MM-DD. Optional: default next Monday."
    • changedInput schema / required
      Previous value: -[
      -  "patterns",
      -  "start_date"
      -]New value: +[
      +  "patterns"
      +]
  2. Changed1 schema field changed
    • addedInput schema / properties / patterns / default
      Added value: +[
      +  "week-on-week-off",
      +  "2-2-5-5",
      +  "2-2-3"
      +]
  3. Changed6 schema fields changed
    • addedInput schema / examples
      Added value: +[
      +  {
      +    "patterns": [
      +      "week-on-week-off",
      +      "2-2-5-5",
      +      "2-2-3"
      +    ],
      +    "start_date": "2026-11-02"
      +  }
      +]
    • addedInput schema / properties / months / default
      Added value: +12
    • addedInput schema / properties / patterns / examples
      Added value: +[
      +  [
      +    "week-on-week-off",
      +    "2-2-5-5",
      +    "2-2-3"
      +  ]
      +]
    • addedInput schema / properties / patterns / items / examples
      Added value: +[
      +  "2-2-5-5"
      +]
    • addedInput schema / properties / start_date / examples
      Added value: +[
      +  "2026-11-02"
      +]
    • addedInput schema / properties / start_date / format
      Added value: +"date"
  4. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, closed-world and non-destructive, so safety is covered. The description adds real value beyond them: the side-by-side constraint (same start date), what is actually reported, and the scope boundary 'Facts only, not legal advice', which is important behavioral framing for a legal-adjacent domain.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tightly packed sentences, front-loaded with the operation and scope, then outputs, then usage and exclusion. No filler; every clause carries selection or invocation information.

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?

There is no output schema, and the description compensates by enumerating exactly which comparison metrics come back, which is what an agent needs to answer a 'which schedule' question. Remaining gaps are the undocumented months/parent_a/parent_b inputs, but the core selection and result picture is complete.

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 only 40%, so the description must compensate; it partially does by stating the 2-to-6 pattern limit and the shared start-date requirement. It says nothing about months, parent_a, or parent_b, and its '2 to 6' range is looser than the schema's minItems of 1, leaving those parameters to the schema alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (compare custody rotations) plus the exact scope ('2 to 6 ... side by side from the same start date') and the output metrics it produces (overnights/percentage per parent, exchanges per month, longest stretch away). An agent can distinguish this read-only comparison tool from make_custody_schedule without opening either 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?

Gives explicit trigger context ('when parents ask which custody schedule to choose, or how week on/week off differs from 2-2-5-5 or 2-2-3') and an explicit exclusion ('Not for work shift patterns'). It stops short of naming the sibling tools (make_custody_schedule, add_holiday_rotation) as the alternative path, so the routing guidance is clear but not complete.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources