Stratum Shifts

Set up workplace

set_up_workplace

DestructiveIdempotent

Use this when the user describes their workplace or changes its rules: name, timezone, which day weeks start, minimum rest between shifts, shifts per person per day, the shifts each day needs (shifts_needed), the pay currency and overtime thresholds. shifts_needed replaces the whole existing pattern. Set new_workplace to add a second location. It does not add or change people.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "set_up_workplace"
  }
}

Input Schema

Name	Required	Description
`name`	No
`currency`	No	Three-letter currency code for pay, such as USD, GBP, EUR, CAD or GYD.
`timezone`	No	IANA timezone such as America/New_York, Europe/London or America/Guyana.
`workplace_id`	No	Workplace id. Omit to use the first workplace.
`new_workplace`	No	Create an additional workplace instead of changing the current one.
`shifts_needed`	No	The full weekly coverage pattern. Replaces the existing pattern.
`min_rest_hours`	No	Minimum hours off between two shifts for one person. Default 8.
`week_starts_on`	No
`reset_team_link`	No	Make a new team link and stop the old one, for example after it was shared too widely.
`max_shifts_per_day`	No	Most shifts one person may work in a day. Default 1.
`overtime_pay_multiplier`	No	Overtime pay multiplier. Default 1.5.
`overtime_after_hours_per_day`	No	Hours in a day after which time is overtime, e.g. 8. null stops tracking it.
`overtime_after_hours_per_week`	No	Hours in a week after which time is overtime, e.g. 40. null stops tracking it.

Output Schema

Name	Required	Description	Default
`teamLink`	Yes
`workplace`	Yes
`shiftsNeeded`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 29, 2026

TDQS

A3.9/5.0

Behavior3/5

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

Adds real value beyond the annotations by disclosing that shifts_needed replaces the entire existing weekly pattern, which is exactly the consequence behind destructiveHint=true. However it does not cover the other mutation surfaces — reset_team_link invalidating an existing link, the partial-update behaviour of omitted optional fields, or the defaults applied when a field is left out.

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?

One compact paragraph that front-loads the trigger condition and then the important mutation caveat, with no filler. Density is high but the sentence is long and packs many unrelated settings into a single list, slightly slowing scanning.

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?

For a 13-parameter configuration tool with an output schema and strong annotations, the description covers the primary use case, the destructive replace semantics, and scope boundaries. The gaps — reset_team_link, partial-update behaviour and default values — are recoverable from the schema, so nothing is outright missing for correct invocation.

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 85%, so parameters are already well documented; the description mostly restates what is in the schema (shifts_needed replaces, new_workplace adds a location). It adds no guidance on the parameters that lack or lightly carry schema text, such as workplace_id omission semantics, week_starts_on, reset_team_link, or the interaction between the overtime fields.

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 (set up / change the rules of) plus the resource (workplace) and enumerates the concrete settings covered: name, timezone, week start, rest, shifts per day, shifts_needed, currency and overtime thresholds. It also draws an explicit boundary against the staffing siblings by saying it does not add or change people, so an agent can separate it from add_staff/update_staff.

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 a clear trigger ('when the user describes their workplace or changes its rules') and two situational rules: use new_workplace for a second location, and this tool never touches people. It stops short of naming the alternate tool to use for people updates, so the routing is implied rather than explicit.

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

All Stratum Shifts 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?