Teamspective

Returns feedback activity metrics for a team: requests, fulfillment rates, praise counts, and per-person breakdown. **When to use:** - "How many feedback requests were sent?" or "What's our fulfillment rate?" - "How active is our feedback culture?" or "Who's most active in giving feedback?" - "Show me feedback statistics for last quarter" - Comparing feedback activity across teams (call for each team) **What it returns:** - Aggregate stats: total requests, fulfilled count, fulfillment rate %, praise count - Unique participants: how many people are requesting vs providing - Per-person breakdown: requests sent, fulfilled, feedback provided, praise sent **Permission behavior:** - Admins with `accessFeedbackStats` see full team data - Managers without team-level access see stats for their managed users only **Distinct from `get_feedback`:** - This tool answers "How active is feedback?" (quantitative metrics) - `get_feedback` answers "What does the feedback say?" (qualitative content) **Examples:** - "Feedback stats for the company" -> { } - "Engineering feedback activity last year" -> { "team": "Engineering", "time_range": "last_year" } - "Last 30 days feedback" -> { "time_range": "last_30_days" }

get_feedback_statistics

Returns the organization's team hierarchy and available segments, showing all teams the user has visibility into. **When to use:** - "Show me the organization" or "What teams exist?" - "What teams can I look at?" or "Show me the team structure" - "What segments are available?" or "Show me departments/locations" - Before querying specific teams for engagement or feedback data (to discover team IDs) - Before filtering engagement by segment (to discover segment attribute keys and values) - When an admin needs to navigate the organization to find specific departments **What it returns:** - Hierarchical tree of all teams the user can access (based on engagement + feedback permissions) - Team names and IDs (use IDs in subsequent tool calls for reliable lookups) - Indentation showing parent-child relationships - Total count of visible teams - Available segments with attribute keys and values (for admins and segment managers) **Relationship to other tools:** - Use this tool to discover team IDs, then use those IDs with: - `get_engagement_results` for survey scores and themes - `get_feedback_statistics` for feedback activity metrics - `get_engagement_statistics` reports live response rates for open surveys (no team argument — it covers the caller's own reports) - Use segment attribute/value pairs with `get_engagement_results` for segment-filtered results - `get_user_context` shows the user's own teams; this tool shows the full org structure they can access **Examples:** - "Show me the full org" -> { } - "Show Engineering sub-teams" -> { "team": "Engineering" } or { "team": 12345 }

get_workspace_overview

Returns workspace-scoped context for another user: their role description, home team, and their relationship to you. All of it is what every workspace member can see of a colleague in Teamspective. **When to use:** - "Who is Jaakko? What's his role?" → resolve their user_id with search_users first, then call this - Drafting feedback / 1:1 notes / praise where knowing the target's role would inform tone and content - Determining how you relate to the target (manager / direct_report / peer / etc) before composing a message **Not for:** - Your own profile. Use get_user_context for that. - A colleague's focus areas. They are visible only inside a feedback request you take part in: read them from the Topics of `get_feedback_requests({ request_id })`. If there is no such request, tell the user the focus areas are not available to you and do not guess them. **Relationship values returned:** - `manager` — target manages you (directly or as a segment manager of a segment you're in) - `direct_report` — you manage target (directly or as a segment manager of a segment they're in) - `secondary_manager` — target is your horizontal-lead / mentor (a secondary manager kind) - `secondary_report` — you are target's horizontal-lead / mentor - `peer` — you share a direct manager with the target - `colleague` — workspace member with no closer link - `external` — target is not a workspace member (only name + ID returned) **Common errors:** - "No user found with ID X": user does not exist. Use search_users to find user IDs by name. - "That user_id is the caller themselves": caller passed their own user_id. Use get_user_context for self. **Example:** `{ "user_id": 12345 }`

get_person_context

Returns the authenticated user's identity, role, teams, and data access permissions. **IMPORTANT: Call this tool first**, at the start of every conversation, before using other Teamspective tools. It provides essential context about who you're speaking with and what data they can access. **When to use:** - Before calling get_engagement_results (to know which teams they can query) - Before calling get_feedback with target: "direct_reports" (to confirm they're a manager) - When user asks "who am I?", "what's my team?", or about their profile **Returns:** - Identity: name, email, numeric user ID - Role: "Manager" (has direct reports) or "Individual Contributor" - Profile attributes: job title, department, location (from HRIS, if available) - Workspace profile: role title, level, start date, and role description (if set) - Home team: their primary team with team ID (use this ID in other tools) - Direct reports: list with names, emails, and user IDs (if manager) - use these IDs with get_feedback - Teams: all teams they belong to with team IDs - Engagement access: count of teams they can query for engagement results - Segment access: whether they can filter engagement by segments (e.g., Department, Location) - Teamspective navigation: the user's app language, the engagement menu labels and URLs this user can open, where surveys are answered on web, Slack and MS Teams, and the user's open surveys under their card titles. Use these exact labels and titles whenever you tell the user where to go. - Company principles documents: list of workspace knowledge resources with document type (call get_file with file ID to read content) **Key concepts:** - "Workspace" = the organization/company in Teamspective - "Team" = a group within the workspace (e.g., Engineering, Sales) - "Home team" = the user's primary team, used as default when no team is specified - Team IDs are numeric (e.g., 12345) and more reliable than team names for queries **Navigating the organization:** - This tool shows the user's own teams. For the full org structure, use `get_workspace_overview`. - Admins who can see many teams should use `get_workspace_overview` to discover team IDs. **Example:** User says "How is my team doing?" → Take their home team ID from the user context, then call get_engagement_results with that team ID.

get_user_context

List actions in the workspace or get a single action by ID or number. **When to use:** - "Show me my actions" or "What actions do I have?" - "List all active actions" or "Show todo actions" - "Get action ACT-123" or "Show action 456" - "Actions assigned to [person]" - "Team actions for Engineering" **Action statuses:** - draft: Not yet visible to others - todo: Ready to be worked on - active: Currently being worked on - done: Completed - canceled: No longer needed **Getting a single action:** - Use task_id for numeric ID lookup (e.g., task_id: 123) - Use task_number for action number lookup (e.g., task_number: "ACT-123") - Single action view includes full description **Filtering actions:** - status: Filter by action status (todo, active, done, etc.) - assignee: Filter by assignee (user ID or name) - team: Filter by team (team ID or name) — actions assigned to a member of the team or any team under it, plus actions that belong to the team itself - limit: Maximum number of actions to return (default: 20) **Examples with exact parameters:** - "My actions" → { "assignee": "me" } - "Active actions" → { "status": "active" } - "Action ACT-42" → { "task_number": "ACT-42" } - "Actions for John" → { "assignee": "John" } - "Engineering team actions" → { "team": "Engineering" }

tasks_list

Lists the organization's cycles (e.g. "2026 H1", "Q3 2025") and process types (e.g. "Annual review", "Probation review"). Admins label structured feedback with them, and get_feedback filters by them. **When to use:** - Before calling get_feedback with `cycle` or `process_type`, to find the exact name or the ID - "Which review cycles do we have?" / "What kinds of reviews does the organization run?" - When the user names a cycle or process type that get_feedback did not recognise **What you get:** - Every cycle and process type with its ID. Archived ones are marked "archived"; they still appear on old feedback and can still be used as a filter. **Examples:** - All tags → `{}` - Only cycles → `{ "kind": "cycle" }` - Only process types → `{ "kind": "process_type" }`

get_performance_tags

List available discussion templates for the workspace. Discussion templates define the structure for 1:1 meeting agendas, feedback call agendas, and other recurring discussion formats. **IMPORTANT: Read templates BEFORE creating 1:1 agendas or discussion notes.** Templates contain the workspace's preferred structure for different meeting types. When preparing a 1:1 agenda, calendar event, or discussion, always check templates first and incorporate their structure into your suggestions. **When to use:** - Before creating a discussion with discussions_save (to see available agenda structures) - Before suggesting a 1:1 agenda or meeting preparation notes - When the user asks "What discussion templates are available?" - When preparing for any recurring meeting format **Returns:** - Template name, type (default or workspace-specific), and full content - Default templates are built-in; workspace templates are custom to the organization **Examples:** - List all templates → `{}`

get_discussion_templates

List available document templates for the workspace. Use this tool to discover which templates exist before creating a document with documents_update_or_create. **When to use:** - Before creating a new document, to see which templates are available - When the user asks "What document types can I create?" - To get the template ID needed for document creation **Returns:** - Template name, ID, type key, and whether self-creation is allowed - Use the template ID (number) when calling documents_update_or_create

get_document_templates

Returns the feedback requests visible to the caller: everything other people want from them. This is the single answer to "what feedback requests do I have" or "what's on my plate". In list mode it unifies BOTH growth feedback requests AND pending structured feedback the caller has been asked to give, so you do not need a separate call to cover structured feedback. This one tool covers list and both detail kinds: - No id → the unified list. - `request_id` → full detail for one GROWTH request. - `structured_feedback_id` → full detail for one STRUCTURED feedback request: its questions, each scale with the exact accepted values, and any drafted answers — everything answer_structured_feedback needs. (The list gives you the structured_feedback_id for each pending structured item.) **When to use:** - "What feedback requests do I have to respond to?" → defaults (status: pending, direction: received). Returns both growth and structured. - "Show me request 1234" → pass request_id (growth detail) - "Let me answer my structured feedback for April" → pass structured_feedback_id from the list to get the questions, then call answer_structured_feedback - "Have I given Sarah feedback before?" → counterpart_user_id + status: all - "What requests have I sent out?" → direction: provided (growth only; structured is not included for this direction) **Scope note:** structured feedback is included in list mode only for the received direction and pending/all statuses (it represents what others are waiting on from you). The provided direction covers growth feedback only. **Status values:** - `pending`: the request has not been responded to (the provider has either not started or has only a draft saved) - `fulfilled`: the feedback has been provided - `all`: both **Direction values (relative to the caller):** - `received`: requests where the caller is the feedback provider (someone asked them for feedback) - `provided`: requests where the caller is the requester (they asked someone for feedback) - `all`: both **Common errors:** - "No accessible feedback request with ID X": the request may not exist or belong to another workspace, or the caller is not a participant on it. Don't retry; ask the user to check the URL or use the list mode without `request_id`. **Examples:** - "What's on my plate?" → `{}` (defaults to pending received) - "Detail of request 42" → `{ "request_id": 42 }` - "My open requests to Jaakko" → `{ "direction": "provided", "counterpart_user_id": <jaakko's user_id> }`

get_feedback_requests

List questions from the workspace question bank. ALWAYS use this before creating a survey — prefer reusing existing questions over creating new ones. **Output per question:** ID (use in save_survey), name, title text, scale, theme, KPI, and when last asked.

list_questions

Discover surveys, recurring surveys, and survey programs in the workspace. Default kind="all" returns three sections (single, recurring, program); narrow with kind. With id you also MUST pass kind: "single" returns full question content, "recurring" returns the question schedule for upcoming rounds with per-question targeting, plus its completed rounds (newest first, up to the most recent 300) with each Round ID for `survey_context.round_ids` in get_engagement_results, when the caller can see results; "program" returns program metadata.

list_surveys

Fetch a company principles file by resource ID and return its content. **When to use:** - When you need to read the actual content of a company principles document - Content is pre-extracted and stored in the database for fast access **Input:** - resourceId: The numeric ID of the company principles resource (from get_user_context) **Returns:** - Pre-extracted text content ready for analysis **Descriptions are only an index:** read potentially relevant content before concluding the company has no guidance on a topic. **Example workflow:** 1. Take the resourceId from the company knowledge document list in the user context (the list get_user_context returns) 2. Call get_file with the resourceId of the document you want to read 3. Analyze the returned text content

get_file

List and read 1:1 or team discussions. Discussions are meeting containers with rich-text notes and threaded comments, used for 1:1s, team meetings, and other recurring conversations. **When to use:** - "Show my discussions" or "What 1:1s do I have?" - "Show notes from my discussion with [person]" - "What was discussed in [discussion name]?" - Preparing for a 1:1 or reviewing past meeting notes - Looking for action items from discussions **How it works:** - **List mode** (no discussion_id): Returns compact summaries — names, participants, note/comment counts with latest note date, last activity date. Use this first to find the discussion you need. - **Detail mode** (discussion_id provided): Returns filtered notes (by time period and limit) with full content, note IDs, and comments. Note IDs are needed for updating notes via discussions_save. **Permissions:** You can see discussions where you are a participant, or where you manage a participant (as their manager/admin). **Parameters:** - `discussion_id`: (optional) Fetch a specific discussion with full notes and comments. Get IDs from list mode. - `include_archived`: (optional, default: false) Include archived discussions in listing. - `limit`: (optional, default: 20) Max items to return — discussions in list mode, notes in detail mode. - `time_period_days`: (optional, default: 90) How many days back to look for note activity in detail mode. Notes with recent comments/edits are included even if the note was created earlier. Aligned with feedback tools (default: ~3 months). **Examples:** - List all active discussions → `{}` - List including archived → `{ "include_archived": true }` - Read a specific discussion (recent notes) → `{ "discussion_id": 42 }` - Read more notes → `{ "discussion_id": 42, "limit": 30, "time_period_days": 180 }` - Read older notes (last year) → `{ "discussion_id": 42, "limit": 100, "time_period_days": 365 }` **Common errors:** - "Discussion not found or you don't have access": The discussion doesn't exist or you're not a participant/manager. Use get_discussions without discussion_id to see accessible discussions.

get_discussions

List and read personal development documents. Documents are personal development docs (IDPs, performance assessments, individual targets) created from templates, with a draft → approved workflow and optional manager review. **When to use:** - "Show my documents" or "What IDPs do I have?" - "Show [person]'s development plan" - "What documents need review?" - "What documents have been shared with me?" - "How many HQ employees have completed their performance assessment?" - Reviewing document content before a 1:1 discussion - Checking document status (draft, approved, archived) - Getting document completion stats for a segment **How it works:** - **List mode** (no document_id): Returns users with their documents (type, template name, status, updated date) plus a per-status summary with counts and percentages. No content in list mode. Token-efficient for browsing. - **Shared with me mode** (shared_with_me: true): Shows documents that others have shared with you (directly or via segments), excluding users you already see in the default listing. Useful for discovering documents from people outside your management chain. - **Detail mode** (document_id provided): Returns full document content as plain text, template info, approval status, reviewer info. Provide the `user` parameter to identify the document owner (defaults to self if omitted). **Filtering by segment and document type (admin only):** To answer "How many people in [segment] have completed their [document type]?": 1. Use `get_workspace_overview` to find the segment ID for the target group 2. Use `get_document_templates` to find the document type key (e.g., "performance_assessment") 3. Call `get_documents` with `segment_id` and/or `document_type` to get filtered stats **Permissions:** - You always see your own documents - Managers see documents of their direct reports - Admins see all users but documents they have no share access to appear as private - Shared-with-me shows documents explicitly shared with you, from users outside your normal view - `segment_id` filter is admin-only. Non-admins get a clear error. **Parameters:** - `document_id`: (optional) Fetch a specific document with full content. Get IDs from list mode. - `user`: (optional) Filter by user (numeric ID preferred, or name). Defaults to showing all accessible users. Cannot be combined with shared_with_me. - `status`: (optional) Filter by status: "all", "no-document" (users without documents), "draft", "pending-review", "approved", "archived". Default shows all. Note: "no-document" is not available in shared-with-me mode. - `shared_with_me`: (optional, default: false) When true, shows documents shared with you by others outside your normal management view. Cannot be combined with the user filter. - `segment_id`: (optional, admin only) Filter by segment. Get segment IDs from `get_workspace_overview`. Returns forbidden for non-admins. - `document_type`: (optional) Filter by document type key (e.g., "performance_assessment", "idp"). Get type keys from `get_document_templates`. - `limit`: (optional, default: 20) Max users to return in listing. **Examples:** - List all documents → `{}` - Documents for a specific person → `{ "user": "Sarah" }` or `{ "user": 12345 }` - Only draft documents → `{ "status": "draft" }` - Documents shared with me → `{ "shared_with_me": true }` - Shared drafts needing attention → `{ "shared_with_me": true, "status": "draft" }` - Read specific document → `{ "document_id": 42, "user": 12345 }` - Stats for HQ segment's performance assessments → `{ "segment_id": 456, "document_type": "performance_assessment" }` - Who hasn't started in a segment → `{ "segment_id": 456, "document_type": "performance_assessment", "status": "no-document" }` **Common errors:** - "Document not found": The document doesn't exist or you don't have access. Use get_documents without document_id to see available documents. - "No user found matching X": The name doesn't match. Use search_users for IDs. - "Access denied": You don't have admin permission for segment filtering. Non-admins should use the `user` parameter instead.

get_documents

Returns engagement survey comments and open-text responses. Use this to understand the "why" behind engagement scores. **PREREQUISITE: Call get_user_context first** to confirm the user has access to engagement comments. **When to use:** - After seeing low or concerning scores in get_engagement_results - "What are people saying about [topic]?" - "Show me recent feedback comments" - "Why is [metric] score low?" - look at related comments - Preparing for team discussions or action planning **What you get:** - Comment text with question context - Date and recency (latest survey indicator) - Sentiment analysis (Positive or Negative when available) - Reply count for each comment - Grouped by question for easy reading - An Analysis Summary whose counts can be incomplete. When it reports comments not analyzed yet, the sentiment counts do not cover those comments, so say so rather than reading the counts as the whole picture. **Filtering options:** - Filter by team (same as get_engagement_results) - Filter by segment with segment_attribute + segment_value (e.g., an HRIS department) — cannot be combined with team - Filter by specific question, theme, or KPI (recommended for topic-based queries) - Text search for specific words (use with caution - see below) - Adjust time period to see older/newer comments **Text search limitations (search_text parameter):** - Literal text matching only, not semantic/AI search - Case-insensitive but language-dependent - Comments are often in the workspace's local language (Finnish, Swedish, etc.) - Searching English terms in non-English workspaces will return no results - Prefer question/theme/kpi filters for topic-based filtering **Privacy:** - Comments are anonymous - no author information - Visibility rules are respected (workspace/team/admin-only) - Only shows comments the user is authorized to see - Segment filtering requires permission to view that segment's results (admins and segment managers) **Example workflow:** 1. Call get_engagement_results → see "Workload" score is 54 (low) 2. Call get_engagement_comments with question: "Workload" to understand why 3. Summarize themes from comments for actionable insights **Examples with exact parameters:** - "Recent comments" → { "time_period_days": 30 } - "Comments about workload" → { "question": "Workload" } (preferred) - "Leadership theme feedback" → { "theme": "Leadership" } - "Engineering team comments" → { "team": "Engineering" } - "Product Management department comments" → { "segment_attribute": "Department", "segment_value": "Product Management" } - "Wellbeing KPI feedback" → { "kpi": "Wellbeing" } - "Comments mentioning 'manager'" → { "search_text": "manager" } (use sparingly, language-dependent)

get_engagement_comments

Returns feedback data for the user, their direct reports, a specific managed employee, or an entire team. Includes growth feedback, praise, and structured feedback with full text content. **PREREQUISITE: Call get_user_context first** to understand the user's role and permissions before choosing a target. **When to use:** - "Show me my feedback" or "What feedback have I received?" - "How is [person] doing?" (for managed employees) - "Team feedback summary" or "feedback trends" - "Show feedback for the Engineering team" (admin-only) - "Summarize Sarah's 2026 H1 review" (a review cycle: pass `cycle`) - Preparing for 1-on-1s or performance discussions **Understanding feedback types:** - Growth feedback: Developmental feedback with specific observations and suggestions - Praise: Recognition and positive feedback - Structured feedback: Responses to structured feedback questionnaires. Each item carries its evaluation type (self, manager, peer, employee, external, other), and the cycle (e.g. "2026 H1") and process type (e.g. "Annual review") the organization tagged it with. **What you get:** - Full text content of each feedback item - Provider name (who gave the feedback) - Timestamp and topic/category - Feedback type (growth, praise, structured feedback); for structured feedback also the evaluation type, cycle and process type **Filtering structured feedback by cycle, process type or evaluation type:** - `cycle` and `process_type` take a tag ID (preferred) or the exact tag name. Archived tags work the same as active ones. Use get_performance_tags to list the organization's cycles and process types with their IDs. - A `cycle` or `process_type` filter REPLACES `time_period_days`: the tag decides what belongs together, so feedback older than the day window is included and the window is ignored. - `evaluation_type` narrows to one relationship, always seen from the person whose feedback is read: "self" is their own self-reflection, "employee" is feedback they received from their manager (Manager-to-employee), "manager" is feedback they received from their direct reports about them as a manager (Employee-to-manager), "peer" is from a colleague, "external" from outside the organization, "other" from another colleague. It combines with the day window unless a cycle or process type is also set. - Any of these three filters returns structured feedback ONLY. Growth feedback and praise carry no tags, so they are left out of a filtered result. - A cycle filter on a single person (self, user, or one direct report) returns every item in that cycle with no per-person cap. Several direct reports or a team keep the per-person cap. - A cycle or process type name that matches nothing is an error, never a fallback to unfiltered feedback. Fix the name or pass the ID from get_performance_tags. **Targets and permissions:** - `self`: Always available — user's own feedback - `direct_reports`: Available to managers — feedback for all or a specific direct report (use subject to filter) - `user`: Available to managers/admins — feedback for a specific managed employee (requires manageUserFeedback permission) - `team`: Admin/observer only — feedback for all members of a team **The `subject` parameter:** - For target "direct_reports": optional filter — user ID or name of a specific direct report - For target "user": required — user ID (preferred) or name of the employee - For target "team": required — team ID (preferred) or team name - Numeric IDs are more reliable than names for all lookups. Get IDs from get_user_context or get_workspace_overview. **Common errors:** - "No direct reports found matching X": The name doesn't match any of your direct reports. Use get_user_context to see your direct reports. - "You don't have permission to view feedback for X": You don't manage this user's feedback. - "Team-level feedback requires workspace admin or observer role": Only admins/observers can use target: "team". - "No cycle named X" / "No process type named X": The tag name does not exist. Call get_performance_tags and retry with the exact name or the ID. **Examples with exact parameters:** - "My recent feedback" → { "target": "self", "time_period_days": 30 } - "Sarah's feedback (direct report)" → { "target": "direct_reports", "subject": "Sarah" } - "Feedback for user 12345" → { "target": "user", "subject": 12345 } - "Feedback for Sarah (managed)" → { "target": "user", "subject": "Sarah" } - "Engineering team feedback" → { "target": "team", "subject": "Engineering" } - "All direct reports feedback this quarter" → { "target": "direct_reports", "time_period_days": 90 } - "Summarize Sarah's 2026 H1 review" → { "target": "user", "subject": "Sarah", "cycle": "2026 H1" } - "My self-reflection from the annual review" → { "target": "self", "process_type": "Annual review", "evaluation_type": "self" } - "Peer feedback for my direct reports in cycle 42" → { "target": "direct_reports", "cycle": 42, "evaluation_type": "peer" }

get_feedback

Returns the authenticated user's own engagement survey answers, grouped by question with chronological history and trend indicators. **When to use:** - "How have my engagement answers changed?" or "Show me my pulse history" - "What did I answer about work-life balance?" or "What was my last engagement response?" - "Show me my answers" or "How have I been feeling at work?" - Self-reflection and personal engagement tracking **What it returns:** - Answers grouped by question, sorted by most recently answered - For each question: chronological answer history with dates and values - Choice labels (e.g., "4 - Agree" instead of just "4") - Comments attached to answers - Trend indicators: 📈 improved, 📉 declined, ➡️ stable **Access requirements:** - The workspace must have "My Answers" enabled (workspace setting) - Returns only the calling user's own answers (no one else's data) **Distinct from `get_engagement_results`:** - This tool shows the user's personal answers (individual level) - `get_engagement_results` shows team-level aggregated scores and themes **Examples:** - "Show my answers" -> { } (no parameters needed)

get_personal_engagement_answers

Search workspace users by name/email/ID or discover users by filter (team, segment, is_manager). Returns user IDs, home team, caller-visible segment memberships, and — for users who manage reports — manager-scoped segment IDs (directReports, allReports) ready to copy into engagement queries. Title and department are included only for people whose feedback the caller can access (themselves, and the people their current feedback permissions cover; being someone's HRIS manager grants this only where the workspace's feedback settings say so), the same access rule as the Teamspective web app; for everyone else they are withheld, and the result says so. **When to use:** - The user references a person by name and you need their numeric user ID before calling get_feedback, get_engagement_results, or similar. - You need to find every manager (or every member) in a department, team, or segment — e.g. "Who are the engineering managers?", "List everyone in Marketing". - You need a manager's directReports segment to query engagement/feedback for their team. - You need to enumerate a small set of users to iterate over (capped at 50; ask a narrower question if more are needed). **Do not use** to list an entire workspace (too broad). If every filter is empty the tool returns an error asking for narrower input. **Parameters (all optional, but at least one filter is required):** - `query`: substring match on first name / last name / email / group name. Use "userId:NNN" to look up an exact user ID (a bare number is treated as plain text). - `team`: team ID (number) or team name (string, resolved case-insensitively among the caller's visible teams). Expands to the full subtree — "Engineering" includes all sub-teams. - `segment_attribute` + `segment_value`: paired filter (both required together). For engagement attributes, membership is profile-hidden; use only publishable attributes like department, tenure, location, etc. See get_workspace_overview for exact keys and values. - `is_manager`: true → only users with at least one direct report. false is a no-op; omit instead. - `limit`: 1-50, default 25. Prefer narrower filters over larger limits. **Result shape:** one bullet per user with User ID (copy this), name, email, home team (plus title/department when the caller can access that person's feedback), visible segment memberships, and for managers a "Manages:" block listing each manager-scoped segment with its segment_attribute / segment_value / segment_id — three fields ready to paste into get_engagement_results to query that manager's team. **Relationship to other tools:** - Call `get_workspace_overview` first to discover team/segment names when the user uses fuzzy language. - Use the returned user IDs with `get_feedback`, `get_personal_engagement_answers`, or `get_user_context`. - Use the returned directReports / allReports segment IDs with `get_engagement_results` to analyse a manager's team. - `get_user_context` returns only the caller's own direct reports; this tool discovers arbitrary users across the workspace. **Example — resolve a name to a user ID:** ``` { "query": "Sarah Lee" } ``` Pick the matching user from results, then pass their User ID to `get_feedback`. **Example — breakdown by manager ("eNPS in Marketing by manager"):** 1. `get_workspace_overview` → confirm there is a "department" attribute with value "Marketing". 2. `search_users({ segment_attribute: "department", segment_value: "Marketing", is_manager: true })` → returns one bullet per Marketing manager, each with a "Manages:" block containing their directReports segment_attribute / segment_value / segment_id. 3. For each manager, call `get_engagement_results({ segment_attribute: "directReports", segment_value: "userId:<managerUserId>" })` in parallel to get the engagement score for that manager's team. 4. Synthesize the per-manager breakdown. Describe each team on its own; do not rank the managers against each other. **Examples:** - "Who is Mary Shelley?" → `{ "query": "Mary Shelley" }` - "Everyone in Engineering" → `{ "team": "Engineering" }` - "Managers in Helsinki" → `{ "segment_attribute": "location", "segment_value": "helsinki", "is_manager": true }` - "User 12345" → `{ "query": "userId:12345" }` (a bare number would be searched as plain text)

search_users

Previews and sends praise (positive recognition) to one or more workspace members. Praise is published and recipients are notified immediately, so there is no separate draft step; use `preview` first to coach the user toward stronger praise. **Flow:** 1. Call with `preview: true` to get a quality check WITHOUT sending. Strong praise names a specific thing the person did and its impact; generic praise ("Great work!") is weak. 2. If the quality check flags the praise as weak, help the user add the specific behavior and its impact (ask what exactly happened and why it mattered), then preview again. 3. Once it is specific and the user confirms, call again with `preview` omitted (or false) to actually send. **When to use:** - "Praise Sarah for the great launch" - "Thank the design team for their work this sprint" - "Send recognition to user 12345" **Behavior:** - Without `preview`, publishes immediately and notifies every recipient (NOT reversible from here). - Praise sent here is always PUBLIC: announced to the workspace, including the Slack/MS Teams channels. There is no private option; do not offer to send praise privately. - All recipients receive the same praise text. To praise people for different things, call once per distinct message. **The `recipients` parameter:** - An array of user IDs (preferred), full names, or "me". Numeric IDs are more reliable; get them from get_user_context or search_users. You cannot praise yourself. **Examples:** - Preview: `{ "recipients": [12345], "content": "Great work on the fleet management!", "preview": true }` - Send: `{ "recipients": [12345], "content": "Your fleet management overhaul cut our turnaround time in half and made the whole team's week smoother." }`

send_praise

Sends a saved feedback draft to the requester. Promotes the existing draft to "sent" and notifies the requester. Does NOT take content — whatever is currently in the saved draft is what gets sent. **When to use:** - Only after the user has explicitly confirmed they want to send. Show them the saved draft and ask first; do not submit unilaterally. - Only after save_feedback_draft has stored the current content. If the draft is stale, call save_feedback_draft again first. **Why no content arg:** the user may have edited the draft in the web UI (via the draft URL) between when you saved it and when they confirmed in chat. Submitting whatever is saved preserves their edits; passing content here would silently overwrite them. **Common errors:** - "No accessible feedback request": wrong request_id or you're not the provider. - "Already fulfilled": the request has been sent. Do not retry. Use get_feedback_requests to see what was sent. - "No draft saved": you skipped save_feedback_draft. Save the draft first, then submit. **Example:** `{ "request_id": 42 }`

submit_feedback