Geo-Parity

Team calendar: shared working days and hours across countries

plan_team_calendar

Read-onlyIdempotent

When a distributed team can actually all work. Joins the two halves no free tool puts together: the weekdays on which NOBODY is on a public holiday (the engine behind compare_public_holidays) and the daily working-hour overlap across the members' time zones (the engine behind find_meeting_slot), evaluated on 15 January and 15 July so daylight-saving asymmetry is visible, and multiplied into conservative shared working hours per year. Members are ISO alpha-2 country codes; each country is placed in the time zone of its representative city, and countries spanning several zones (US, CA, BR, MX, AU, ID) are flagged multiZone — append @IANA/Zone to override (e.g. US@America/Chicago). Covers the 41-country spine EXCEPT India, Thailand, Malaysia, the UAE and Saudi Arabia, which have no published holiday calendar and return NO_DATA naming them rather than a calendar with no holidays. Working-hour windows are a stated assumption (09:00-18:00 local unless given), not a measurement; annual leave is not modelled.

Input Schema

Name	Required	Description
`end`	No	Default local working-window end, minutes from midnight (default 1080 = 18:00).
`year`	No	Calendar year for the holiday calendar. Defaults to the first year in the dataset.
`hours`	No	Per-member `start-end` overrides, semicolon-separated and aligned with `members`; leave a slot empty to keep the default (e.g. "540-1080;;420-720").
`start`	No	Default local working-window start for every member, minutes from midnight (default 540 = 09:00).
`members`	Yes	Comma-separated ISO alpha-2 codes, two or more, each optionally `CC@IANA/Zone` (e.g. "GB,JP,US@America/Chicago").

Output Schema

Name	Required	Description	Default
`ok`	No
`days`	No
`year`	No
`hours`	No
`caveats`	No
`members`	No
`attribution`	No
`sharedWorkingHoursPerYear`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 1, 2026
- addedInput schema / examples
```
Added value: +[
+  {
+    "members": "GB,DE,US"
+  }
+]
```
AddedSep 4, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Annotations already declare read-only/idempotent/non-destructive, and the description adds substantial behavior beyond them: evaluation on 15 Jan and 15 Jul to expose DST asymmetry, multiZone flagging for US/CA/BR/MX/AU/ID, the @IANA/Zone override syntax, the NO_DATA sentinel instead of an empty calendar, and the explicit admission that working hours are an assumption and annual leave is unmodeled.

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

Conciseness3/5

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

The scoping and coverage facts are front-loaded well, but the opening ('the two halves no free tool puts together') is rhetorical filler and the single sprawling sentence bundles overriding, coverage exclusions and assumptions together. Much earns its place, yet trimming would improve scannability.

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 an output schema present, return-value detail is not required, yet the description still explains the NO_DATA sentinel and the multiZone flag. Combined with the stated default working window and leave-modeling caveat, an agent has what it needs; only explicit sibling routing is absent.

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 coverage is 100%, so the schema already documents members, start, end, hours and year including the CC@IANA/Zone form. The description reinforces the override syntax and default-window assumption, but adds no parameter detail the schema lacks — baseline 3 is appropriate.

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 composite purpose: joins the no-holiday weekday calculation (behind compare_public_holidays) with time-zone working-hour overlap (behind find_meeting_slot), multiplied into shared annual hours. It explicitly positions itself against two named siblings so an agent can tell it apart without opening schemas.

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?

It names the two sibling engines it subsumes and states hard coverage limits (41-country spine minus India, Thailand, Malaysia, UAE, Saudi Arabia, which return NO_DATA). What is missing is an explicit 'prefer this over compare_public_holidays when...' routing rule, but the context is clear.

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

All Geo-Parity 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?