Employee scheduling, staffing feasibility, localized demos, schedule reports and CSV export.
Scored across 8 tools
Each of the eight tools targets a distinct stage of a scheduling workflow (examples → validate → feasibility → generate → report → export, plus health and demo creation). The descriptions explicitly disambiguate the two closest pairs (validate_project vs check_feasibility for structure vs schedulability, and create_demo_project vs generate_schedule). No two tools appear to do the same thing.
All tools share the 'rotase_' prefix and snake_case, and most follow a verb_noun pattern (check_feasibility, create_demo_project, export_csv, generate_schedule, validate_project). Three tools break the verb_noun pattern by being noun-only (examples, health, schedule_report), which is a minor but noticeable deviation.
Eight tools is well-scoped for a stateless scheduling service covering the full preview workflow from template retrieval through export and diagnostics. No tool feels redundant or gratuitous.
The surface covers the end-to-end flow: examples, validation, feasibility, generation, reporting, CSV export, health, and demo scaffolding. Gaps are minor (e.g. no alternate export formats or persistent project save/update), but these are consistent with the server's stateless, non-persisting design rather than clear omissions.
Check whether a complete Rotase project can satisfy opening hours, staffing requirements, availability, rest rules and work-hour limits. Use after rotase_validate_project and before generation when the user asks whether a schedule is possible. This operation is read-only and does not save or modify the project.
| Name | Required | Description | Default |
|---|---|---|---|
| store | Yes | ||
| project | Yes | ||
| employees | Yes | ||
| schedules | No | ||
| preferences | No | ||
| availability | No | ||
| schemaVersion | No | ||
| monthlyTargets | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds value beyond that by specifying the constraint categories checked and reaffirming 'does not save or modify the project.' It stops short of describing what a positive/negative result looks like, but the output schema carries that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with the resource and constraint scope, followed by placement guidance and safety. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need no explanation, and the description fully covers purpose, timing and safety for this complex tool. The remaining gap is parameter guidance, which the external schema partially covers via its top-level description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Property-level schema coverage is 0%, so the description must compensate and largely does not — it only says a 'complete Rotase project' is needed, without explaining store, employees, schedules, preferences, availability, monthlyTargets or schemaVersion. The schema's top-level object description partially rescues this by naming required sections, but the tool description itself adds almost nothing about the 8 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (check) and resource (schedule feasibility) and enumerates the exact constraints evaluated: opening hours, staffing, availability, rest rules and work-hour limits. This clearly distinguishes it from siblings like rotase_generate_schedule, which produces a schedule rather than testing whether one is possible.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit sequencing ('after rotase_validate_project and before generation') and the triggering user intent ('whether a schedule is possible'), naming both adjacent siblings. An agent can place this tool correctly in the workflow without inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a localized demonstration project using the same project-creation operation as the Rotase API. The server chooses the current period in the requested timezone, loads the localized demo names and company name, applies the selected country calendar and can generate an initial schedule. The result is returned in the response; nothing is saved on the server or in a browser.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | ||
| region | No | Optional region code supported by the selected country. | |
| country | No | ISO country code, for example PL, DE, GB or US. | |
| language | No | Demo language code, for example en, pl, de, fr or es. | |
| timezone | No | IANA timezone, for example Europe/Warsaw. | |
| closeOnHolidays | No |
| Name | Required | Description |
|---|---|---|
| project | No | |
| optimization | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, but the description adds the crucial non-obvious trait that nothing is persisted on the server or in a browser and the result is returned inline. It also discloses server-side behavior (current period selection, localized name/company loading, country calendar application), which the annotations cannot convey. It does not cover auth requirements or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three front-loaded sentences that lead with the action and then the behavioral consequences; no filler or restatement of the name. Slightly dense in the second sentence but each clause carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return structure need not be described, and the description correctly focuses on side effects and generation behavior. It is close to complete for a demo-creation tool, with only secondary details (permissions, invalid country/region handling) absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, so the schema already documents country, language, timezone and region examples. The description usefully ties behavior to parameters (timezone drives current period, language/country drive localized names, country drives the calendar), but the 'kind' enum (DEMO/EMPTY) is never explained, leaving a real gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Create a localized demonstration project') and notes it mirrors the Rotase API project-creation operation, which is more precise than the title alone. It does not, however, contrast itself with siblings such as rotase_validate_project or rotase_generate_schedule, which an agent must infer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use or when-not-to-use guidance, and no sibling tool is named as an alternative. The mention that it 'can generate an initial schedule' hints at a relationship with rotase_generate_schedule but stops short of telling the agent which to pick.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read an example store, employees and complete project payload. Defaults to English labels; pass a supported language code to localize names. Call this when the project structure or field names are unknown. The returned project can be copied and edited before validation. This operation is read-only and does not access a user browser or saved project.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No |
| Name | Required | Description |
|---|---|---|
| store | No | |
| project | No | |
| employees | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds value beyond that by noting it 'does not access a user browser or saved project' and that the payload is copyable/editable, which is genuinely useful context for an agent planning next steps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, front-loaded with what is read and defaulted to English, then the usage condition. Nothing is padded, though the final sentence partially restates the readOnly annotation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need not be spelled out, and annotations cover safety. The description supplies the trigger condition, default behavior, and localization semantics, leaving little an agent would need to infer for a single optional param.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry the meaning of 'language'. It does so well: 'Defaults to English labels; pass a supported language code to localize names' explains both the default and the effect. It doesn't enumerate supported codes, but the schema's enum covers that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb+resource ('Read an example store, employees and complete project payload'), making clear this returns sample data rather than performing an operation. It does not explicitly distinguish itself from the closest sibling, rotase_create_demo_project, which also deals with example/demo project material.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Call this when the project structure or field names are unknown' gives a concrete triggering condition, and 'The returned project can be copied and edited before validation' clarifies the follow-on workflow. It stops short of naming alternatives or stating when-not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export a generated monthly schedule as spreadsheet-compatible CSV. Pass the complete project object and either provide the generated schedule as the top-level "schedule" property or put it in the project schedules array. The response contains the CSV text; nothing is saved on the server.
| Name | Required | Description | Default |
|---|---|---|---|
| store | Yes | ||
| project | Yes | ||
| employees | Yes | ||
| schedules | No | ||
| preferences | No | ||
| availability | No | ||
| schemaVersion | No | ||
| monthlyTargets | No |
| Name | Required | Description |
|---|---|---|
| csv | No | |
| filename | No | |
| contentType | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context beyond the annotations: the CSV is returned in the response text and "nothing is saved on the server," which tells the agent this is a stateless pure-compute call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the purpose before the invocation details, and every sentence carries information (what, how to call, what comes back). Minor redundancy between "generated monthly schedule" and "the generated schedule," but nothing is padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter, nested-object tool, the description plus the rich schema-level object description (which names the required project/store/employees sections) covers what an agent needs to construct a call, and an output schema exists so return values need not be spelled out. The residual gap is the "schedule" vs "schedules" ambiguity and the unexplained auxiliary parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Property-level schema coverage is 0%, so the description must compensate, and it only covers the project and schedule placement. It says nothing about store, employees, preferences, availability, schemaVersion, or monthlyTargets. There is also a naming ambiguity: it references a top-level "schedule" property while the schema defines "schedules", which could mislead an agent about where to put the data.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (export), resource (monthly schedule) and output format (spreadsheet-compatible CSV), which is clear enough to distinguish it from rotase_generate_schedule and rotase_schedule_report. It does not explicitly name or contrast with rotase_schedule_report, which also produces schedule output, so differentiation is inferred rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase "a generated monthly schedule" implies the precondition that a schedule must already exist (i.e., run rotase_generate_schedule first), and it explains how to supply that schedule to this call. It stops short of naming alternative tools or stating explicit when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a monthly employee schedule from a complete Rotase project payload. Use rotase_examples to obtain a template, then rotase_validate_project first. The operation calculates and returns a schedule; it does not save a project, modify browser storage or create an account. Explain returned violations or shortages instead of assuming that every project is schedulable.
| Name | Required | Description | Default |
|---|---|---|---|
| store | Yes | ||
| project | Yes | ||
| employees | Yes | ||
| schedules | No | ||
| preferences | No | ||
| availability | No | ||
| schemaVersion | No | ||
| monthlyTargets | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered; the description still adds value by spelling out the negative side effects (no project save, no browser-storage mutation, no account creation) and by warning that output may contain violations or shortages. It stops short of describing determinism, cost, or pagination, so it is strong but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each doing distinct work: purpose, prerequisite workflow, and side-effect/output caveats, with the core action front-loaded. Slightly dense in the final warning sentence, but no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex, nested-input tool with an output schema (so return values need not be explained), the description covers purpose, prerequisites, and side-effect boundaries. The missing piece is any orientation to the payload's constituent parts, which matters given eight undocumented parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With eight parameters, three required, nested objects, and 0% per-parameter schema coverage, the description only gestures at 'a complete Rotase project payload' and never explains store, employees, schedules, preferences, availability, schemaVersion, or monthlyTargets. The root object description in the schema carries the required/optional distinction, but the tool description itself contributes essentially no parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Generate a monthly employee schedule') plus the required input ('complete Rotase project payload'), so the agent knows exactly what the tool produces. It also implicitly separates itself from rotase_validate_project and rotase_examples by casting them as prerequisite steps rather than alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit ordered workflow ('Use rotase_examples to obtain a template, then rotase_validate_project first') and states when-not-to-expect-something ('does not save a project'), which is exactly the routing guidance an agent needs. Nothing about sequencing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only check that the Rotase scheduling service is available. Use this when connectivity or service availability is uncertain. It does not require a project and does not change data.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| status | No | |
| service | No | |
| phpVersion | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds genuinely useful context beyond that: no project scope is required and no data is changed, which shapes how the agent should invoke it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with what it does, followed by when to use it and the side-effect-free guarantee. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists and no parameters are required, so the description need not explain return values. It covers purpose, trigger, and safety, which is everything needed for a zero-arg health check.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly reinforces that no project argument is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: a read-only check of the Rotase scheduling service's availability. It is clearly distinguishable from siblings like rotase_check_feasibility (project feasibility) and rotase_generate_schedule (schedule creation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit trigger: 'Use this when connectivity or service availability is uncertain.' That is a clear condition for reaching for this tool, though it names no alternative or when-not-to-use case against the other check/report siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate per-store and per-employee statistics for a generated monthly schedule. Pass the complete project object and either provide the generated schedule as the top-level "schedule" property or put it in the project schedules array. This operation is read-only and does not save data.
| Name | Required | Description | Default |
|---|---|---|---|
| store | Yes | ||
| project | Yes | ||
| employees | Yes | ||
| schedules | No | ||
| preferences | No | ||
| availability | No | ||
| schemaVersion | No | ||
| monthlyTargets | No |
| Name | Required | Description |
|---|---|---|
| store | No | |
| employees | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the description's 'This operation is read-only and does not save data' largely restates structured data. The added nuance that it only computes and persists nothing is mildly useful, but there is no detail on cost, size limits, or failure behavior for a large nested project payload.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact sentences with the purpose front-loaded, followed by the payload convention and the read-only note. No filler, though the awkward 'either...or' sentence about the schedule could be tighter and more accurate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described. For an 8-parameter, deeply nested tool with no per-parameter docs, the description covers only the schedule-placement question and leaves the majority of the payload under-explained; the 'schedule' vs 'schedules' naming mismatch is a real ambiguity an agent could trip on.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Per-parameter schema coverage is 0%, so the description must compensate, and it does partially by explaining how to supply the schedule (as a top-level property or inside the project schedules array). However, it names a 'schedule' property that does not exist in the schema (the schema has 'schedules'), and it says nothing about store, employees, preferences, availability, monthlyTargets or schemaVersion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a concrete verb and resource: 'Calculate per-store and per-employee statistics for a generated monthly schedule.' That is clearly distinct from sibling rotase_generate_schedule (which produces the schedule) and rotase_validate_project. It does not, however, explicitly name any sibling or contrast itself with them, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the operation applies to a 'generated monthly schedule', which suggests rotase_generate_schedule must run first, but this prerequisite is never stated. No guidance is given on when to use this instead of rotase_check_feasibility or rotase_validate_project, and no exclusions are listed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate a complete Rotase project payload without saving or modifying it. Use rotase_examples first if the payload shape is unknown. Call this before feasibility checks or schedule generation. The input is the project object itself, not a wrapper with an additional "project" property.
| Name | Required | Description | Default |
|---|---|---|---|
| store | Yes | ||
| project | Yes | ||
| employees | Yes | ||
| schedules | No | ||
| preferences | No | ||
| availability | No | ||
| schemaVersion | No | ||
| monthlyTargets | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotentHint/non-destructive, so 'without saving or modifying it' largely restates them. The description does add workflow context (validation precedes feasibility and scheduling) that annotations cannot express, which is genuine added value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, front-loaded with purpose, then usage ordering, then the input-shape caveat. No filler and every sentence carries actionable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be documented, and the description covers purpose, precondition, sequencing and envelope shape. It is slightly thin on the semantics of the optional sections, though the input schema's own description partially covers the required vs. optional split.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Per-parameter schema coverage is 0% across 8 params with nested objects, so the description must compensate - and it only partly does, clarifying the top-level payload shape and pointing to rotase_examples as a template. It says nothing about store, employees, schedules, preferences, availability, schemaVersion or monthlyTargets. The claim that the input is 'the project object itself, not a wrapper with an additional "project" property' also sits awkwardly against a schema where 'project' is a required top-level key, which risks confusing an agent about the correct envelope.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb+resource ('Validate a complete Rotase project payload') and immediately scopes it as non-mutating ('without saving or modifying it'). It is readily distinguishable from siblings like rotase_check_feasibility, rotase_generate_schedule and rotase_examples, which are named explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear ordering guidance ('Call this before feasibility checks or schedule generation') and names an alternative for payload discovery ('Use rotase_examples first if the payload shape is unknown'). It lacks an explicit when-not/negative case, so it falls short of the top band.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
rotase_check_feasibilityrotase_create_demo_projectrotase_examplesrotase_export_csvrotase_generate_schedulerotase_healthrotase_schedule_reportrotase_validate_projectGenerate optimized work shift schedules from staffing demand, availability and fairness rules.
Staff shift scheduler: fills the week fairly, flags clashes, finds cover, gives staff one link.
Builds optimal 24/7 staff rosters with a real MILP solver: rest rules, skills, nights, fairness.
Shift rotas, attendance and labour-law checks for Slovak and Czech restaurants and shops
Add one secure layer between your agents and this server.
