--- name: robin-powered-office-attendance-check description: Answer "who is in the office and where do people sit" questions for Robin (Workplace) by looking up people, departments and live building state, and report presence and seating for a person or team without over-sharing personal detail. Read-only. Use when the user asks who is in today, where a colleague or team sits, whether a team is on site, or who is around a floor, or types things like "is Sam in the office", "where does Marketing sit", "who's on Floor 2 right now". --- # Check office attendance and seating This job answers two questions: **who is in the building right now (or at a stated time)**, and **where a person or team sits**. It is a lookup, not a booking. Nothing here changes state, so no approval step is needed, but the answer must still be scoped and proportionate: an office presence report is personal data about other people. ## 1. Pin down the question before calling anything Decide which of these the user means, because each needs different tools: - **A named person:** "Is Sam in today, and where?" - **A team or department:** "Who from Marketing is in this week?" - **A place:** "Who is on Floor 2 right now?" - **Overall occupancy:** "How busy is HQ?" If the name is ambiguous (two Sams, or a first name only), resolve it with `graphql-mcp-server-find-people` and ask which one before reporting anything about them. Do not guess a person's identity and then report their location. Confirm the building or site if the user has several. Presence is per building, so a result from the wrong site is worse than no result. ## 2. Find the people, then their seating Work from identity to location: 1. Find the person or department with `graphql-mcp-server-find-people` or `graphql-mcp-server-get-departments`. For a team, use `graphql-mcp-server-get-department-overview` to get its members rather than searching names one by one. 2. For a person's seat, check `graphql-mcp-server-find-reports` only if the question is about reporting structure, not location. Seating comes from desk assignments, so use `graphql-mcp-server-get-draft-assignments` only when the user is asking about a planned layout, not the current one. 3. For live presence in a place, call `graphql-mcp-server-get-building-live-state`. Use `graphql-mcp-server-get-building-overview` for the floor and desk context needed to describe where a person is, and `graphql-mcp-server-get-building-hours` if the user asks whether the building is open at a given time. Treat "live state" as a snapshot. Say the time it reflects if the result carries one. If the user asks about a future day, do not extrapolate live presence; say that live data only covers now and offer the planned seating or their own bookings instead. ## 3. Decide how much to disclose Match the detail to the request: - A manager or colleague asking "is X in today" needs yes or no, and the floor or zone if known. - A team question needs counts and a short list of names, not a per-person timeline. - Do not volunteer anything beyond presence and seating: no schedules that reveal private appointments, no inference about why someone is away, no comparison of how often people attend. - If someone is not visible, do not infer absence or leave; say "not showing as present in Robin" and stop there. If the request looks like tracking an individual's attendance over time, or monitoring a colleague, stop and check the purpose with the user before running more lookups. Presence history for a named person is a different request from a team's seating today. ## 4. Handle gaps honestly - **No match for a name:** report "no one matching that name in the directory" and suggest the full name or email. - **Empty live state:** the building may have no live sensors or no check-ins. Say presence data is unavailable for that place rather than reporting an empty office. - **Permission block:** if a call is refused, say the Robin account cannot see that data, and suggest the user ask their Robin administrator. Do not try to work around the restriction with other tools. - **Partial results:** if the team list is paginated or truncated, say how many were returned and that the rest were not checked. ## Common patterns and traps - **Live state is not attendance.** A person being on the floor now does not mean they are at work for the day. Report what the live data shows, with its time, and nothing more. - **Desk assignment is not presence.** A person can have an assigned desk and be absent, or sit at a shared desk they did not book. Keep "assigned to" and "seen in" separate. - **Same-name collisions.** Two people share a first name is the most common error. Always confirm the person before reporting their location. - **Time zones.** A team across sites may be on different local days. State the site and time for each figure. - **Over-disclosure by default.** Listing every person on a floor with their desk number is usually more than the question needs. Summarise first, name people only when asked. - **Confusing this with booking.** If the user then says "book Sam a desk next to him", that is the desk-booking job, and it needs its own confirmed write. ## Output ``` Question: , ,