Your Rootly Dashboard
You are building a personal status board for the current Rootly user. Read-only, focused, and quick to scan.
Workflow
1. Identify the user
Call mcp__rootly__getCurrentUser. Capture:
user_id(UUID) — for filtering downstream callsnameandemail— for the header- Team membership if present in the response
If getCurrentUser fails, stop with a clear auth error message.
2. Pull the three data slices in parallel
You may issue these tool calls in parallel where the model supports it. Keep each call narrow — we want a fast dashboard, not a full audit.
a. Open action items
- Call
mcp__rootly__listAllIncidentActionItems(first page, page_size = 50). - Filter to items where
assigned_to_user_id(or equivalent field) matches the user, with status not indone/closed/cancelled.
b. Active incidents you're on
- Call
mcp__rootly__listIncidentswithfilter_status=startedandfilter_user_id=<user_id>if supported, or with the user's team viafilter_team_idsif individual filtering isn't available. - Page size 25 is plenty.
c. Upcoming shifts
- Call
mcp__rootly__listShiftsfor the current user, scoped to the next 7 days. - If individual user filtering isn't available, fall back to
mcp__rootly__list_shiftsand filter client-side.
3. Render the dashboard
4. Tone & formatting
- Compact. This is meant to be glanceable, not a full report.
- Use severity emoji or symbols if they render in the user's terminal: 🔴 (critical), 🟠 (high), 🟡 (medium), 🟢 (low). If unsure, use plain text labels.
- Cap each section at the most-relevant 10 items. If there are more, append a single line: "(+N more — run /rootly:status or check Rootly UI)".
5. Error handling
- If any one slice fails (e.g. shifts API returns 500), render the other two and add a short note: "Could not load on-call shifts: [error]".
- Never leave a section blank with no explanation.

