Stratum Shifts

Update staff

update_staff

DestructiveIdempotent

Use this when the user changes something about one person: name, roles, email, hour limit, pay rate, availability (only the days given change), dates off, or removing them from the team (active false; their past shifts stay). Identify the person by name or staff id. A date off recorded here keeps every later fill from scheduling the person that day; shifts already on that date stay until they are removed.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "person": "<person>"
    },
    "name": "update_staff"
  }
}

Input Schema

Name	Required	Description
`name`	No
`email`	No
`roles`	No	Replaces their roles.
`active`	No	false removes them from the team, true brings them back.
`person`	Yes	Name or staff id.
`hourly_rate`	No	Pay per hour for labor cost; null removes it. Never shown to staff.
`add_time_off`	No
`availability`	No	Per day: "any", "off" or windows like ["07:00-15:00"]. Keys mon to sun, or weekdays / weekends. Days left out mean any time.
`workplace_id`	No	Workplace id. Omit to use the first workplace.
`remove_time_off`	No
`new_personal_link`	No	Replace this person's own link, if it was lost or shared; the old one stops working. Team and week links seen on it stay valid until reset_team_link.
`max_hours_per_week`	No	null removes the limit.

Output Schema

Name	Required	Description	Default
`person`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 29, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already flag destructiveHint=true and idempotentHint=true, but the description goes well beyond them: availability is a partial merge ('only the days given change'), deactivation preserves past shifts, a date off blocks future fills yet leaves existing shifts, and a new personal link invalidates the old one while team/week links survive. These are exactly the mutation side-effects an agent needs before writing.

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 the usage trigger, then a dense field enumeration, then consequences. Every clause carries information, though the final sentence about date off is syntactically tangled and could be split for readability.

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?

With 12 parameters, nested availability, an output schema, and destructive annotations, this is the right amount of description: it explains the non-obvious merge/destructive behaviors and identity resolution, and correctly leaves field formats and return values to the schema.

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 67% across 12 parameters, so description must add value — and it does: it clarifies partial-update semantics for availability, the effect of active=false, the scheduling consequence of add_time_off, and that 'person' accepts a name or staff id. Remaining gaps (add_time_off/remove_time_off date format, workplace_id default) are covered by the schema itself.

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 ('changes something about one person') and enumerates the exact updatable fields — name, roles, email, hour limit, pay rate, availability, dates off, deactivation. The phrase 'one person' plus 'removing them from the team' clearly separates it from add_staff without needing to name the sibling.

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?

'Use this when the user changes something about one person' gives a concrete trigger condition, and the field list implies the scope of edit operations. It does not explicitly exclude alternatives (e.g. use edit_shifts for shift changes, add_staff for new people), so the agent must infer routing.

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?