Trainual

Read-only. Search the credentials uploaded to user profiles — certifications, licenses, assessments, and professional records. Call this tool even if the question mentions a specific person - profile documents are searchable by user name. Works at any scope: one named person's documents, or an account-wide sweep across everyone's uploaded credentials (queries search the parsed document text, so "anything mentioning X" sweeps need no person filter). NOT for skills or certifications mentioned only in a user's bio text (fetch_users' queries also searches skills - try both if the first comes up empty). NOT for files uploaded into training content — course attachments and the like (search_content's uploaded_file type). The word "uploaded" alone does not mean training content: a credential, license, or certification file — person-scoped or account-wide — is a profile document and belongs here. NOT for a file the user attached to the current Assistant conversation — read_attached_file. Common use cases: - "Show me John's certifications." - "Who has a PMP certification?" - "Find expired licenses." - "What assessments has Sarah completed?" - "Search for AWS certificates." - "Does [user] have [certification]?" - "Search everyone's uploaded credentials for [a qualification]." FILTERS: You can provide ids, queries, both, or neither: - ids only: Fetch specific profile documents by ID - queries only: Search documents by user name, filename, document content (plain_text), or document type (multiple queries use OR logic — matches ANY term) - Both ids AND queries: First filters to the provided IDs, then searches within that filtered set (INTERSECTION: must match at least one query term AND be in the ids list) - Neither: Returns all accessible profile documents The queries parameter searches the following fields: - user name - filename - plain_text (parsed document content including certifications, assessments, licenses, etc.) - document_type (e.g., certification, assessment, license) **Optional includes**: • user - the document's owner (name and ID), always returned regardless of include. Passing include: ['user'] is accepted but has no effect — this class eager-loads the user association unconditionally, so the parameter changes neither the response shape nor the query plan. Returns the following fields: {"id":"The profile document's internal identifier","filename":"The filename of the profile document","plain_text":"The extracted plain text content from the profile document","document_type":"The type of the profile document (e.g., certification, assessment, license)","user":"The user that owns the profile document, with the following fields: {\"id\":\"The user's internal identifier\",\"name\":\"The user's full name\",\"job_title\":\"The user's job title\",\"avatar\":\"URL to the user's avatar image\",\"result_card\":\"A string used for client-side navigation\",\"citation\":\"A string used to identify the record in citations\",\"web_url\":\"Absolute URL to the user profile page in the Trainual web app (nil when account context is unavailable)\",\"__typename\":\"The type of the object (always 'User')\"}","__typename":"The type of the object (always 'ProfileDocument')"}

fetch_profile_documents

Read-only. Search inside training content — the primary tool for finding answers within an organization's written training material. Most answers to policy, process, and procedure questions live in training pages (steps), which make up the majority of content in any account. Meetings are not training content: when the question asks about a meeting ("which meeting covered the Q3 budget?") or who said or raised what, call fetch_meetings or fetch_meeting_transcripts instead of this tool (if neither is available to you, say meeting content isn't available). Domain: - Customer-facing terminology: Subject (top-level container, legacy: Curriculum), Document (content item made of Pages, legacy: Topic), Page (unit within a Document, legacy: Step), Category (grouping: Company / Policies / Processes, legacy: Sector). - A Page can contain richtext, links, embeds, videos, images, files, and tables. Version history and commenting are available on Pages. - Subjects are categorized as Company, Policies, or Processes. - This tool searches INSIDE content (page text, training-video transcripts, checklist items, file text). To find or list training subjects/documents by title, use fetch_curriculums instead. NOT for: team status reports, weekly updates, or check-ins — those live in the Updates feature (fetch_update_assignments); content search returns look-alike training documents from unrelated teams. NOT for Trainual product release notes / "what's new at Trainual" — no tool covers product announcements. NOT for per-user training progress, completion, or due dates — fetch_curriculum_assignments. NOT for looking up people or groups directly — fetch_users or fetch_groups respectively. NOT for credentials, certifications, or licenses uploaded to user profiles — fetch_profile_documents, including account-wide sweeps ("everyone's uploaded credentials"); the uploaded_file type here covers files uploaded into training content, not profile documents. NOT for a file the user attached to the current Assistant conversation — read_attached_file; a file the user just uploaded into the chat is never indexed here. NOT for who said, raised, or decided something, even when no meeting is named — that is conversation, not training content. Its transcripts are training-video transcripts, not meeting transcripts: use fetch_meeting_transcripts. If that tool isn't available to you, say meeting content isn't available rather than answering from a training page. Long bodies are trimmed: each result carries body_truncated and full_length. body_truncated: true means the document matched but its body was cut — the visible text may omit the answer even when the document is clearly relevant. Retry ONCE with a narrower, more specific query to rank the relevant portion higher; never conclude the information doesn't exist just because a truncated body doesn't show it. If a search returns nothing, retry with alternate phrasings, synonyms, and broader terms before concluding the content doesn't exist. Exception: when the question is about credentials, certifications, or licenses, do not spend retries here — that material lives on user profiles, so switch to fetch_profile_documents. Likewise for a meeting, or who said or raised something: switch to fetch_meetings / fetch_meeting_transcripts rather than retrying here. Common use cases: - "What is our PTO policy?" / "How do we handle returns?" / "What's the onboarding process?" - "Show me checklists" / "Find training videos" / "List all flowcharts" - Fallback when other tools do not return the information needed Content types searched: - steps (training pages — the largest content type, where most answers live) - courses (Documents — the container for Pages; use to answer "do we have a Document about X?") - videos (with transcript text, type, and description) - checklists (with checklist item text) - flowcharts (with structure and content) - uploaded_files (with extracted plain text — files uploaded INTO training content only; a user's uploaded credentials, certifications, and licenses are profile documents and never appear here, so credential questions must go to fetch_profile_documents even when this type returns nothing) Use the content_types filter to narrow results to specific types (e.g., only videos, only checklists). Omit it to search across all content types. Each result includes: id, title, body text (page text, video transcript, checklist items, or extracted file text), body_truncated, full_length, citation (for response annotations), result_card (for navigation), owner, and curriculum/course context.

search_content

Retrieves feedback requests — first-class objects with a fulfillment status — from the requesting user's perspective. Read-only; responding to a request is not supported. Domain: - A request asks one or more responders for feedback ABOUT one user. Each responder gets an invitation whose status is 'pending' until they answer ('completed'). - Requests are personal-scope: users see requests they SENT and requests they were ASKED to answer. There is no account-wide request view, even for admins. An account-wide- sounding brief ("all feedback requests in the account") is still answerable — CALL this tool and report the requester's own sent/to-answer requests; a scope mismatch is never a reason to decline the call or to answer without calling it. Report those results as the requester's own requests, never as an account-wide or complete listing — an admin's results are exactly as personal-scope as anyone else's — and state plainly that no account-wide view exists. - A completed invitation links to the feedback record it produced (feedback_id) — fetch the response text via fetch_feedback with ids: [feedback_id]. Common use cases: - "Which of my feedback requests haven't been answered yet?" → role: 'sent', status: 'pending' - "Show me requests I've sent about my direct reports and their status" → role: 'sent', about_user_ids: [...] (resolve the reports via fetch_users include: children) - "Do I have feedback requests waiting on my response?" → role: 'to_answer', status: 'pending' FILTERS: - role (required): 'sent' = requests the user created; 'to_answer' = requests where the user is an asked responder (scoped to their own invitation). - status: 'pending' or 'completed'. For 'sent', filters on invitation fulfillment (a request with any pending invitation matches 'pending'; with any completed invitation matches 'completed'). For 'to_answer', filters the user's own invitation state. - about_user_ids: only requests about these users. Resolve names via fetch_users first. - created_after / created_before: ISO 8601 datetimes. PAGINATION: newest-first; if has_more is true, call again with cursor: next_cursor until has_more is false before summarizing. A cursor is only valid for the SAME filters it was returned from — an invalid or mismatched cursor returns an error telling you to retry without it (omit cursor to restart from the first page). Returns {"feedback_requests": [...], "total_count": n, "has_more": bool, "next_cursor": str|null}. Each record: {"id":"The feedback request's internal identifier","prompt":"The question the requester asked, as plain text","visibility":"Visibility the resulting feedback will carry: 'private', 'private_plus_manager', or 'manager_only' (requests are never public)","about_user":"The user the request is about. Structure: {\"id\":\"The user's internal identifier\",\"name\":\"The user's full name\",\"job_title\":\"The user's job title\",\"avatar\":\"URL to the user's avatar image\",\"result_card\":\"A string used for client-side navigation\",\"citation\":\"A string used to identify the record in citations\",\"web_url\":\"Absolute URL to the user profile page in the Trainual web app (nil when account context is unavailable)\",\"__typename\":\"The type of the object (always 'User')\"}","created_by":"The user who sent the request. Structure: {\"id\":\"The user's internal identifier\",\"name\":\"The user's full name\",\"job_title\":\"The user's job title\",\"avatar\":\"URL to the user's avatar image\",\"result_card\":\"A string used for client-side navigation\",\"citation\":\"A string used to identify the record in citations\",\"web_url\":\"Absolute URL to the user profile page in the Trainual web app (nil when account context is unavailable)\",\"__typename\":\"The type of the object (always 'User')\"}","invitations":"Who was asked to respond, each with fulfillment status. Structure: {\"id\":\"The invitation's internal identifier\",\"status\":\"'pending' (not yet answered) or 'completed' (the responder gave feedback)\",\"responded_at\":\"When the responder answered (ISO 8601), or null while pending\",\"recipient\":\"The user asked to give feedback. Structure: {\\\"id\\\":\\\"The user's internal identifier\\\",\\\"name\\\":\\\"The user's full name\\\",\\\"job_title\\\":\\\"The user's job title\\\",\\\"avatar\\\":\\\"URL to the user's avatar image\\\",\\\"result_card\\\":\\\"A string used for client-side navigation\\\",\\\"citation\\\":\\\"A string used to identify the record in citations\\\",\\\"web_url\\\":\\\"Absolute URL to the user profile page in the Trainual web app (nil when account context is unavailable)\\\",\\\"__typename\\\":\\\"The type of the object (always 'User')\\\"}\",\"feedback_id\":\"The feedback record that fulfilled this invitation (fetch by id via fetch_feedback), or null while pending (or if the linked feedback record was since removed)\",\"result_card\":\"Not available for invitations (always null)\",\"citation\":\"A string used to identify the record in citations\",\"web_url\":\"Absolute URL to the Feedback requests tab in the Trainual web app\",\"__typename\":\"The type of the object (always 'PerformanceFeedbackRequestInvitation')\"}","created_at":"When the request was sent (ISO 8601)","result_card":"Not available for feedback requests (always null)","citation":"A string used to identify the record in citations","web_url":"Absolute URL to the Feedback requests tab in the Trainual web app","__typename":"The type of the object (always 'PerformanceFeedbackRequest')"}

fetch_feedback_requests

Read-only. Retrieves goals (OKRs/targets) the user has permission to see, by ID(s) or search queries, with optional related data like owner, watchers, recorded values, comments, and history. Owner, watcher (which may be a group), and linked-meeting fields are summary data only — call fetch_users, fetch_groups, or fetch_meetings with their IDs for full details. Use this tool when you need information about goals including progress, status, ownership, and targets. Domain: - Goals track progress toward a defined outcome with an end state — distinct from Scorecards (recurring measurable targets, no end state). - Goals and Scorecards are separate stores; neither tool returns the other's data. A metric/target/trend question that doesn't say "goal" or "scorecard" can be tracked in either product, so both this tool and fetch_scorecards must be queried to cover it. - Owner: exactly one per goal, responsible for driving progress. - Watchers: users or groups who can view progress. Includes the owner's direct managers by default. - Status: Not Started, On Track, Off Track, At Risk, or Done. - Metric: optional measurable target (e.g. "Close 50 deals") — a numeric value tracked against a target. - Observations: progress entries logged against a goal or its metric. - Due Date: optional target completion date. - Visibility: owners, watchers, owner's direct reports. Billing Admins see all. NOT for the full picture alone: "team status", "catch me up", "full picture", or "what should I focus on" questions usually also need fetch_update_assignments (what people reported) and fetch_meetings (meeting activity) — fetch_goals does not cover general meeting or update- submission activity beyond what's already linked to a specific goal. Common use cases: - "What goals am I working on?" - "What's the status of [goal name]?" - "Which goals are off track?" - "Who owns the revenue goal?" FILTERS: You can provide ids, queries, owner_ids, status, or combinations: - ids only: Fetch specific goals by ID - queries only: Search goals by title or description (multiple queries use OR logic - matches ANY term) - Both ids AND queries: First filters to the provided IDs, then searches within that filtered set (INTERSECTION: must match at least one query term AND be in the ids list) - owner_ids: Filter goals by owner user IDs. Use fetch_users first to resolve names to IDs. - watcher_ids: Filter goals watched by specific user IDs (direct or via group membership). Automatically excludes goals owned by the same user (use owner_ids for owned goals). - exclude_owner_ids: Exclude goals owned by these user IDs from results. - status: Filter goals by status (multiple values use OR logic) - due_before / due_after: Filter by the goal's target (due) date. Use for time-bounded questions like "goals due this quarter" or "what's due by end of month". Goals with no target date are excluded when either bound is set. For a pure date-range question, pass ONLY due_before/due_after — do NOT also pass queries. queries is ANDed with the date bounds, so adding words like "due date" or "deadline" wrongly drops goals whose title and description don't contain those literal words. - Neither: Returns all goals visible to the current user The queries parameter searches the following fields: goal title, description If a title search returns nothing, retry with partial words, singular/plural variants, and related terms from the request before concluding the goal doesn't exist (e.g. "the Q3 revenue growth goal" → queries: ["revenue", "Q3", "growth"]). Treat non-exact keyword matches as candidates, not a confirmed match. **Optional includes**: • owner - The user who owns this goal • watchers - Users and groups watching this goal • children - Sub-goals under this goal • parent - The parent goal if this is a sub-goal • observations - Recorded values (progress updates) with numeric values and status snapshots over time • comments - Comments on this goal • goal_histories - History of edits (state before each change) • meetings — Meetings linked to this goal Returns the following fields: {"id":"The goal's internal identifier","title":"The name of the goal","description":"A detailed description of what this goal aims to achieve","target_value":"The primary target value. For single-target goals, this is the goal. For range goals, this is the upper bound of the range.","secondary_value":"The lower bound of the range. Only present when the goal is a range goal; null otherwise.","target_date":"The target completion date for the goal (ISO 8601)","status":"Internal status identifier, computed from the latest recorded value. Never show the raw value to users. When narrating, render 'not_started' as \"Not Started\", 'on_track' as \"On Track\", 'off_track' as \"Off Track\", 'at_risk' as \"At Risk\", 'done' as \"Done\".","current_value":"The current progress value. Already aggregated — for Cumulative goals this is the sum of recorded values; for Trend goals it is the latest recorded value.","unit":"The unit of measurement and formatting hint. Format recorded values as: 'currency' → prefix with $ (e.g. '$5,000'), 'percentage' → suffix with % (e.g. '85%'), 'count' → plain number (e.g. '1,234').","measurement_type":"How progress is tracked, as a human-readable label: 'Trend' (latest recorded value is the current state) or 'Cumulative' (values sum over time).","parent_id":"The ID of the parent goal, if this is a sub-goal","created_at":"When the goal was created (ISO 8601)","updated_at":"When the goal was last updated (ISO 8601)","result_card":"Not available for goals (always null)","web_url":"Absolute URL to the goal page in the Trainual web app (nil when account context is unavailable)","citation":"A string used to identify the record in citations","__typename":"The type of the object (always 'OperationsGoal')"}

fetch_goals

Retrieves growth areas — persistent, named development focuses — the user is entitled to see, with title, description text, status, dates, owner, and creator. Read-only. Domain: - A growth area belongs to exactly ONE owner. It can be created by the owner or by their manager, so creator and owner may differ — both are returned and filterable. - Status lifecycle: 'draft' and 'active' mean not done / in progress; 'completed' is done; 'archived' is abandoned. When the user asks what is "not done", "unfinished", or "in progress", PASS status: ["draft","active"] — do not fetch all statuses and classify the results yourself; archived items are abandoned, NOT "not done". "Overdue" → target_before: now AND status: ["draft","active"] (completed/archived items are never overdue). An unqualified request ("show me X's growth areas") means ALL statuses — omit the key (or pass status: ['any']); do NOT narrow to draft/active unless the user asks what is open or not done. - Entitlement: users see their own growth areas and their org-chart reports' — the whole reporting subtree below them, not just direct reports. Account-wide visibility requires billing-admin or an admin with performance full access — a plain admin or group manager does NOT see group members' growth areas. Enforced per record; results may legitimately be empty — when they are, say the items may exist but aren't visible to the requester, don't assert none exist. - Topics/themes are NOT stored. Infer them from the returned title and description text. - NOT ad-hoc praise or private feedback given between people; that's fetch_feedback. Common use cases: - "Show me my growth areas" → status: ['any'] (or omit status entirely) - "Which of my growth areas aren't done?" → status: ["draft","active"] - "Growth areas my manager created for me" → owner_ids: [me], creator_ids: [manager id] - "Growth areas I created for Dani" → creator_ids: [me], owner_ids: [Dani] — ALWAYS pair creator_ids with owner_ids when the question names whose growth areas they are; creator_ids alone returns everything that person ever created, including their own. owner_ids is DANI (whose profile the areas live on) — NEVER yourself for a "for <someone else>" question; owner_ids: [me] + creator_ids: [me] returns your own self-created areas. - "What are my team's growth themes?" → resolve the team via fetch_users/fetch_groups, pass owner_ids FILTERS (all optional, AND semantics): - ids: direct record lookup (e.g. for follow-ups). Unentitled ids are silently excluded. - owner_ids: whose growth areas. Resolve names, groups, and "team" references to user IDs first via fetch_users/fetch_groups. For "my team": a people-manager means their direct reports (fetch_users include: children); a group manager means members of the groups they manage. For a user who is BOTH: a brief that covers both scopes is fully specified — fetch both and label results by scope; a brief naming neither warrants one clarifying question — never pick one scope silently. When "team" cannot be resolved at all, ask rather than guess. - creator_ids: who created them — distinct from owner. - status: any of 'draft', 'active', 'completed', 'archived'. Omit for all statuses. - target_after / target_before: ISO 8601 — target-date window (due soon, overdue). - created_after / created_before: ISO 8601 — creation window (when the focus was SET). - completed_after / completed_before: ISO 8601 — completion window (when the focus FINISHED). Use for "completed in <period>" questions — created_after only tells you when it was set, not when it finished, and will miss items set earlier and completed later. - updated_after / updated_before: ISO 8601 — last-edit window. Any edit bumps updated_at (activity proxy, not proof of substantive progress). Use updated_before to find growth areas that have gone quiet. - There is NO text-search parameter — retrieve and infer topics from the returned title/description text. PAGINATION: newest-first; if has_more is true, call again with cursor: next_cursor (same filters — changing filters invalidates the cursor) until has_more is false. Retrieve ALL pages before synthesizing themes or trends. total_count is the full entitled count for the current filters. Returns {"growth_areas": [...], "total_count": n, "has_more": bool, "next_cursor": str|null}. Each record: {"id":"The growth area's internal identifier","title":"The named development focus","description":"Optional detail as plain text.","status":"'draft', 'active', 'completed', 'archived' ('draft'/'active' = open; see tool description for filter semantics)","target_date":"Target completion date (ISO 8601 date), or null","completed_date":"When it was marked completed (ISO 8601 date), or null","created_at":"When it was created (ISO 8601)","updated_at":"When it was last edited in any way (ISO 8601). Activity proxy only — any edit bumps it; not proof of substantive progress","owner":"The person this growth area belongs to — exactly one. Structure: {\"id\":\"The user's internal identifier\",\"name\":\"The user's full name\",\"job_title\":\"The user's job title\",\"avatar\":\"URL to the user's avatar image\",\"result_card\":\"A string used for client-side navigation\",\"citation\":\"A string used to identify the record in citations\",\"web_url\":\"Absolute URL to the user profile page in the Trainual web app (nil when account context is unavailable)\",\"__typename\":\"The type of the object (always 'User')\"}","creator":"Who created it — the owner themselves or their manager; may differ from owner. Structure: {\"id\":\"The user's internal identifier\",\"name\":\"The user's full name\",\"job_title\":\"The user's job title\",\"avatar\":\"URL to the user's avatar image\",\"result_card\":\"A string used for client-side navigation\",\"citation\":\"A string used to identify the record in citations\",\"web_url\":\"Absolute URL to the user profile page in the Trainual web app (nil when account context is unavailable)\",\"__typename\":\"The type of the object (always 'User')\"}","result_card":"Not available for growth areas (always null)","citation":"A string used to identify the record in citations","web_url":"Absolute URL to the owner's profile page (where growth areas live)","__typename":"The type of the object (always 'PerformanceGrowthArea')"}

fetch_growth_areas

Read-only. Retrieves specific meeting items by id — agenda items, their talking points, action items, or their subtasks — when you already hold an item id from a previous fetch_meetings result and need to drill into that one item without re-fetching the whole meeting. Each result carries the item's full detail plus `parent` (the agenda item or action item it sits under, null for top-level items) and `meeting` (id and title). NOT for finding meetings, listing an agenda, or answering "what's on my agenda" — use fetch_meetings for those. Ids here are the string `id` values from fetch_meetings' item objects, never meeting ids. Ids that are not returned were not found or are not visible to this user; say so rather than substituting other items. Returns an array of: {"id":"The item's identifier (use with fetch_meeting_items)","text":"The item title (short text)","content_html":"The item description/notes, sanitized to Markdown from its rich-text body. Read this, not just text, to understand what the item is about","kind":"'agenda_item' (a topic to discuss; its children are talking points) or 'action_item' (a task; its children are subtasks)","recurring":"True when this item carries forward to the next occurrence even after being completed","position":"Display order within its parent or section","owner":"The user assigned to this item, or null. Structure: {\"id\":\"The user's internal identifier\",\"name\":\"The user's full name\",\"job_title\":\"The user's job title\",\"avatar\":\"URL to the user's avatar image\",\"result_card\":\"A string used for client-side navigation\",\"citation\":\"A string used to identify the record in citations\",\"web_url\":\"Absolute URL to the user profile page in the Trainual web app (nil when account context is unavailable)\",\"__typename\":\"The type of the object (always 'User')\"}","due_by":"Deadline (ISO 8601 date), null if none","completed_at":"When completed (ISO 8601). Present = completed, null = open.","deferred_at":"When deferred (ISO 8601), null if not deferred","deferred_until":"When a deferred item resurfaces (ISO 8601)","archived_at":"When archived (ISO 8601), null if not archived","comments":"Comments on this item, oldest first. Structure: {\"id\":\"The comment's internal identifier\",\"content_html\":\"The comment content in HTML format\",\"created_at\":\"When the comment was created (ISO 8601)\",\"created_by\":\"The user who wrote the comment. Structure: {\\\"id\\\":\\\"The user's internal identifier\\\",\\\"name\\\":\\\"The user's full name\\\",\\\"job_title\\\":\\\"The user's job title\\\",\\\"avatar\\\":\\\"URL to the user's avatar image\\\",\\\"result_card\\\":\\\"A string used for client-side navigation\\\",\\\"citation\\\":\\\"A string used to identify the record in citations\\\",\\\"web_url\\\":\\\"Absolute URL to the user profile page in the Trainual web app (nil when account context is unavailable)\\\",\\\"__typename\\\":\\\"The type of the object (always 'User')\\\"}\",\"__typename\":\"The type of the object (always 'Comment')\"}","attachments":"Files attached to this item. Structure: {\"id\":\"The attachment's identifier\",\"filename\":\"The uploaded file name\",\"content_type\":\"MIME type of the file\",\"byte_size\":\"File size in bytes\",\"uploaded_by\":\"The user who attached the file. Structure: {\\\"id\\\":\\\"The user's internal identifier\\\",\\\"name\\\":\\\"The user's full name\\\",\\\"job_title\\\":\\\"The user's job title\\\",\\\"avatar\\\":\\\"URL to the user's avatar image\\\",\\\"result_card\\\":\\\"A string used for client-side navigation\\\",\\\"citation\\\":\\\"A string used to identify the record in citations\\\",\\\"web_url\\\":\\\"Absolute URL to the user profile page in the Trainual web app (nil when account context is unavailable)\\\",\\\"__typename\\\":\\\"The type of the object (always 'User')\\\"}\",\"created_at\":\"When the file was attached (ISO 8601)\",\"__typename\":\"The type of the object (always 'OperationsItemAttachment')\"}","parent_id":"For a talking point or subtask, the id of its parent item; null for top-level items","meeting_id":"The meeting this item belongs to","children":"Nested talking points (under an agenda item) or subtasks (under an action item), same structure as this object. Always present; [] when there are none","__typename":"The type of the object (always 'OperationsMeetingItem')","parent":"For a talking point or subtask, { id, text } of the agenda item or action item it sits under; null for top-level items","meeting":"{ id, title } of the meeting this item belongs to"}

fetch_meeting_items

Read-only. Retrieves meetings the user has permission to see, by ID(s) or search queries, with optional related data: owner, attendees, agenda items (with their talking points), action items (with their subtasks), and linked goals. Owner, attendee (which may be a group), and linked-goal fields are summary data only — call fetch_users, fetch_groups, or fetch_goals with their IDs for full details. Domain: - Meetings provide structured recurring agendas for 1-on-1s, team syncs, and other regular check-ins. Each meeting has an agenda that carries forward between occurrences. - Owner: the user who created and manages the meeting. - Attendees: users or groups. Group attendee includes all members. - Agenda items: the topics a meeting covers — recurring ones reappear every occurrence, one-off ones belong to a single occurrence. Each has a short title (text), a rich-text description (content_html), an optional owner, comments, attachments, and nested talking points in `children` (sub-points to cover under that topic). - Action items: tasks with an owner and optional due date that persist until completed. Same fields as agenda items; their `children` are subtasks. - Every item, at every level, carries the same fields. Use `content_html` and comments — not just `text` — to explain what an item is actually about. - `children` is always present. When it is [] the item has NO talking points or subtasks: say so. An item's own `text`/`content_html` describes the item itself and is never a talking point or subtask — do not restate it as one. - "Discussion topics" is the former name for one-off agenda items — a user asking about them means agenda_items. - Meeting Notes: free-form notes captured during an occurrence. - Cadence: recurrence schedule (weekly, biweekly, monthly, etc.). NOT for the full picture alone: meeting prep, 1-on-1 prep, and "catch me up"/"team status" questions usually also need fetch_goals (goal progress) and fetch_update_assignments (what people reported) — fetch_meetings does not cover general goal or update-submission activity beyond what's already linked to a specific meeting. Common use cases: - "What meetings do I have this week?" - "What's the agenda for my next team sync?" - "Help me prepare for my 1-on-1 with [person]" - "What did we discuss under [agenda item]?" → its children (talking points) **Assembling "the agenda":** A customer's idea of "the agenda" — or "what's coming up", "what should I cover", or anything meeting-prep — is the WHOLE picture: agenda items with their talking points AND outstanding action items with their subtasks. For these questions, include: ["agenda_items", "action_items"] is REQUIRED, not optional — request both in one call (add "meeting_goals" when prep is implied). Never report an empty agenda without having requested both. When listing action items, always state owner, due_by, and completion state for each. To drill into a single item you already hold an id for (a talking point, subtask, agenda item, or action item), use fetch_meeting_items instead of re-fetching the meeting. **Meeting types** (team syncs, all-hands, project check-ins, and 1-on-1s are all meetings, distinguished by attendees and cadence): - General: any combination of user and group attendees. Most user queries ("my meetings", "meetings this week", "how many meetings") refer to ALL meetings. - Recurring: any meeting with a cadence. Identify by checking the cadence field in the response (non-empty = recurring). - 1-on-1: a specific subtype — recurring, with 1 owner (User) + 1 attendee (User), and no Group attendees. To identify from results: include meeting_attendees, then check that cadence is non-empty, there is exactly 1 attendee with __typename: 'User', and none with __typename: 'Group'. - One-off: a meeting with no cadence field. FILTERS: You can provide ids, queries, date range, person_ids, or combinations: - ids only: Fetch specific meetings by ID - queries only: Search meetings by title, agenda item text, action item text, and summary, and the notetaker recap when notetakers are available to you (multiple queries use OR logic — matches ANY term). They never search what was said (transcripts): for what was said, decided, or raised in meetings, use fetch_meeting_transcripts without meeting_ids. - Both ids AND queries: First filters to the provided IDs, then searches within that set - starts_after / starts_before: Filter by meeting start time range (ISO 8601) - person_ids: Filter meetings where specific users participate (as owner, direct attendee, or group member). Use fetch_users first to resolve names to IDs. Prefer person_ids over queries when the user names a person — a name in queries fuzzily matches other people's meetings too. - Neither: Returns all meetings visible to the current user If a title search returns nothing, retry with partial words, singular/plural variants, and related terms from the request before concluding the meeting doesn't exist (e.g. "the weekly product sync meeting" → queries: ["product", "sync", "weekly"]). Treat non-exact keyword matches as candidates, not a confirmed match. Meeting status (upcoming vs ended) and recurrence (cadence field) are included in the response data. **Result ordering**: - Searches with queries return most-relevant-first, weighted toward recent meetings, with one result per recurring series (its newest occurrence). For recency questions ("last", "most recent", "latest", "previous") on a search, the first result is usually the answer. - Results without queries (ids, person_ids, or date filters only) are ordered oldest-first (starts_at ascending). For recency questions there, set starts_before: <current datetime> and answer from the result with the latest starts_at — never assume the first result is the most recent. **Optional includes**: • meeting_owner — The current owner of this meeting • meeting_attendees — Users and groups attending this meeting • agenda_items — Agenda items with owner, description, comments, attachments, and nested talking points • action_items — Action items with owner, due date, completion state, comments, attachments, and nested subtasks • meeting_goals — Goals linked to this meeting • notetaker_summary — The AI notetaker's recap of what was discussed, merged across every recording, with notetaker_status and summary_status Recap questions ("summarize my last leadership meeting", "how did the all-hands go?", "main takeaways from Tuesday's sync") → prefer the meeting's `summary` when it is present (a participant wrote or corrected it); include notetaker_summary and fall back to its content only when `summary` is empty. State in the answer which one you used. Questions about who said what, exact wording, what was decided, or when something came up in the conversation need the transcript: use fetch_meeting_transcripts when it is available to you (with queries and no meeting_ids when no meeting is named — a fetch_meetings keyword hit is not a transcript search); otherwise say the transcript isn't available rather than inferring quotes from the summary. When requesting agenda_items or action_items, always narrow the call with ids, person_ids, queries, or a starts_after/starts_before window — item includes make each meeting large, and an unfiltered call on a busy account returns far more than one question needs. Comments and attachments belong to a specific item, not the meeting. Use the item's `text` and `content_html` to identify what a comment was about, along with the commenter. Returns the following fields: {"id":"The meeting's internal identifier","title":"The name of the meeting","cadence":"Human-readable recurrence schedule (e.g. \"Weekly on Mondays\"). Null if one-off.","timezone":"The IANA timezone for this meeting","starts_at":"Scheduled start time (ISO 8601)","ends_at":"Scheduled end time (ISO 8601)","started_at":"When the meeting actually started (ISO 8601). Present = started, null = not yet started.","ended_at":"When the meeting actually ended (ISO 8601). Present = ended, null = not yet ended.","summary":"The meeting recap written or edited by a participant (may start from AI-generated text). Empty when nobody has written one.","created_at":"When the meeting was created (ISO 8601)","updated_at":"When the meeting was last updated (ISO 8601)","result_card":"Pipe-delimited string: 'OperationsMeeting|{uuid}|{title}'","web_url":"Absolute URL to the meeting page in the Trainual web app (nil when account context is unavailable)","citation":"A string used to identify the record in citations","__typename":"The type of the object (always 'OperationsMeeting')"} Each entry in agenda_items and action_items (and each of its children) has this structure: {"id":"The item's identifier (use with fetch_meeting_items)","text":"The item title (short text)","content_html":"The item description/notes, sanitized to Markdown from its rich-text body. Read this, not just text, to understand what the item is about","kind":"'agenda_item' (a topic to discuss; its children are talking points) or 'action_item' (a task; its children are subtasks)","recurring":"True when this item carries forward to the next occurrence even after being completed","position":"Display order within its parent or section","owner":"The user assigned to this item, or null. Structure: {\"id\":\"The user's internal identifier\",\"name\":\"The user's full name\",\"job_title\":\"The user's job title\",\"avatar\":\"URL to the user's avatar image\",\"result_card\":\"A string used for client-side navigation\",\"citation\":\"A string used to identify the record in citations\",\"web_url\":\"Absolute URL to the user profile page in the Trainual web app (nil when account context is unavailable)\",\"__typename\":\"The type of the object (always 'User')\"}","due_by":"Deadline (ISO 8601 date), null if none","completed_at":"When completed (ISO 8601). Present = completed, null = open.","deferred_at":"When deferred (ISO 8601), null if not deferred","deferred_until":"When a deferred item resurfaces (ISO 8601)","archived_at":"When archived (ISO 8601), null if not archived","comments":"Comments on this item, oldest first. Structure: {\"id\":\"The comment's internal identifier\",\"content_html\":\"The comment content in HTML format\",\"created_at\":\"When the comment was created (ISO 8601)\",\"created_by\":\"The user who wrote the comment. Structure: {\\\"id\\\":\\\"The user's internal identifier\\\",\\\"name\\\":\\\"The user's full name\\\",\\\"job_title\\\":\\\"The user's job title\\\",\\\"avatar\\\":\\\"URL to the user's avatar image\\\",\\\"result_card\\\":\\\"A string used for client-side navigation\\\",\\\"citation\\\":\\\"A string used to identify the record in citations\\\",\\\"web_url\\\":\\\"Absolute URL to the user profile page in the Trainual web app (nil when account context is unavailable)\\\",\\\"__typename\\\":\\\"The type of the object (always 'User')\\\"}\",\"__typename\":\"The type of the object (always 'Comment')\"}","attachments":"Files attached to this item. Structure: {\"id\":\"The attachment's identifier\",\"filename\":\"The uploaded file name\",\"content_type\":\"MIME type of the file\",\"byte_size\":\"File size in bytes\",\"uploaded_by\":\"The user who attached the file. Structure: {\\\"id\\\":\\\"The user's internal identifier\\\",\\\"name\\\":\\\"The user's full name\\\",\\\"job_title\\\":\\\"The user's job title\\\",\\\"avatar\\\":\\\"URL to the user's avatar image\\\",\\\"result_card\\\":\\\"A string used for client-side navigation\\\",\\\"citation\\\":\\\"A string used to identify the record in citations\\\",\\\"web_url\\\":\\\"Absolute URL to the user profile page in the Trainual web app (nil when account context is unavailable)\\\",\\\"__typename\\\":\\\"The type of the object (always 'User')\\\"}\",\"created_at\":\"When the file was attached (ISO 8601)\",\"__typename\":\"The type of the object (always 'OperationsItemAttachment')\"}","parent_id":"For a talking point or subtask, the id of its parent item; null for top-level items","meeting_id":"The meeting this item belongs to","children":"Nested talking points (under an agenda item) or subtasks (under an action item), same structure as this object. Always present; [] when there are none","__typename":"The type of the object (always 'OperationsMeetingItem')"}

fetch_meetings

Read-only. Look up who someone is — identity, contact info, profile data, role history, skills, interests, working style, and reporting structure. Domain: - Permission levels are cumulative — General (view assigned items), Contributor (edit assigned items), Author (create and assign), Admin (reports, manage users), Billing Admin (manage billing and plans). - Users can configure their profile (name, title, phone, email, pronouns, time zone, birth month/day with optional hidden birthday, LinkedIn URL, "Working with me" notes, interests, skills, role history). Email notifications: daily update (new assignments, ownership changes, review tags) and weekly incomplete-work reminders. NOT for: training progress, completions, or due dates — fetch_curriculum_assignments is the only tool with per-user assignment data. NOT for group-level attributes (a team's responsibilities, software, membership) — fetch_groups with the matching include. Profile data is the source of truth: treat returned skills, interests, and bio as authoritative. Never guess or fabricate skills/interests, and never add names beyond those in the results. If a value appeared in a result earlier in the conversation, do not later claim it was not found. Resolving people by name: - If a name lookup returns nothing, retry with nickname and spelling variants as additional query terms before concluding the person isn't found (e.g. "Mike" → ["Mike", "Michael"], "Jess" → ["Jessica"]). - When there is no exact match, results may be approximate (closest by name) — treat them as candidates to confirm or disambiguate, never as a single asserted match. Common use cases: - "Who is [person]?" / job title, email, phone, LinkedIn — base fields, no include needed. - "What are [person]'s skills / interests?" (include: skills, hashtags) - "What are [person]'s responsibilities?" (include: responsibilities) - "What roles has [person] held?" (include: user_roles) - "Who does [person] report to?" (include: parent) / "Who reports to [person]?" (include: children) - "Who are [person]'s peers?" — fetch [person] with include: parent, then fetch the parent with include: children; the children minus [person] are the peers. - Comparison/commonality questions ("what do I have in common with X") — fetch BOTH people with include: [skills, hashtags]. - "List all users" / "Who are the engineers?" (permissions / group_ids filters) - Reverse lookups ("who knows [skill]?", "who is interested in [topic]?", "who else is a [job title]?", "who mentions [thing] in their bio?") — pass the term as a query. FILTERS: ids, queries, both, or neither: - ids only: specific users by ID - queries only: searches user name, job title, skills, interests, bio text, and "working with me" notes (OR logic across multiple terms) - Both: INTERSECTION — must match at least one query term AND be in the ids list - Neither: all accessible users - permissions: narrow to these levels ('general', 'contributor', 'author', 'admin', 'billing_admin') - group_ids: narrow to users in these groups (resolve names to IDs with fetch_groups first) **Optional includes**: parent (direct manager), children (direct reports), groups, software (owned/managed by the user — NOT software granted only through group membership; see fetch_softwares/fetch_groups for that), responsibilities (the user's complete set, direct plus group-inherited, each with name, description, assignment_source and via_groups — answers "what is [person] responsible for?" on its own; fetch_responsibilities cannot scope to a person), skills, hashtags (interests — hobbies, passions, out-of-work topics; pair skills with hashtags for two-person comparisons — a single-person lookup uses the minimal default includes), user_roles (job title history). Returns the following fields: {"id":"The user's internal identifier","name":"The user's full name","job_title":"The user's job title","avatar":"URL to the user's avatar image","result_card":"A string used for client-side navigation","citation":"A string used to identify the record in citations","web_url":"Absolute URL to the user profile page in the Trainual web app (nil when account context is unavailable)","__typename":"The type of the object (always 'User')","bio":"The user's biography","completion_percentage":"The percentage of assigned content the user has completed","pronouns":"The user's preferred pronouns","email":"The user's email address. Use to answer how to reach someone in writing or to identify users by email. Returns nil if the account has disabled showing email addresses on profiles.","phone_number":"The user's phone number, if set. Use to answer how to reach someone by phone. Returns nil if the user has not set a phone number, or if the account has disabled showing phone numbers on profiles.","linkedin_url":"The URL of the user's LinkedIn profile, if set. Returns nil otherwise.","invitation_sent_at":"The date the user was invited to join Trainual, formatted as ISO 8601. Surfaced on the profile UI as \"Invite date\" — phrase responses using that label. Use to answer questions like \"When was [user] invited?\" or \"Who are the most recently added members?\". Returns nil if the user was not invited (e.g., the account owner).","working_with_me":"The user's working style, communication preferences, and collaboration cues — the \"Working with [User]\" section of their profile, written by the user themselves. Returned as plain text. Common use cases: helping someone understand how to collaborate effectively with this person, comparing two people's working styles to find compatibility or differences, summarizing what to know before a first interaction, or answering questions like \"how do Taylor and I best work together?\" or \"what's Taylor's preferred communication style?\". Choose whatever output format suits the question (prose, table, comparison list). Returns nil if the user has not filled in this field.","parent":"The user's direct manager or supervisor in the organizational hierarchy (immediate superior only). Use this field to answer questions such as: \"Who does [user] report to?\", \"Who is [user]'s manager?\", \"Who is [user]'s supervisor?\". Returns nil if the user has no manager (e.g., CEO or top-level user). The parent user includes the following fields: {\"id\":\"The user's internal identifier\",\"name\":\"The user's full name\",\"job_title\":\"The user's job title\",\"avatar\":\"URL to the user's avatar image\",\"result_card\":\"A string used for client-side navigation\",\"citation\":\"A string used to identify the record in citations\",\"web_url\":\"Absolute URL to the user profile page in the Trainual web app (nil when account context is unavailable)\",\"__typename\":\"The type of the object (always 'User')\"}","children":"The users who directly report to this user in the organizational hierarchy (immediate subordinates only). Use this field to answer questions such as: \"Who reports to [user]?\", \"Who are [user]'s direct reports?\", \"Who does [user] manage?\", \"How many people report to [user]?\". Returns an empty array if the user has no direct reports. Each child user has the same structure as 'parent' above. Tip: to find a user's peers (others with the same manager), fetch the user's parent and then fetch the parent's children — that list, minus the user themselves, is the peer set.","groups":"Useful to determine the groups that the user is a member of and answer questions such as: What groups am I in? What groups is that user a part of? What groups is [specific user] a member of? A list of groups the user belongs to, Returns the following fields: {\"id\":\"The group's internal identifier\",\"name\":\"The name of the group. This is primary way that the UI and users identify the group.\\nIMPORTANT: Groups with name 'Everyone' are special system groups that automatically contain all users in the account.\\nThese groups cannot be deleted and their membership cannot be manually modified (users are automatically added/removed).\",\"description\":\"A brief description of the group\",\"kind\":\"The type of group, such as role, team, department, location, other\",\"web_url\":\"Absolute URL to the group page in the Trainual web app (nil when account context is unavailable)\",\"__typename\":\"The type of the object (always 'Group')\"}","time_zone":"The user's time zone","time_zone_info":"Detailed information about the user's time zone","start_date":"The date the user started, formatted as MM/DD/YYYY","birth_day":"The day of the month the user was born, as an integer (1-31). When answering questions about birthdays, combine this with birth_month to form a complete date (e.g., birth_day: 15, birth_month: 3 should be presented as 'March 15th'). Returns nil if not set or hidden.","birth_month":"The month the user was born, as an integer (1-12 where 1=January, 2=February, etc.). When answering questions about birthdays, combine this with birth_day to form a complete date (e.g., birth_day: 15, birth_month: 3 should be presented as 'March 15th'). Returns nil if not set or hidden.","software":"A list of software, tools, equipment that the user is directly assigned as an OWNER of. This field shows DIRECT ownership only. Users may also have access to additional software through their group memberships (check user.groups → group.software for complete picture). Useful for queries like: \"What software does [user] own?\", \"What tools is [user] responsible for managing?\". To answer \"What software does [user] USE?\" combine this field with software from all their groups. Structure: {\"id\":\"The software's internal identifier\",\"name\":\"The name of the software, tool, equipment, or vendor (e.g., \\\"Slack\\\", \\\"Zoom\\\", \\\"MacBook Pro\\\"). This is how users refer to the software in conversations. Software can be assigned in two ways: (1) Direct assignment to USERS (owners): Specific users are designated as owners of the software. (2) Assignment to GROUPS: All members of the group have access to/use the software. To answer queries about software: \\\"What software does [user] use?\\\" check user.software (shows direct ownership) PLUS any software assigned to groups the user belongs to. \\\"What software is assigned to [group]?\\\" check group.software (all members have access). \\\"Who uses [software]?\\\" check both direct owners AND groups assigned to it. Note on \\\"use\\\" vs \\\"own\\\": A user \\\"owns\\\" software if directly assigned as an owner. A user \\\"uses\\\" or \\\"has access to\\\" software if assigned via group membership.\",\"description\":\"A brief description of what this software is, what it does, or how it's used in the organization. May include setup instructions, access details, or usage guidelines.\",\"logo\":\"URL to the software or vendor logo image (if available)\",\"url\":\"URL to the software website, documentation, login page, or vendor information\",\"category\":\"The category of the software (e.g., 'Productivity', 'Communication', 'Development', 'Design'). Helps organize and filter software by type.\",\"resource_contents\":\"Array of attached content for this software (links and connected items). Structure: {\\\"id\\\":\\\"The resource content's internal identifier\\\",\\\"title\\\":\\\"The title of the attached content (falls back to the contentable title when present)\\\",\\\"url\\\":\\\"The URL for the attached content\\\",\\\"contentable_type\\\":\\\"The type of the contentable record associated with this attachment (if any)\\\",\\\"contentable_id\\\":\\\"The id of the contentable record associated with this attachment (if any)\\\",\\\"curriculum_type\\\":\\\"The curriculum type for this attachment (if any)\\\",\\\"citation\\\":\\\"The string used to identify the record in citations\\\",\\\"result_card\\\":\\\"The string used for client-side navigation\\\",\\\"__typename\\\":\\\"The type of the object (always 'ResourceContent')\\\"}\",\"owners\":\"Array of users who are designated as owners/managers of this software\",\"groups\":\"Array of groups that have access to this software (all group members can use it)\",\"__typename\":\"The type of the object (always 'Software')\"}","responsibilities":"The COMPLETE set of responsibilities this user holds — both those assigned directly to the user and those inherited through their group memberships. Answers \"What are all of [user]'s responsibilities?\" / \"What is [user] responsible for?\" with no need to separately fetch group responsibilities. Each item carries an `assignment_source` ('direct' when assigned to the user individually, 'group' when inherited via a group) and `via_groups` (the groups the responsibility is inherited through, each with id and name; empty array when the responsibility is direct-only). A responsibility assigned both directly and via a group has source 'direct' and still lists that group in `via_groups`. Structure: each item has {\"id\":\"The responsibility's internal identifier\",\"name\":\"The name of the responsibility. This is the primary way users identify responsibilities.\\n\\nA responsibility is a task or role that users are expected to perform. Responsibilities are assigned to users or groups,\\nand inherit to all members of the group. Useful for queries like: \\\"What is [user] responsible for?\\\",\\n\\\"What responsibilities does the [group name] have?\\\",\\n\\\"Who is responsible for [responsibility name]?\\\" (check which groups have it).\\n\\nIMPORTANT - How Responsibilities Are Assigned:\\nResponsibilities can be assigned to both individual users AND groups.\\nWhen assigned to a GROUP: All members of that group inherit the responsibility.\\nWhen assigned to a USER: Only that specific user has the responsibility.\\n\\nTo answer queries about responsibilities: \\\"What is [user] responsible for?\\\" check user.responsibilities (direct assignments)\\nAND all responsibilities from their groups. \\\"What is everyone in [group] responsible for?\\\" check group.responsibilities\\n(applies to all members). \\\"Who is responsible for X?\\\" search users/groups with that responsibility.\",\"description\":\"A brief description of what this responsibility entails, including any relevant context about the work or expectations.\",\"__typename\":\"The type of the object (always 'Responsibility')\"} plus \"assignment_source\" ('direct' or 'group') and \"via_groups\" (array of { id, name }).","skills":"A list of skills the user has self-listed on their profile (e.g., 'Product Strategy', 'Data Analysis'). Use to answer questions like 'What are [user]'s skills?', 'Who on the team has experience with X?', or to aggregate skills across a group. Returns the following fields: {\"id\":\"The skill's internal identifier\",\"title\":\"The name of the skill (e.g., 'Product Strategy', 'Roadmapping', 'Data Analysis'). Skills are user-listed competencies on their profile, useful for answering questions like 'What are [user]'s skills?' or 'Who has experience with [skill]?'.\",\"__typename\":\"The type of the object (always 'Skill')\"}","hashtags":"The user's interests — hobbies, passions, or out-of-work topics they have self-tagged on their profile. Render inline as small chips beneath the bio in the UI. When phrasing responses, always refer to these as the user's \"interests\". Use to answer 'What are [user]'s interests?', 'Who else is into [topic]?', or to find shared interests between users. When answering broad interest questions, also consider the user's bio — interests may be described in prose there. Returns the following fields: {\"id\":\"Internal identifier for this interest record\",\"title\":\"The interest term, without any leading '#' (e.g., 'golf', 'travel', 'cycling'). These are hobbies, passions, or out-of-work topics the user has tagged themselves with. The profile UI renders them as small inline chips beneath the user's bio (no section label). When phrasing responses, refer to these as the user's \\\"interests\\\". Useful for questions like 'What are [user]'s interests?', 'Who else is into [topic]?', or finding shared interests between users. Bio text may also describe interests in prose — consider both this structured list and the bio when answering interest questions.\",\"__typename\":\"The type of the object (always 'Interest')\"}","user_roles":"The user's role history at the company — past and current job titles with their start and end dates. Surfaced on the profile UI as the \"Role history\" section; the current role is labeled \"Present\" rather than showing an end date. Phrase responses using \"role history\". Use to answer 'What roles has [user] held?', 'When did [user] become X?', or 'Who has been here since before \u003cyear\u003e?'. Returns the following fields: {\"id\":\"The role record's internal identifier\",\"title\":\"The job title held during this role (e.g., \\\"VP of Product\\\", \\\"Senior Engineer\\\")\",\"start_date\":\"The date the user started this role, formatted as YYYY-MM-DD\",\"end_date\":\"The date the user ended this role, formatted as YYYY-MM-DD. Returns nil for the user's current role (see is_current).\",\"is_current\":\"True for the role the user holds today; false for past roles in their history. The profile UI labels the current role as \\\"Present\\\" — mirror that phrasing in responses.\",\"__typename\":\"The type of the object (always 'UserRole')\"}","abilities":"The permissions/capabilities the current user has for this user. Includes 'update' (fields that can be updated) and 'delete' (whether the user can be deleted).","permission":"The user's permission level in Trainual. Internal identifier — never show the raw value to users. When narrating, render 'general' as \"General\", 'contributor' as \"Contributor\", 'author' as \"Author\", 'admin' as \"Admin\", 'billing_admin' as \"Billing Admin\". Capabilities are cumulative (General \u003c Contributor \u003c Author \u003c Admin \u003c Billing Admin). Use to answer \"What is [user]'s permission level?\", \"Is [user] an admin?\", or \"Who can create/assign content?\"."}

fetch_users

Retrieves praise and private feedback records the user is entitled to see, with the raw feedback text, participants, visibility, and timestamps. Read-only. Domain: - Public praise: positive recognition visible to the whole account. One or many recipients. - Private feedback: exactly one recipient, with a visibility tier: 'private' (author + recipient), 'private_plus_manager' (author + recipient + recipient's manager), or 'manager_only' (author + recipient's manager — the recipient cannot see it and it never appears in their own "received" results — EXCEPT for users with account-wide performance access (billing admins and admins with full performance access), who see all records including manager_only feedback about themselves). - Entitlement is enforced per record for the requesting user; results may legitimately be empty for records other users can see. - Sentiment and themes are NOT stored. Retrieve the records and infer them from the text. - People-feedback ONLY: praise and private feedback exchanged between people. NOT reports of problems with training content — content feedback is a training-content concept and is not retrievable through this tool; say so rather than reporting that none exists. Also NOT a manager's private observations about a person (visible only to the author who wrote them) — those are fetch_performance_notes. Common use cases: - "Show me feedback I've received" → relationship: 'received' - "Show me public praise I've given" → relationship: 'given', feedback_type: 'praise' - "Show me feedback Taylor has given Dani" → author_ids + recipient_ids (resolve names first) - "What are the feedback trends for my team this year?" → recipient_ids + created_after, then synthesize from the returned text FILTERS (all optional, combined with AND): - ids: Fetch specific feedback records by ID directly, e.g. a feedback_id returned from fetch_feedback_requests. Entitlement is still enforced — an ID you're not entitled to see is silently excluded. - feedback_type: 'praise' (public recognition) or 'private_feedback' (the private tiers). Deterministic — praise returns exactly the public records. OMIT feedback_type unless the user distinguishes praise from private/constructive feedback; plain "feedback" means both. - relationship: the requesting user's OWN relationship to the feedback — 'given' (they authored), 'received' (they are a recipient), 'involving' (either). Omit for no relationship constraint (e.g. company-wide questions). - author_ids / recipient_ids: filter by who gave / who received. Use fetch_users and fetch_groups FIRST to resolve names, groups, or "team" references to user IDs. For "my team": a people-manager means their direct reports (fetch_users include: children); a group manager means members of the groups they manage. For a user who is BOTH: a brief that covers both scopes is fully specified — fetch both and label results by scope; a brief naming neither warrants one clarifying question — never pick one scope silently. When "team" cannot be resolved at all, ask rather than guess. For SOMEONE ELSE's received feedback ("what feedback has Dani received?"), pass recipient_ids ONLY and OMIT relationship — 'received' always means received BY THE REQUESTING USER, so combining relationship: 'received' with recipient_ids for another person demands records that are both; the tool returns an error if you do (symmetric for relationship: 'given' with author_ids). - visibility: explicit visibility tiers to include. - created_after / created_before: ISO 8601 datetimes. Any window works (last month, last 2 years). Do NOT pass either unless the user asks about a time period — an unqualified question ("praise I've given", "summarize my feedback") means ALL TIME; adding your own window silently hides older records the user asked for. - query: a single search term matched against the feedback text and participant names. PAGINATION: results are newest-first. If has_more is true, call again with cursor: next_cursor until has_more is false — retrieve ALL pages before running any analysis or synthesis, otherwise your answer is based on a partial dataset. total_count is the full entitled count for the current filters. A cursor is only valid for the SAME filters it was returned from — an invalid or mismatched cursor returns an error telling you to retry without it (omit cursor to restart from the first page). Returns {"feedback": [...], "total_count": n, "has_more": bool, "next_cursor": str|null}. Each record: {"id":"The feedback record's internal identifier","feedback_type":"'praise' (public recognition, visible to the whole account) or 'private_feedback' (constructive or positive feedback with restricted visibility)","visibility":"Who can see this record: 'public' (everyone), 'private' (author + recipient), 'private_plus_manager' (author + recipient + recipient's manager), 'manager_only' (author + recipient's manager; hidden from the recipient unless they hold account-wide performance access)","text":"The feedback message as plain text. Sentiment/themes are NOT stored — infer them from this text.","author":"The user who gave the feedback. Structure: {\"id\":\"The user's internal identifier\",\"name\":\"The user's full name\",\"job_title\":\"The user's job title\",\"avatar\":\"URL to the user's avatar image\",\"result_card\":\"A string used for client-side navigation\",\"citation\":\"A string used to identify the record in citations\",\"web_url\":\"Absolute URL to the user profile page in the Trainual web app (nil when account context is unavailable)\",\"__typename\":\"The type of the object (always 'User')\"}","recipients":"The users this feedback is about. Praise may have many recipients; private feedback has exactly one. Structure: {\"id\":\"The user's internal identifier\",\"name\":\"The user's full name\",\"job_title\":\"The user's job title\",\"avatar\":\"URL to the user's avatar image\",\"result_card\":\"A string used for client-side navigation\",\"citation\":\"A string used to identify the record in citations\",\"web_url\":\"Absolute URL to the user profile page in the Trainual web app (nil when account context is unavailable)\",\"__typename\":\"The type of the object (always 'User')\"}","in_response_to_request_id":"The feedback request ID this record fulfills, or null if given unprompted. The request itself is only retrievable by its sender or invited responders (via fetch_feedback_requests).","created_at":"When the feedback was given (ISO 8601)","result_card":"Not available for feedback (always null)","citation":"A string used to identify the record in citations","web_url":"Absolute URL to the Feedback page in the Trainual web app","__typename":"The type of the object (always 'PerformanceFeedback')"}

fetch_feedback

Read-only. Retrieves responsibility information — names, descriptions, and (optionally) assigned groups and users — by ID(s) or search terms. Domain: - Responsibilities can be assigned to individual users OR groups. When assigned to a GROUP, all members inherit it; when assigned to a USER, only that user has it. A user can hold responsibilities both directly and through group membership. NOT for "What are [person]'s responsibilities?" — this tool has no person filter (ids and queries only). Use fetch_users with include: responsibilities for a named person, or call this tool unfiltered with include: ['effective_users'] and find the person in the results. Common use cases: - "Who is responsible for [X]?" — search for the responsibility, then request include: ['effective_users'] to list the actual people responsible (it expands group members, not just the assigned groups; responsibility_assignees does not). - Get all responsibilities (no parameters), or by ID, or by search term. Parameter Usage: - No parameters: Returns ALL responsibilities in the account - ids only: Returns responsibilities matching the specified IDs - queries only: Returns responsibilities matching the search terms (name or description) - ids AND queries: Returns the INTERSECTION - only responsibilities that match BOTH the IDs AND the search terms - Multiple search terms can be provided so that multiple variations can be matched **Optional includes**: • responsibility_assignees - Users and groups directly assigned to this responsibility • effective_users - All individuals responsible (direct user assignees plus members of assigned groups). Use to answer "Who is responsible for [X]?" with actual people. Returns the following fields: {"id":"The responsibility's internal identifier","name":"The name of the responsibility. This is the primary way users identify responsibilities.\n\nA responsibility is a task or role that users are expected to perform. Responsibilities can be assigned to both\nindividual users AND groups. When assigned to a group, all members of that group inherit the responsibility.","description":"A brief description of what this responsibility entails, including any relevant context about the work or expectations.","responsibility_assignees":"Array of all assignees records showing how this responsibility is assigned to users and groups with the following fields: {\"id\":\"The assigned responsibility's internal identifier\",\"type\":\"The type of entity this responsibility is assigned to (either 'User' or 'Group')\",\"assigned_to\":\"The user or group to which this responsibility is assigned. User fields: {\\\"id\\\":\\\"The user's internal identifier\\\",\\\"name\\\":\\\"The user's full name\\\",\\\"job_title\\\":\\\"The user's job title\\\",\\\"avatar\\\":\\\"URL to the user's avatar image\\\",\\\"result_card\\\":\\\"A string used for client-side navigation\\\",\\\"citation\\\":\\\"A string used to identify the record in citations\\\",\\\"web_url\\\":\\\"Absolute URL to the user profile page in the Trainual web app (nil when account context is unavailable)\\\",\\\"__typename\\\":\\\"The type of the object (always 'User')\\\"}, Group fields: {\\\"id\\\":\\\"The group's internal identifier\\\",\\\"name\\\":\\\"The name of the group. This is primary way that the UI and users identify the group.\\\\nIMPORTANT: Groups with name 'Everyone' are special system groups that automatically contain all users in the account.\\\\nThese groups cannot be deleted and their membership cannot be manually modified (users are automatically added/removed).\\\",\\\"description\\\":\\\"A brief description of the group\\\",\\\"kind\\\":\\\"The type of group, such as role, team, department, location, other\\\",\\\"web_url\\\":\\\"Absolute URL to the group page in the Trainual web app (nil when account context is unavailable)\\\",\\\"__typename\\\":\\\"The type of the object (always 'Group')\\\"}\",\"assigned_at\":\"The date/time this responsibility was assigned (i.e. when the user or group gained it), formatted as ISO 8601\"}","effective_users":"All individuals responsible for this — the direct user assignees plus the members of any assigned groups, deduplicated. Use to answer \"who is responsible for [X]?\" with the actual people (it expands group members), rather than listing the assigned groups. Returns the following fields: {\"id\":\"The user's internal identifier\",\"name\":\"The user's full name\",\"job_title\":\"The user's job title\",\"avatar\":\"URL to the user's avatar image\",\"result_card\":\"A string used for client-side navigation\",\"citation\":\"A string used to identify the record in citations\",\"web_url\":\"Absolute URL to the user profile page in the Trainual web app (nil when account context is unavailable)\",\"__typename\":\"The type of the object (always 'User')\"}"}

fetch_responsibilities