GoProfiles

Send a Bravo (peer recognition) that the user has already approved. ONLY call this after preview_bravo and after the user has explicitly said to send that preview. The user asking for a Bravo is not approval of its contents — they must approve the actual recipient, badge, and message first. Sends the recipient and badge resolved by preview_bravo, so this tool takes no uid or bid: the arguments here are the human-readable values the user approved, and they are checked against the preview rather than sent. When the preview showed a point count or a send time, pass them — points are deducted from the sender's balance and a send time schedules delivery that cannot be changed from this chat (only later in GoProfiles), so omitting either is treated as a change to the approved Bravo and the send is refused. The sender is always the authenticated user, derived from the access token. Not read-only and not reversible — it notifies the recipient. Requires bravos:write and profiles:read scopes.

create_bravo

Check whether a specific person is available right now, by uid (https://www.goprofiles.io). Combines their connected calendar (Google or Outlook, whichever the workspace uses) with the working hours configured on their GoProfiles profile: their local time, whether they are on the clock, the start and end time of every meeting left in their day, the open blocks between those meetings, and their next time off. Meeting times only — the calendar API deliberately withholds titles, locations, and attendees, so never claim to know what a meeting is about. Scoped to today — it reports what is left of the person's current working day, not future dates. Use after search_people has resolved a name to a uid. If the person has no calendar connected, or the workspace has no calendar integration, this still reports their working hours and says so explicitly; relay that caveat rather than presenting the hours as confirmed free time. Never show the uid to the user. Read-only. Requires profiles:read scope.

get_availability

Get the signed-in user's OWN GoProfiles profile (https://www.goprofiles.io) and which parts of it they can edit. Use this whenever the user asks about or wants to change "my profile". Unlike get_profile it needs no uid and no search_people lookup — it always returns the person who is signed in. Each field is listed as editable or locked. Locked fields are controlled by the workspace: synced from an HR system or directory (edit it there), managed by an admin, or turned off. Workspace-specific custom bio fields are listed with their type and, for dropdown / multi choice, the allowed options. The [name] next to each field is the preview_my_profile_update parameter. Read-only. Requires profiles:read scope.

get_my_profile

Get a specific person's full GoProfiles profile by uid (https://www.goprofiles.io). Combines users.php, certifications.php, and languages.php into one normalized response with bio, title, languages, skills, certifications, interests, groups, and contact info. Only an explicit allow-list of profile fields is returned — other fields from the underlying endpoints are stripped. The uid itself is not included in the response text. Use after search_people when you need the full profile for a resolved uid. This tool cannot look anyone up by name and has no notion of "me" — use get_my_profile for the signed-in user's own profile. search_people is the only way to turn a name into a uid, and the uid must come from this chat, never from memory or another conversation. Never show the uid to the user. Read-only. Requires profiles:read scope.

get_profile

Preview a Bravo before sending it. Sends nothing. Resolves the recipient and badge to their real names, checks both exist, and returns a preview of exactly what create_bravo will send. Nothing is sent and nothing is notified. Call this once you have the recipient, the badge, and the message. Gather the badge and the message together in a single question rather than one at a time — do not call this tool with a message you invented and have not shown the user. Do not ask how many points they want; leave points out unless they bring it up themselves. Then show the user the To / Badge / Points / Message from the result and wait for them to explicitly approve it. Only after that, call create_bravo. Read-only. Requires bravos:read and profiles:read scopes.

preview_bravo

Preview a calendar invite before creating it. Creates nothing. Resolves the attendee to their real name, checks they exist, works out which calendar the workspace uses (Google or Outlook), and returns a preview of exactly what schedule_meeting will create. No event is created, no calendar is touched, and nobody is notified. The start time has to come from the user. Nothing here can search for a free slot on a future date — get_availability only reports what is left of that person's TODAY. So never pick a time on the user's behalf: ask them for the day and time, and put their UTC offset in starts_at. Omitting description uses the same default invite body the GoProfiles web scheduler sends when nobody customizes it — the attendee's name, title, location, and profile link, with a GoProfiles footer. That default is the normal case; don't draft custom text unless the user has actually asked for different wording. The result includes a Conflicts line, which is ADVISORY and never blocks the invite. It reports one of three things, and the difference matters: a warning that the attendee is booked or out of office; that nothing was found in the window that could be checked; or that the slot could not be checked at all — which is the normal answer for any slot beyond today, because only the rest of today's meetings are visible. Time off is the exception and is checked up to two months ahead. Relay that line as it stands. NOT CHECKED does not mean free, and must never be reported to the user as free. Ask for everything still missing in ONE message — the time, the length, and the title. Do not ask for these one turn at a time. Description needs no asking unless the user wants something other than the default. Then show the user the With / When / Duration / Title / Description from the result and wait for them to explicitly approve it. Only after that, call schedule_meeting. Read-only. Requires profiles:read scope.

preview_meeting

Preview a change to the signed-in user's own GoProfiles profile. Changes nothing. Checks each requested change against the user's current profile and the workspace's data matching settings, and returns a before → after preview. If any requested field is locked (synced from an HR system, admin-managed, or turned off), nothing is staged and the reason is returned — tell the user where that field is managed instead of retrying. Only the signed-in user's profile can be changed; there is no way to edit anyone else. Call get_my_profile first if you need field names, custom field options, or current values. If you draft text for the user (e.g. a bio), show it to them before calling this. Then show the user the preview and wait for them to explicitly approve it. Only after that, call update_my_profile with the same `changes`. Read-only. Requires profiles:read scope.

preview_my_profile_update

Create a calendar invite that the user has already approved. ONLY call this after preview_meeting and after the user has explicitly said to send that invite. The user asking for a meeting is not approval of its contents — they must approve the actual attendee, time, length, title, and invite body first. Creates the meeting resolved by preview_meeting, so this tool takes no uid: the arguments here are the human-readable values the user approved, and they are checked against the preview rather than sent. The organizer is always the authenticated user, derived from the access token. There is no way to schedule on someone else's behalf, and no parameter that could point the invite at a different person or calendar. Not read-only and not reversible — it creates a real event on both people's calendars and emails the invite. Requires profiles:write and profiles:read scopes.

schedule_meeting

List the Bravo badge types that can be given in the user's GoProfiles workspace (https://www.goprofiles.io). Call with no arguments to list them all. Always call this tool in the current chat before naming any badge to the user — even if you already "know" a badge name like Team Player from earlier in this conversation, another chat, memory, or examples. Never tell the user which badges are available based on anything but this tool's output. When the user has not said which badge they want, call this with no search so they see the real choices. Do not invent a search term on their behalf: it silently hides badges, and presenting a filtered result as "the available badge" is wrong. Returns each badge type's name, description, and a numeric 'bid' for preview_bravo. This is the catalog of what CAN be given — for bravos that have already been given, use search_bravos. After results return, ask the user for everything still missing in one message — which badge (unless they already named one) and what the message should say. Do not ask for these one turn at a time. The 'bid' is internal. Never show, read aloud, or otherwise expose it to the user; refer to badge types by name. Read-only. Requires bravos:read scope.

search_bravo_types

Search the history of Bravos already given in the user's GoProfiles workspace (https://www.goprofiles.io) — peer recognition that has been sent. This is the recognition FEED, not the badge catalog and not a way to send anything: use search_bravo_types to see which badges exist, and preview_bravo to send one. Use this tool to answer questions about what already happened — who was recognized recently, what someone has been thanked for, which teams are giving recognition. Each result gives the badge, when it was given, who gave it, who received it, their departments, any points, and the message. Results are always newest first; there is no sort option. Filters combine (they narrow each other, never widen). Date filtering is a relative past-only day window, not calendar dates. The person filter is not directional — it matches the giver or the receiver — so check 'From' and 'To' before telling the user someone gave rather than received a bravo. Each entry carries numeric 'uid' values for follow-up get_profile calls. Never show, read aloud, or otherwise expose them; refer to people by name, username, or department instead. Read-only. Requires bravos:read scope.

search_bravos