Robin, inside Claudeyour AI assistant

List the department names that actually exist in the caller's organization. Call this before filtering find_people by department. Departments are free text an admin typed, and the filter is an exact match, so a plausible guess like "Design" returns nobody when the real value is "Design & Research" — and an empty result is indistinguishable from a department with no people in it. Pass a value from this list verbatim. These are the values stored on people, not a group hierarchy, so they are exactly the set find_people filters against. An empty list means nobody in the organization has a department set: say so rather than guessing a name. Names only, no counts. For the headcount of every department — "how big is each team", "which teams are largest" — call get_department_overview instead: it returns these same strings, each with its number of active people, in one call. Never size teams by calling find_people once per value from here. This is the cheap read when all you need is the valid strings.

No parameters required.

Draw a stack plan: one row per floor, every desk as a chip coloured by its group, with a legend. Use it for questions about a WHOLE building — how space divides across floors, where there is room, whether a team is split up — and to show a PROPOSED layout before anything is written to Robin. You supply the rows, so read the building first (get_location_levels for the floors, then get_draft_data per floor for who sits where, joined to find_people for departments and managers) and pass the counts you worked out. Send the same numbers you describe in prose. Do not call this on a vague request: confirm which building and which breakdown first, since reading a building is many calls.

Changes the time of an existing desk reservation in place — extend it, shorten it, or shift it — keeping the same booking rather than cancelling and rebooking. A booking that has not started keeps its id; one already in progress may be SPLIT by the service into an elapsed part and a new live booking, and the new part does not carry the original check-in (see updatedReservations). Pass only the bound(s) that change; an omitted start or end is kept as is. The new window goes through the same guard as a fresh booking: nothing entirely in the past, a slipped start bumped forward to now and reported. Works on the calling user's own, non-recurring bookings only — someone else's reservation, a recurring series, and an assigned desk are refused with the supported route instead. Performs the write immediately once the reservation and the new time are settled; returns the previous window beside the new one and a ready-made call to put it back.

Start a floor-plan draft for a building. Returns the buildingDraftId that every subsequent lifecycle call (update_draft, review_draft_changes, publish_draft) requires — child floorDraftIds are never valid there. The new draft starts at version 0.

Save a stack plan for a building along with the business-unit options it is weighing. Each option is a set of building-wide desk totals per business unit. Returns the plan id and an id per option, which create_allocation needs to propose a floor split.

Discard a stack plan and every floor-split proposal under it. There is no way to discard one proposal on its own. Scenario drafts built from a proposal are not affected. Confirm with the user first — this takes the whole plan.

Start assigning or seating a person or people at a desk, floor, or building. Returns the scenario-planning workflow with the request restated — call this before create_building_draft or update_draft, then follow the steps it returns.

Removes a desk reservation: cancels it outright when it has not started yet, or ends it at this moment when it is already in progress — one tool for both, and the result says which happened. This is the undo for book_desk. A reservation that is already over is refused, and a recurring booking requires you to say whether the user meant this one occurrence or the whole series — ask them, never assume. Works on the caller's own bookings and, with delegate permission, on someone else's. Returns the removed booking's desk, window, type and visibility, plus a ready-made book_desk call to put it back.

Resolve a human desk reference like "Pod 1, Desk 2" to desk ids, or list a floor's desks: searches a building's desks by name (case-insensitive, exact matches first), optionally narrowed by pod (zone) name and level. Omit deskName (levelId then required) to list every desk on a floor — the listing is complete and includes booking types and assignee count; an open assignable desk has deskTypes ["assigned","shared"], assigneeCount 0, and isDisabled false. If a name reference matches more than one desk, ask the user to disambiguate instead of guessing. Use the returned deskId in update_draft. Reads the LIVE floor plan, so it cannot see changes made in the current draft — for a floor as the draft would leave it, use get_draft_data. Use this when you need desk ids or the assignee on a specific desk; for desk counts by booking type, one floor or the whole building, use get_building_overview rather than listing a floor and counting.

List the workplace analytics metrics available for scenario planning in this organization — one per question: commonly booked rooms by type (space_reservations_count, group by meeting__space_type), rooms consistently under capacity (undersized_meetings_count, group by meeting__space_name), desks used by an individual (desk_checkin_days_count, group by reservation__assignee_name), and desks a team reserves on a typical day (avg_desks_used_per_day: distinct desks reserved per day the group had a booking — reservations including no-shows, not check-ins, averaged over the days the group was in, not over all office days; group by reservation__assignee_department, reservation__assignee_manager_name, or reservation__level_name). Returns each metric’s id, description, allowed group-bys, allowed filters, and date-range behavior. These are the only metrics execute_scenario_planning_metric accepts; always call this first, for the building you will execute against, and use the ids and options it returns. Takes the building_id only; needs planning access to that building.

Execute one of the scenario planning metrics (commonly booked rooms by type, rooms consistently under capacity, desks used by an individual, desks a team reserves on a typical day) for one building and return the result (a single value, or grouped rows when group_by is given) with the applied date range, filters, and provenance. The building is a filter in the query itself, so results cover only that building and building_id is echoed on the response; do not add the building to group_by. For how many desks a team reserves on a typical day, use avg_desks_used_per_day grouped by the lens you need (department, manager, or level) and say it counts reservations including no-shows, averaged over the days the group was in. It has a different basis from desk_checkin_days_count, which counts check-in days per person; do not present one as the other. Needs planning permission on the building, or collaborator access to one of its drafts or stack plans: viewers are refused (viewer_only), others too (no_planning_access), and collaborators may group and filter by place and time only, never by anything that names a person (aggregates_only, with the allowed dimensions in valid) — relay these in plain words and do not retry. A truncated result (truncated: true) was capped within the building, like any other grouped result; say so rather than retrying. Use find_scenario_planning_metric first for the metric ids and their allowed group-bys and filters; no other metric id is accepted. Validation failures return a structured error with the valid options — correct the arguments and retry.

Get the link that opens a building draft in Robin, so the user can review and edit it there. Call it when the user asks to open, see, review or share the draft — and when you have just finished building one, since reviewing in Robin is easier than another round of tool calls. Do NOT offer a link to a draft that has no changes in it yet: a draft created only to read who sits where is an empty editor, and pointing someone at it is confusing. Takes the buildingDraftId from create_building_draft; add levelId to land on a specific floor. The link is not a share — it opens for people who already have access, so use invite_users_to_draft to give someone access.

Read one stack plan in full: the business-unit variations it is weighing, every proposed floor split, and which business units each split leaves short or overprovisioned. Read-only.

PUBLISHES a building draft to the LIVE floor plan — irreversible and visible to the whole workplace. Before calling: run review_draft_changes and confirm with the user. Requires the draft's current version (from the latest update_draft) and the numeric levelIds to publish. EMAIL: publishing always sends a summary to the publisher — whoever authorized this call — and that cannot be turned off, so never tell the user no email will go out. Every OTHER email is opt-in and off by default: sendNotifications emails the people affected (assignments changed and reservations cancelled, together — they cannot be separated), and exportCSVUserIds emails a CSV of the changes to recipients the user names, which is a separate choice from notifying the affected people. Only enable either if the user asked. Publishing is ASYNCHRONOUS: a successful return means the publish was ACCEPTED, not that the changes are live. Confirm with get_draft_status, polled three times — 10 seconds after this call, again at 20, and a last time at 30 — and never retry this tool or create another draft while a publish is in flight.

Invite people to a building draft as collaborators or viewers, so they can review or help build a plan before it is published. This NOTIFIES the people invited, so treat it the way you would sending mail on the user's behalf: invite only who the user named, and only when they asked for it. Requires an explicit accessLevel — 'collaborator' can change the draft, 'viewer' can only read it, and NEITHER can publish it: that stays with the draft's owner. Takes NO version: sharing is outside the draft's version chain, so there is nothing to chain here. Call get_draft_collaborators first to see who already has access — re-inviting someone emails them a second time for nothing.

Find people, desks, spaces, or bookable resources in the caller's organization by name or email. Returns matching entities with their IDs, types, and location context, for use as inputs to other tools. Optionally restrict to specific entity types; omit entityTypes to search everything.

List the neighborhood colour slots this organization actually has, with the hex each one renders as. Call this before sending a neighborhood to update_draft, and pass an `id` from it verbatim. `id` is what update_draft's `color` field takes — a named slot such as `NH_A`, never a CSS colour. `base` and `dark.base` are only what that slot looks like on the floor plan, so a choice can be described to the user ("the teal one"); never send `base` or `dark.base` to update_draft, which fills the display hex in itself. A caller only DESCRIBING a colour reads `base` and can ignore everything else. A caller DRAWING a neighborhood needs the set matching the background it draws on: `base` + `label` on a light ground, `dark.base` + `dark.label` on a dark one. `base` is the fill; `label` is the pill the neighborhood's NAME sits in, as background plus text colour. Worth knowing which half actually changes: the fill is the same in both themes for every slot, and the label pill inverts. So a renderer that only fills shapes can read `base` alone and be correct on any ground; one that writes names has to switch. Worth the round trip, because the vocabulary is not guessable in the direction that costs something. The schema declares fourteen slot names (`NH_A`..`NH_N`) but only the ones returned here have a colour defined, and a neighborhood written with any other name is accepted by every validator upstream, publishes, and then renders with no colour at all. update_draft refuses a slot missing from this list rather than landing that, so a name invented from the pattern costs the same round trip and an error. The list is org-wide and identical on every floor, so one call covers a whole session. Which slots are FREE is per-floor and is not answered here: read the floor with get_draft_data and pick one no neighborhood there is already using, so two neighborhoods on one plan are not drawn the same colour.

No parameters required.

Who a building draft or stack plan has been shared with, and at what level. Returns each person it was shared with through invite_users_to_draft, with their user id, name, email, and access level (`collaborator` or `viewer`). It does NOT list the owner or the building's planners unless someone invited them: they have access through their planning permission, not through a share, so an empty list means "shared with nobody", not "nobody can see it". find_people_for_draft reports each person's access to the draft, including those permission-based `editor`s. Call this BEFORE invite_users_to_draft. Inviting emails the people named, and nothing here checks whether they already have access, so this is what keeps a share from landing in the inbox of someone who has had the draft open all along. `editor` is the only level that can PUBLISH the draft, and it comes from planning permission. A `collaborator` can change everything in it but cannot publish; a `viewer` can only read. invite_users_to_draft grants `collaborator` or `viewer` only, never `editor`. Takes the buildingDraftId from create_building_draft, and no version: sharing sits outside the draft's version chain.

Everyone who reports to one manager, directly or through other managers — the manager's whole organization in one call, each person with their depth (depth 1 is a direct report, 2 a report's report, and so on). This is the skip-level question find_people cannot answer: its managerIds filter returns DIRECT reports only. Use find_reports when the request is a leader's whole org ("everyone under Jack", "seat Priya's organization on Floor 1"); use find_people with managerIds when it is one manager's own team. managerId is a user id, never a name — get_managers lists the people who manage someone, with the ids this takes; two managers with the same name is a question for the user, not a coin flip. The manager themselves is not included in the result. The walk stops at a deactivated person: they are not returned, and it does not continue through them to their own reports, because a manager line still pointing at someone who has left is stale. So a team whose manager has left does NOT reappear under the manager above — it is absent, and a gap in the org chart is a gap, not a reparented team. A deactivated manager has an empty chain. Every intermediate manager is itself a member, so each person's managerId can be read off the same result — group by it to see the org's shape. The one exception is the queried manager, who is not in the result: their depth-1 reports carry a managerId with no member to label it, and that label comes from the get_managers lookup you started with. `name` is the display name and can be null — fall back to givenName and familyName, which are selected for exactly that reason. maxDepth bounds the walk. It takes 1 to 20 and defaults to its maximum of 20, which is deeper than any real org chart, so the default returns the whole chain and nothing is clipped. A maxDepth you choose yourself returns a PARTIAL chain, and nothing in the result says so — there is no truncation flag, and total counts the people returned, not the people below. So when you pass a maxDepth, say the answer is bounded to that depth and name it; members at the deepest level may have reports that were never fetched. Never present a bounded chain as a whole org. total is the number of people returned. The whole chain comes back in one response; there is no paging. Above 1000 people the call FAILS instead of returning part of the chain — ask about a manager further down, or pass a lower maxDepth and then state the bound, as above.

Get the calling user's identity, workplace context, and the current time in one call: Robin user id, name, email, timezone, default building (id and name), current organization, and currentDateTime — the authoritative current instant. Takes no input. Call this FIRST for any request about the calling user themselves ("my desk", "my building", "book me a desk"): it replaces search_entities for self-referential requests, and its userId, timezone, and defaultLocationId are the values to pass to any tool that takes a user id, a timezone, or a building (location) id — defaultLocationId is the building the floor and desk lookups (get_location_levels, find_desks) take, and defaultLevelId is the floor; use them unless the user names another. Call it FIRST as well for any request carrying a relative date ("today", "tomorrow", "next Tuesday", "this week"): resolve that date against currentDateTime in the user's timezone rather than assuming what today is, because Robin's reservation service accepts a booking in the past silently.

No parameters required.

Pre-flight a desk booking: for up to 100 desks and up to 30 time windows (at most 750 desk-window pairs per call), report each desk's availability status per window, the typed reasons it cannot be booked (policy violations, access, capacity — each carrying the rule's value and a plain-language explanation, so a rejection contains the rule it broke), the reservations occupying it, and any exclusion windows (released assigned desks — bookable as reverse_hotel when the window fits entirely inside one). For a multi-day or recurring plan, pass each day's span as its own window in ONE call instead of calling once per day. This answers whether SPECIFIC desks can be booked; it is not a floor sweep — narrow the desks first (find_desks by floor or zone) and bring their ids here. Availability is evaluated for the calling user unless userId is given, and each desk reports bookedByRequestingUser — the flag that separates a desk someone ELSE holds from one the evaluated user already holds themselves (private bookings included, also when checking on someone else's behalf), the latter being reschedulable in place even though the desk reads as not bookable. Assigned desks (types ["assigned","shared"]) are judged the way the office map judges them: bookable only as reverse_hotel on a day the assignee has released the desk — releasedForWindow, assignees, and bookAs report exactly that, and bookable already folds it in, so an unreleased assigned desk nobody sits at reads status AVAILABLE but bookable false. Zone-less window bounds are read in timeZone when given (pass the same value to book_desk), else the caller's timezone. ALWAYS check the chosen desk here before book_desk: booking rejections that this surfaces in advance include conflicts, advance-booking limits, max length, working hours, and floor capacity — and capacity is only enforced here, not at booking time.

List every office location (building) in the caller's organization, with address and timezone. The id of each is the buildingId the building tools take. For a building's size and shape — floors, desk counts by booking type, neighborhoods — pass it to get_building_overview. When only the floor ids and names are needed, get_location_levels is the one cheaper call.

No parameters required.

Headcount per department for the caller's organization in one call: every department string with the number of active people in it, plus how many people have no department at all. Reads the live directory and counts — no draft, and no call per department, so this replaces get_departments followed by find_people once per team when what you need is the size of each team. The strings are exactly what find_people's departments filter takes. Pass departments to size only the teams in scope. Department is free text on each person, not an org hierarchy: two spellings are two departments, and nothing here rolls them up.

Books a desk for a settled desk and time window, and returns everything needed to report the booking back and offer an undo. Books for the current user by default, or for another person when forUser (their email) is given — which requires delegate permission. This tool performs the write immediately; confirm the desk, window, and reservation type first (check_desk_availability shows what is bookable and which reservationType to send as bookAs). It does not re-check availability itself, but the window goes through the same guard as the read tools: start and end may carry an offset or be zone-less (then read in timeZone, the request timezone, or the caller's profile timezone, in that order), a window that has already ended is refused, and a start that has merely passed is clamped to now and reported as effectiveStartTime. Assigned desks follow their own rule: one is bookable only as reverse_hotel, and only on a day its assignee has released it — with no release (or no assignee to release it) it is seated by an admin assignment instead and cannot be booked by anyone.

Read this FIRST, before loading a building's floors or calling scenario_planning_workflow, whenever the request involves: Use for viewing, evaluating, mocking up or drafting a stack plan — how business units are seated across the floors of a building. Triggers on "how are my teams using the building", "show me where teams are sitting", "can I reduce my footprint", "what if Sales moved floors", "can we absorb growth", "consolidate teams onto one floor", "create neighborhoods for each department", "build a scenario planning draft", "save this as a plan", "what plans do we have for this building", "open the Q3 plan", and on follow-ups like sharing a plan, inviting collaborators, or asking where one team sits. Consult it before rendering any stack plan or changing anything in Robin. Returns how to read the current seating, which questions this data can and cannot answer (assignments yes, desk usage no), how to identify what a business unit actually is, and when a proposal is ready to become a draft.

No parameters required.

Record one more set of building-wide desk totals on an existing stack plan. Use this when the numbers change: a variation freezes once an allocation implements it and cannot be edited, so a revision is a new variation on the same plan — not an edit, and not a second plan. Returns the variation id create_allocation needs.

Read this FIRST, before calling create_building_draft, update_draft, or publish_draft, whenever the request involves: Assign or move people to desks ("Assign Sam to Floor 2", "Move the team to Pod 1"), change desk types or reservability, edit floor plans, and publish draft changes via the Robin MCP tools. Returns which tool to use in which order, the draft lifecycle rules, and the conventions for talking to the user while planning.

No parameters required.

Apply changes to a building draft under an optimistic lock: per-desk changes (reservability, reservation types, assignments) and per-neighborhood changes (name, colour slot, desk membership, creation and removal). Takes the buildingDraftId and the draft's current version; returns the bumped version, which the next update_draft or publish_draft call must use. Two reads come first for a neighborhood change: get_neighborhood_colors, because a colour is a named slot from that list and not a hex, and get_draft_data, because a neighborhood's desk membership REPLACES what is there. Neighborhood changes on several floors are grouped by the tool; the caller sends one batch.

Review what a building draft would change before publishing: per-floor summary with each floor's numeric levelId (the ids publish_draft takes), change flags, desk-statistics deltas, per-neighborhood before/after deltas, the existing bookings publishing would cancel, and the draft status. Always review before publish_draft, and always show the user any reservationsToCancel — publishing cancels those people's bookings and cannot be undone. Set detailed: true for the full payload with assignment schedules.

Fetch the current optimistic-lock version of a building draft. Support tool for recovery: versions normally come from create_building_draft (0) and each update_draft result — use this only when the current version is unknown (lost context) or an update failed with a stale-version error. Takes the buildingDraftId returned by create_building_draft.

Answer "what desks are free on floor X for this window" in one call: sweeps an entire level for a time window and returns the desks that are bookable by the calling user (with names, booking types, pod, amenities, and the reservationType to book them as), plus how many are busy or off-limits. Assigned desks follow the office map's rule: one is listed only when its assignee has released it for the window (then with bookAs reverse_hotel) — the rest are counted in assignedNotBookableCount. Optionally filter to desks with specific amenities — call once without deskAmenityIds to get the floor's amenity ids from levelDeskAmenities, then re-call with them. Use this instead of paging find_desks results through check_desk_availability in batches. A window that has already ended is refused; a start that has merely passed is clamped to now and reported as effectiveStartTime, which then replaces the requested start everywhere. Availability reflects the caller's own access and conflicts; still call check_desk_availability on the desk you pick before book_desk, since policy limits and floor capacity are only reported there.

List a user's desk reservations within a time range: which desk (with its floor and building names), when, the reservation type, check-in state, and who booked it, sorted earliest-first. Omit userId for the calling user (it resolves automatically); resolve anyone else with search_entities. Times are ISO 8601 datetimes; use the start and end of the user's day (in their timezone) to answer questions about a specific day. For preference questions ("my usual desk", "which days am I normally in", "how often do I come in"), query a past range (4-8 weeks works well) and read the server-computed `analytics` block instead of counting reservations yourself.

The building's working day, date by date: opening time frames for a range of calendar dates, with closed days (weekends, holidays, closures) coming back as empty. Use it to propose real booking hours instead of assuming 9:00–17:00, and to skip closed days when planning multi-day bookings — a day with open=false should never be booked. locationId defaults to the calling user's default building; all times are local wall-clock times in the building's own timezone (returned alongside).

Read a building as floors × desk types in one call: every floor with its desk counts (total, active, disabled) and how many active desks are of each booking type, plus each floor's neighborhoods when includeNeighborhoods is set. Reads the LIVE floor plan and needs no draft. This is the opening read for a stack plan and the cheap way to tell an assignment-desk building from a hotel-desk one; it does not say who sits where — that is get_draft_data (draft) or find_desks (live, one floor).

Find people in the caller's organization and return the user ids the draft tools take. Built for a request that names a group — "the design team", "everyone reporting to Ana", "people who joined this month" — but userNameFilter also resolves a single named person, and in a draft-only toolset this is the tool for that. Where search_entities is also available it matches fuzzily and scores results, so prefer it for a half-remembered name. Each filter narrows the result; combining them ANDs them together. - departments: EXACT match against free text an admin typed. Call get_departments first and pass one or more values from it verbatim. A guessed string returns zero people, which is indistinguishable from a team that has nobody in it, so never guess. - managerIds: user ids, not names. Call get_managers for the real set and pass an id from it; that is also what makes an ambiguous "Ana" visible rather than silently resolved. Failing that, this tool's userNameFilter or search_entities can look the manager up. Returns DIRECT reports only — for everyone under a leader at every depth, use find_reports. - userNameFilter: a PREFIX match on name, surname, slug, or email — "ana" finds "Ana Kovač", "kova" finds her by surname, but a fragment from the middle of a name finds nothing — ask for a cleaner spelling rather than guessing, or use search_entities where the client exposes it. - addedWithinDays: people added to the organization in the last N days, for seating a joiner cohort. - statuses: omit it and deactivated people are excluded, which is what seating wants. Pass DEACTIVATED to explain why someone expected is missing. Each person comes back with department, title, and their DIRECT manager (managerId plus the manager's name), which is what lets results be grouped by team, seniority, or reporting line without a second lookup. It is one level only — a manager's manager is not resolved, so a senior leader's wider org cannot be assembled from this call; find_reports walks the whole chain. accountUsersTotal is the total number of matches, not the size of this page: state it to the user before changing any desks, so seating a 40-person department is a decision rather than a surprise. hasNextPage and nextPageOffset page through the rest. Use this when you need the people themselves — their ids, managers, titles. When the question is only how big each team is, get_department_overview returns every department's headcount in one call; do not size teams by calling this once per department. Omitting every filter lists the whole directory one page at a time. That is occasionally what someone wants, but it is rarely the answer to a seating request — pass at least one filter unless a full listing was asked for.

Read one floor's editable draft state: its desks (booking types, who the draft seats on each) and its neighborhoods (name, color slot, desk membership), each flagged for whether it differs from the live plan. This is the draft-aware counterpart to find_desks, which reads the LIVE plan and cannot see changes made in the current draft. Also returns the draft's current version, so you do not need get_draft_version. levelId is REQUIRED — each call reads exactly one floor. It needs a draft: for neighborhoods or desk counts across floors with no draft in play, get_building_overview with includeNeighborhoods reads the live plan for the whole building in one call and creates nothing. NOTE: this is not a pure read. It creates the floor's child draft if one does not exist yet (which is what you want right after create_building_draft) and syncs newly-added seats onto it; repeating the call changes nothing further.

Where specific people sit according to a draft: their desk assignments with the draft's pending changes already merged over the live floor plan, for one or more people looked up by userId or email. Use it before moving someone, to see which desks they currently hold (and would be released), and to confirm an assignment landed. find_desks reads the LIVE plan only and cannot see assignments made in the current draft; this can.

List the saved stack plans for a building — named replans, each holding the business-unit variations it is weighing. Returns names and descriptions only; call get_stack_plan for one plan's variations, floor splits and shortfalls. Read-only. Building drafts are not listed here or by any other tool, so do not offer to look one up; a draft can only be reached by the id you were given.

Park people on one floor's assignment queue in a draft — the holding list for people you mean to seat but cannot yet. The main use: a group does not fit, so you seat everyone who fits and queue the overflow, then the admin adds desks and you assign the queued people. Queues are PER FLOOR, so levelId is required. Takes NO version — queue changes are outside the draft's version optimistic lock, so there is nothing to chain here. Read the queue back with get_draft_queue.

Who is waiting for a desk on one floor of a draft: the people on that floor's assignment queue, with names, emails, and departments. A queue holds people an admin means to seat but cannot yet — typically because a group did not fit, so the overflow was parked here until desks are added. Queues are PER FLOOR, so levelId is required. Use this before assigning from the queue, and after, to confirm it is clear. Note that assigning someone does NOT remove them from the queue — remove_users_from_draft_queue does that.

Get an office location (building) by ID with its address and timezone, plus every floor with that floor's total desk count. Use it to resolve a floor name to the numeric levelId the draft tools take. deskCount includes inactive desks — to see individual desks, their booking types, and who sits on them, use find_desks with that levelId. For desk counts by booking type across floors, or each floor's neighborhoods, use get_building_overview instead.

List the people who actually manage someone in the caller's organization, with the user ids the manager filters take. Call this before filtering find_people or find_people_for_draft by `managerIds`. Those filters take ids, never names, so without this list the only way to reach "everyone reporting to Ana" is to look Ana up by name first and hope the right Ana came back. This returns the actual set of managers, so a request naming a reporting line can be resolved against it — and an ambiguous one ("Ana") is visibly ambiguous rather than silently resolved to whoever matched first. This is the manager counterpart of get_departments, and it has the same meaning: these are people referenced as somebody's manager on their user record, not an org-chart hierarchy. It is exactly the set the filters compare against. Someone who manages nobody does not appear, however senior they are. One level, like the filters it serves: filtering by a manager returns their DIRECT reports, not their reports' reports. For a senior leader's whole organization — reports of reports, all the way down — pass the id from here to find_reports instead. `name` is the display name and can be null — fall back to givenName and familyName. Department and title are included to tell two people with the same name apart; ask the user which they meant rather than picking one. An empty list means nobody in the organization has a manager set: say so rather than guessing a name.

No parameters required.

Current status of ONE building draft — how you confirm a publish actually landed. publish_draft returns as soon as the publish is ACCEPTED, not when it is live, because publishing is asynchronous; this tool is how you learn what became of it. Takes the buildingDraftId from create_building_draft. After publish_draft, poll this THREE times: 10 seconds after the publish, again at 20 seconds, and a last time at 30 seconds. Stop at the first settled status. - published — the changes are live. Confirm to the user and stop. - publishing — still in flight. Poll again if you have polls left. Never retry publish_draft and never create a new draft while one is publishing. - publishing_failed — the publish did not go through. Report it and stop. - discarded — the draft was thrown away; nothing was published. - open — the publish never started. Still publishing after the third poll? Stop polling and tell the user their changes are on the way and to check back in a few minutes; a large set of changes takes longer to go live. Do not retry the publish and do not create another draft. Never narrate any of this. The user does not need to hear about polling, publish states, or asynchronous anything — only whether their changes are live yet. This reads one draft whose id you already hold. It cannot list or search drafts, and it returns nothing but that draft's id and status.

Clear people from one floor's assignment queue in a draft. Call this AFTER you seat a queued person: assigning someone a desk with update_draft does not remove them from the queue, so the queue keeps reporting them as waiting until you remove them here. Also use it when the user changes their mind about who is waiting. Queues are PER FLOOR, so levelId is required. Takes NO version — queue changes are outside the draft's version optimistic lock.

Search the WHOLE organization's directory, and see each person's relationship to one building draft: what access they have to it (if any), and whether the draft seats them. It searches everyone, not the draft's members — most results will have no connection to the draft at all, which is the point when you are looking for someone to invite. Use it BEFORE invite_users_to_draft to check whether the people you are about to email already have access. With assignmentStatus UNASSIGNED it flips to the other question: who has no desk in this plan. This tool does NOT invite anyone — invite_users_to_draft does that. For a directory lookup with no draft in play, use find_people; to list the people already on a draft, use get_draft_collaborators.

Propose a way of placing one of a stack plan's options across the building's floors. Several proposals can implement the same option, which is how layouts get compared. Returns the proposal's version for update_allocation, which business units the split leaves short or overprovisioned, and each floor in the starting split against its real desk count (floorCapacity); an unfinished split is saved rather than refused.

Rewrite the floor split of a proposal. Each floor sent replaces that floor outright; floors left out are untouched, and a floor sent with no business units is cleared. Returns the new version, what the split still leaves short against its option, and each written floor against its real desk count (floorCapacity) — a split can add up and still not fit the floor. Requires the version last read.

Get a read handle for a building's CURRENT seating — who sits at which desk, as it stands right now. Use this to answer questions and explore options; it leaves nothing behind for anyone to find, appears in no drafts list, and can never be published. Returns the same handle every time for a building, so call it once and reuse the id. When the user commits to a layout, build a real draft instead — this is not it.