swap

Shift Swap Request

You are helping the user offload one of their on-call shifts to someone else. This is a write action: you must show the proposed change and get explicit user confirmation before calling mcp__rootly__createOverrideShift.

Workflow

1. Identify the user

Call mcp__rootly__getCurrentUser. Capture user_id.

2. List the user's shifts

Call mcp__rootly__listShifts (or list_shifts) scoped to:

• The current user
• Next 14 days

If the MCP doesn't expose user-level filtering, call the broader listShifts and filter client-side by user_id.

3. Pick the target shift

• If $ARGUMENTS is empty: show the next 5 shifts and ask "Which shift do you want covered?"
• If $ARGUMENTS is next: pick the soonest upcoming shift.
• If $ARGUMENTS is a date or shift identifier: try to match.

If no match, list options and ask.

4. Find candidate coverers

For the shift's schedule and time window:

1. Call mcp__rootly__create_override_recommendation if it accepts the shift parameters — this is the cleanest path; it returns suggested coverers.
2. Otherwise, fall back to mcp__rootly__check_responder_availability against the relevant team/schedule and propose users with available=true and no conflicting shifts.
3. Present up to 3 candidates with reasoning (workload, recent shifts, conflicts).

If no candidates are available, surface that and stop.

5. Show the proposal

**Proposed shift swap:**
- **Shift**: [Schedule name] [start] → [end] ([duration])
- **Currently assigned**: you ([your name])
- **Proposed coverer**: [candidate name]
- **Why**: [reason — e.g. "no shifts this week, on team rotation"]

**Alternatives**:
- [other candidate] — [reason]
- [other candidate] — [reason]

Confirm to create the override? (yes / no / pick another)

6. Wait for confirmation

• yes → call mcp__rootly__createOverrideShift with this shape:

{
  "schedule_id": "[schedule_id]",
  "data": {
    "type": "shifts",
    "attributes": {
      "starts_at": "[shift start ISO8601]",
      "ends_at": "[shift end ISO8601]",
      "user_id": [coverer user id]
    }
  }
}

Echo the resulting override ID and a confirmation line.

• pick another or naming a different candidate → revise the proposal and re-confirm. Do not execute on the first reply if the user is changing the candidate.
• no or any other answer → acknowledge and stop. Do not call the create tool.

7. After the override is created

Output:

✅ Override created.
- ID: [uuid]
- Coverer: [name]
- Window: [start] → [end]

Recommended next steps:
- Notify the coverer in Slack / your team channel.
- The original on-call schedule will route alerts to the coverer for this window.

8. Guidelines

• Never call createOverrideShift without confirmation. The "yes" must come from the user, not be inferred.
• If create_override_recommendation is unavailable, lean on check_responder_availability rather than guessing. Don't propose a coverer you can't verify is available.
• If the user's shift is in the past or already started, refuse with a helpful message — overrides for the present moment are usually a different operation.
• Show timezone explicitly in the proposal. Ambiguous times cause mistakes.