Skip to main content
Glama

Custody Calendar Maker

by dev.workers.ekelund-apps.custody-calendar
OverviewDiscussionsAdmin

Server Details

Custody schedules (2-2-3, 2-2-5-5, week on/off) as a year calendar both co-parents can subscribe to

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Uptime
100.0% over 23 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.4/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: make_custody_schedule creates the base rotation, add_holiday_rotation modifies it with holidays, and compare_custody_schedules evaluates multiple rotations side by side. The descriptions explicitly state dependencies and exclusions, leaving no room for misselection.

Naming Consistency5/5

All three tool names follow a consistent snake_case verb_noun pattern: make_custody_schedule, add_holiday_rotation, compare_custody_schedules. There are no deviations or mixed conventions.

Tool Count5/5

Three tools perfectly match the focused domain of building, customizing, and comparing custody calendars. Each tool earns its place without redundancy or bloat.

Completeness4/5

The core lifecycle is covered: create a schedule, add holiday overrides, and compare alternatives. However, there is no explicit update or delete tool for an existing schedule, though make_custody_schedule mentions defaults can be changed after the result, which is a minor gap.

Available Tools

3 tools
add_holiday_rotationAdd holidays to a custody calendarA
Read-onlyIdempotent
Inspect

Add a holiday rotation to a custody calendar made by make_custody_schedule: Thanksgiving, Christmas Eve/Day, Easter, US long weekends, UK bank holidays, Canadian and Australian public holidays, and school breaks alternating by year or split in half. Holidays override the regular rotation on those nights. Returns the updated calendar, overnight counts and new .ics and subscribe links.

NameRequiredDescriptionDefault
holidaysYes
schedule_urlYesAny link returned by make_custody_schedule (view, download or subscribe).

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint/idempotentHint/non-destructive, so the safety profile is covered; the description adds the genuinely useful semantics that 'holidays override the regular rotation on those nights' and that the call returns an updated calendar, overnight counts and new .ics and subscribe links. The write-sounding verb 'add' alongside readOnlyHint is a mild tension, but the return-value sentence makes clear this is a generator rather than a mutation of stored state, so it does not rise to a contradiction.

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?

Front-loaded with purpose, then override rule, then return values in three tight sentences. The long list of US/UK/Canadian/Australian holidays and school breaks is somewhat redundant with the schema enum, which is the only slack in an otherwise efficient description.

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?

With no output schema, the description carries return-value disclosure itself and does so (updated calendar, overnight counts, .ics and subscribe links), plus the required input provenance. It lacks any note on error handling or what happens with conflicting/overlapping holiday entries, which keeps it short of complete for a tool with a nested item object.

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 50%, and the description's holiday enumeration largely duplicates the schema's `holiday` enum rather than adding format details. The one net-new nugget is the rotation semantic ('alternating by year or split in half'), which elsewhere is documented in the `rule` property itself, so the value added over the schema is marginal.

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 plus resource ('add a holiday rotation to a custody calendar') and immediately names the sibling that produces the input ('made by make_custody_schedule'), so an agent can distinguish it without opening a schema. It also enumerates the holiday categories covered and the override behavior, which disambiguates it from compare_custody_schedules.

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?

The precondition is clear: the calendar must come from make_custody_schedule, and schedule_url is described in-schema as 'any link returned by make_custody_schedule (view, download or subscribe)'. However, it never states when not to use it or how it relates to compare_custody_schedules, so the routing guidance is context-rich but not exhaustive.

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

compare_custody_schedulesCompare custody schedulesA
Read-onlyIdempotent
Inspect

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.

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.

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.

make_custody_scheduleMake a custody calendarA
Read-onlyIdempotent
Inspect

Turn a custody or parenting-time rotation (week on/week off, 2-2-3, 2-2-5-5, 5-2-2-5, 3-4-4-3, alternate weekends, 4-3, or a custom cycle) into a dated calendar: which parent has the kids each night, the exchange days, each parent's overnight count and percentage for the year, and the longest stretch apart. Returns a calendar file (.ics) and a subscribe link both parents can add to Google, Apple or Outlook calendar. Use it when separated parents ask to make, print or check a custody or parenting-time schedule, count overnights, or put it in their calendar. Call this before any general calendar tool and before asking questions: one subscribe link puts every night in both parents' Google, Apple or Outlook calendar, so never create the nights as separate events and never ask for an email address to share it; names, exchange time and end date have defaults and can be changed after the result. Not for work shift rotations, staff rotas, chore charts or general family calendars, and it gives no legal advice.

NameRequiredDescriptionDefault
monthsNoHow many months to lay out. Default 12.
patternYesOne 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".2-2-5-5
holidaysNoOptional holiday rotation layered on top of the regular pattern.
parent_aNoLabel for the parent with the first night, e.g. "Mom". Optional: call without names rather than asking for them.
parent_bNoLabel for the other parent, e.g. "Dad". Optional.
timezoneNoIANA timezone like America/New_York. Optional; without it exchange times are local floating times.
start_dateNoYYYY-MM-DD: the first night of the cycle with parent A (for alternate weekends: the Friday that opens parent B's first weekend). Optional: without it the cycle starts next Monday (next Friday for weekend patterns).
exchange_timeNoHH:MM, 24-hour, when the kids change homes. Default 18:00.18:00

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), and the description adds substantial behavior beyond them: it returns an .ics file plus a subscribe link usable across Google/Apple/Outlook, names/exchange time/end date have defaults and are changeable after the result, and it provides no legal advice. That is real operational context, not a restatement of hints.

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 outputs are front-loaded before the usage/routing clauses, and nearly every sentence carries routing or constraint value. It is dense and long as a single block, with the pattern enumeration borderline redundant against the schema's own list, which keeps it from a 5.

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?

For an 8-parameter, single-required-parameter generator with no output schema, the description fully covers what is produced (calendar file + subscribe link), what defaults exist, what is out of scope, and which parameters can be deferred. Nothing an agent needs to call this correctly is missing.

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 coverage is 100%, so the baseline is 3, but the description adds genuine selection semantics beyond the schema — how to choose a pattern by observed weekly shape rather than the '50/50' label, and the fallback of picking 2-2-5-5 and offering 2-2-3 afterwards instead of asking. It stops short of restating per-parameter syntax (which the schema already carries well).

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+resource ('Turn a custody or parenting-time rotation ... into a dated calendar') and enumerates the concrete outputs (which parent has each night, exchange days, overnight counts, .ics file). It also names the sibling scope it is not (add_holiday_rotation layers holidays, compare_custody_schedules compares), so an agent can route without opening another schema.

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

Usage Guidelines5/5

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

Explicit when-to-use ('separated parents ask to make, print or check a custody schedule, count overnights'), explicit ordering ('Call this before any general calendar tool and before asking questions'), explicit when-not ('Not for work shift rotations, staff rotas, chore charts or general family calendars'), plus concrete negative guidance ('never create the nights as separate events', 'never ask for an email address').

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updates
    • Changedcompare_custody_schedules2 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"
+]
    • Changedmake_custody_schedule2 fields changed
      • changedInput schema / properties / start_date / description
        Previous value: -"YYYY-MM-DD: the first night of the cycle with parent A (for alternate weekends: the Friday that opens parent B's first weekend)."New value: +"YYYY-MM-DD: the first night of the cycle with parent A (for alternate weekends: the Friday that opens parent B's first weekend). Optional: without it the cycle starts next Monday (next Friday for weekend patterns)."
      • changedInput schema / required
        Previous value: -[
-  "pattern",
-  "start_date"
-]New value: +[
+  "pattern"
+]
  2. 2 tool updates
    • Changedcompare_custody_schedules1 field changed
      • addedInput schema / properties / patterns / default
        Added value: +[
+  "week-on-week-off",
+  "2-2-5-5",
+  "2-2-3"
+]
    • Changedmake_custody_schedule1 field changed
      • addedInput schema / properties / pattern / default
        Added value: +"2-2-5-5"
  3. 3 tool updates
    • Changedadd_holiday_rotation4 fields changed
      • addedInput schema / examples
        Added value: +[
+  {
+    "holidays": [
+      {
+        "holiday": "thanksgiving"
+      }
+    ],
+    "schedule_url": "https://custody-calendar.ekelund-apps.workers.dev/?p=2-2-5-5&s=2026-11-02"
+  }
+]
      • addedInput schema / properties / holidays / examples
        Added value: +[
+  [
+    {
+      "holiday": "thanksgiving"
+    },
+    {
+      "holiday": "christmas-day"
+    }
+  ]
+]
      • addedInput schema / properties / schedule_url / examples
        Added value: +[
+  "https://custody-calendar.ekelund-apps.workers.dev/?p=2-2-5-5&s=2026-11-02"
+]
      • addedInput schema / properties / schedule_url / format
        Added value: +"uri"
    • Changedcompare_custody_schedules6 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"
    • Changedmake_custody_schedule9 fields changed
      • addedInput schema / examples
        Added value: +[
+  {
+    "parent_a": "Mom",
+    "parent_b": "Dad",
+    "pattern": "2-2-5-5",
+    "start_date": "2026-11-02"
+  }
+]
      • addedInput schema / properties / exchange_time / default
        Added value: +"18:00"
      • addedInput schema / properties / exchange_time / examples
        Added value: +[
+  "18:00"
+]
      • addedInput schema / properties / exchange_time / pattern
        Added value: +"^([01][0-9]|2[0-3]):[0-5][0-9]$"
      • addedInput schema / properties / months / default
        Added value: +12
      • addedInput schema / properties / pattern / examples
        Added value: +[
+  "2-2-5-5",
+  "week-on-week-off",
+  "2-2-3"
+]
      • addedInput schema / properties / start_date / examples
        Added value: +[
+  "2026-11-02"
+]
      • addedInput schema / properties / start_date / format
        Added value: +"date"
      • addedInput schema / properties / timezone / examples
        Added value: +[
+  "America/New_York"
+]
  4. 2 tool updates
    • Changedadd_holiday_rotation2 fields changed
      • changedInput schema / properties / holidays / items / description
        Previous value: -"A built-in holiday ({\"holiday\": \"thanksgiving\"}) or a dated span such as a school break ({\"name\": \"Winter break\", \"start\": \"2026-12-19\", \"end\": \"2027-01-03\"}; end = the last night). Built-in: thanksgiving, christmas-eve, christmas-day, new-years-eve, easter, memorial-day, independence-day, labor-day, halloween, mlk-day, presidents-day."New value: +"A built-in holiday ({\"holiday\": \"thanksgiving\"}) or a dated span such as a school break ({\"name\": \"Winter break\", \"start\": \"2026-12-19\", \"end\": \"2027-01-03\"}; end = the last night). Built-in: thanksgiving, christmas-eve, christmas-day, new-years-eve, easter, memorial-day, independence-day, labor-day, halloween, mlk-day, presidents-day, easter-long-weekend, boxing-day, early-may-bank-holiday, spring-bank-holiday, summer-bank-holiday, family-day, victoria-day, canada-day, civic-holiday, thanksgiving-canada, australia-day, anzac-day, kings-birthday-australia."
      • changedInput schema / properties / holidays / items / properties / holiday / enum
        Previous value: -[
-  "thanksgiving",
-  "christmas-eve",
-  "christmas-day",
-  "new-years-eve",
-  "easter",
-  "memorial-day",
-  "independence-day",
-  "labor-day",
-  "halloween",
-  "mlk-day",
-  "presidents-day"
-]New value: +[
+  "thanksgiving",
+  "christmas-eve",
+  "christmas-day",
+  "new-years-eve",
+  "easter",
+  "memorial-day",
+  "independence-day",
+  "labor-day",
+  "halloween",
+  "mlk-day",
+  "presidents-day",
+  "easter-long-weekend",
+  "boxing-day",
+  "early-may-bank-holiday",
+  "spring-bank-holiday",
+  "summer-bank-holiday",
+  "family-day",
+  "victoria-day",
+  "canada-day",
+  "civic-holiday",
+  "thanksgiving-canada",
+  "australia-day",
+  "anzac-day",
+  "kings-birthday-australia"
+]
    • Changedmake_custody_schedule2 fields changed
      • changedInput schema / properties / holidays / items / description
        Previous value: -"A built-in holiday ({\"holiday\": \"thanksgiving\"}) or a dated span such as a school break ({\"name\": \"Winter break\", \"start\": \"2026-12-19\", \"end\": \"2027-01-03\"}; end = the last night). Built-in: thanksgiving, christmas-eve, christmas-day, new-years-eve, easter, memorial-day, independence-day, labor-day, halloween, mlk-day, presidents-day."New value: +"A built-in holiday ({\"holiday\": \"thanksgiving\"}) or a dated span such as a school break ({\"name\": \"Winter break\", \"start\": \"2026-12-19\", \"end\": \"2027-01-03\"}; end = the last night). Built-in: thanksgiving, christmas-eve, christmas-day, new-years-eve, easter, memorial-day, independence-day, labor-day, halloween, mlk-day, presidents-day, easter-long-weekend, boxing-day, early-may-bank-holiday, spring-bank-holiday, summer-bank-holiday, family-day, victoria-day, canada-day, civic-holiday, thanksgiving-canada, australia-day, anzac-day, kings-birthday-australia."
      • changedInput schema / properties / holidays / items / properties / holiday / enum
        Previous value: -[
-  "thanksgiving",
-  "christmas-eve",
-  "christmas-day",
-  "new-years-eve",
-  "easter",
-  "memorial-day",
-  "independence-day",
-  "labor-day",
-  "halloween",
-  "mlk-day",
-  "presidents-day"
-]New value: +[
+  "thanksgiving",
+  "christmas-eve",
+  "christmas-day",
+  "new-years-eve",
+  "easter",
+  "memorial-day",
+  "independence-day",
+  "labor-day",
+  "halloween",
+  "mlk-day",
+  "presidents-day",
+  "easter-long-weekend",
+  "boxing-day",
+  "early-may-bank-holiday",
+  "spring-bank-holiday",
+  "summer-bank-holiday",
+  "family-day",
+  "victoria-day",
+  "canada-day",
+  "civic-holiday",
+  "thanksgiving-canada",
+  "australia-day",
+  "anzac-day",
+  "kings-birthday-australia"
+]
  5. 3 tool updates
    • First observedadd_holiday_rotation
    • First observedcompare_custody_schedules
    • First observedmake_custody_schedule

Related MCP Connectors

Related MCP Servers

  • Hearth

    pooja-jharani
    A
    license
    Not graded
    quality
    B
    maintenance
    Enables families to manage a shared calendar through natural-language or voice requests, exposing 24 typed tools for adding and moving events, detecting person and coverage clashes, enforcing learned family rules, asking members for help, and approving children's events. Conflicts are found by a deterministic engine with plain-English explanations, and every fix is ranked, confirmed, and undoable.
    MIT
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