Rotawise Shift Scheduler

Check a shift schedule

check_schedule

Read-onlyIdempotent

Use this when the user already has a work schedule and wants it checked against scheduling rules: "check this schedule", "does anyone have a clopening", "is anyone over 40 hours", "fix this schedule, Sam cannot work Mondays". Takes the shifts with the people on them (typed, or an attached schedule CSV/XLSX grid or list) plus optional staff rules (roles, max hours, unavailable days) and reports each problem it finds: overlapping or double-booked shifts, less rest than the rule between shifts, too many shifts per day or days in a row, over max hours or overtime, wrong role, unavailable times, and shifts below headcount. Returns hours per person and a PDF, Excel and per-employee calendar files of the checked schedule. Does not change the schedule itself (generate_shift_schedule builds a corrected one) and does not give legal advice on scheduling laws.

Input Schema

Name	Required	Description
`staff`	No	Optional staff rules to check against (roles, max hours, unavailable days), same format as generate_shift_schedule, e.g. [{"name":"Sam","unavailable":["Mon"]}].
`time_zone`	No	The business's time zone, IANA or US name, e.g. "America/Chicago", "Pacific". Default America/New_York. Used for daylight-saving weeks and calendar files.
`week_start`	No	First day of the week to schedule, e.g. "2026-10-05". Default: next Monday. Dates pin calendar files and daylight-saving weeks to real hours.
`assignments`	No	The schedule to check, one item per shift with its people, e.g. [{"day":"Fri","start":"16:00","end":"23:00","staff":["Sam"]},{"day":"Sat","start":"07:00","end":"15:00","staff":["Sam"]}].
`business_name`	No	Optional name printed on the PDF, e.g. "Blue Door Cafe".
`schedule_file`	No	Optional existing schedule the user attached (CSV or .xlsx): a grid with a Name column and day columns (Mon..Sun) holding "07:00-15:00 cook" or "off", or a list with Employee, Day, Start, End, Role columns, e.g. week41.xlsx.
`allow_overtime`	No	false (default): nobody is scheduled past overtime_after_hours. true: overtime is allowed when needed for coverage, kept as low as possible, and flagged.
`min_rest_hours`	No	Minimum hours off between two shifts of the same person (the "clopening" rule), default 10, e.g. 8 or 11. 0 only blocks overlaps.
`max_shifts_per_day`	No	Default shifts per person per day, default 1. Use 2 to allow split shifts (same-day shifts need no rest gap, only no overlap).
`max_consecutive_days`	No	Most days in a row anyone may work in this week, default 6, e.g. 5.
`overtime_after_hours`	No	Weekly hours after which time counts as overtime, default 40 (US federal FLSA workweek), e.g. 40. 0 turns overtime tracking off.

Output Schema

Name	Required	Description	Default
`week`	Yes
`notes`	Yes
`rules`	Yes
`staff`	Yes
`valid`	Yes
`problems`	Yes
`downloads`	Yes
`assumptions`	Yes
`open_shifts`	Yes
`problem_count`	Yes
`problems_by_rule`	Yes
`open_shifts_not_shown`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 22, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Beyond the safe annotations, the description details the exact checks performed (overlapping, rest, max hours), the return types (PDF, Excel, calendars), and crucial behavioral constraints (no legal advice, no mutation). This provides exhaustive context on the tool's operational limits.

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?

The definition is quite lengthy, which detract from absolute conciseness. However, every sentence serves a purpose, and the structure efficiently organizes functional requirements and limitations without any wasted language.

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?

Given the complexity and the high parameter count, the definition is highly complete. It covers input formats, all key functional logic, output formats, and operational boundaries, leaving no major functional gap for an agent.

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

Parameters5/5

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

While the schema is 100% covered, the description adds vital semantic context. It explains input variations, such as that the staff data can be typed, or supplied via a CSV/XLSX grid or list. It also provides functional definitions for complex rules like 'clopening'.

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?

The tool's purpose is perfectly clear: it checks a schedule against scheduling rules. Furthermore, it distinguishes itself explicitly from the sibling tool, generate_shift_schedule, by stating it 'Does not change the schedule itself'.

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?

The description provides clear use cases and examples ('clopening', 'over 40 hours'). It effectively guides the user by contrasting its function (checking) with the function of its sibling tool (generating/fixing).

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

All Rotawise Shift Scheduler 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?