SAMRUM

Returns an overview of one selected family: members (nickname or first name, role, test status, and relationships including inferred siblings), reports, active focus tracks, recent moment cards, and suggested next steps. Requires authentication. Call this: - At the start of any conversation about the user's SAMRUM data - When the user asks what they should do next, what's available, or what they've completed - When the user asks which focus track fits best, what report makes sense next, or "what would you pick?" - When the user names one or two family members and asks about reports, focus tracks, or next steps - When you need to find the ID of a report, track, or family member before calling another tool Do NOT call this to explain what SAMRUM is as a product (use get_samrum_info). Do NOT call this to read report content (use get_report with the reportId from this result). The result contains no personality data – only structure and status. The authenticated user is marked with "isCurrentUser": true. Next steps are computed server-side based on family composition, completed tests, and existing reports. If you've already called this in the current conversation and have the IDs you need, don't call it again unless the user asks about family structure or "what should I do next." Use includeRecommendations=true whenever the user asks for a recommendation, which report or focus track to choose, or what to do next. Leave it false only for simple orientation to keep latency and payload smaller. RECOMMENDATION SOURCE OF TRUTH: - When availableNextSteps or trackOptions are present, use them as the source of truth for recommendations. - Do NOT invent new focus tracks or report types from profile interpretation when recommendations are already available in this result. - If the user names two people together ("me and Louise", "Thilde og Merle"), treat that as ONE pair request. Do NOT split it into two separate individual recommendations unless the user explicitly asks for one per person. - If the pair is two non-current family members and the user is an adult in the family, treat it as a proxy pair request, not as two separate personal tracks. Optional familyId scopes to a specific family (for multi-family users). Optional locale (da, en, sv, or de); if omitted, use the authenticated user's preferred language when available, otherwise da.

get_family_overview

Returns a focus or relational track with progress info: type, participants, total weeks, current week, content for the current week, check-in status, and days since last read. Includes track-specific guardrails and flags. Requires authentication. Call this when: - The user asks about their track, this week's focus, or what they should be working on - The user mentions a weekly experiment or exercise - You want to follow up on progress ("how did last week go?") Do NOT call this for report experiments – those come from get_report. Tracks are multi-week programs with weekly delivery. Reports are one-time documents with suggested experiments. The response includes daysSinceLastRead. If this is high (more than ~14 days), the user has stalled. Don't pretend they're mid-flow. Acknowledge warmly: "You started this track a while back and got through week N. Want to pick it up?" Track responses include track-specific forbidden words and preferred vocabulary. Use the preferred vocabulary when discussing this track's content. Requires trackId from get_family_overview. Optional locale (da, en, sv, or de); if omitted, use the authenticated user's preferred language when available, otherwise da.

get_track

Returns one person's personality profile: coarse bands (high/middle/low) and plain-language summaries for each of the 10 axes. Only returns data for people the user has permission to see. Requires authentication. Call this when: - The user asks about their own personality or a specific dimension ("am I introverted?", "what does emotional reactivity mean for me?") - The user asks about a family member's personality and you need individual trait data - You need trait-level context to explain something from a report Do NOT call this to understand how two people interact – that's in the report (use get_report). Profiles show individual tendencies; reports show what happens when those tendencies meet. COMPARING TWO PEOPLE: - When the user asks to compare two people's profiles ("compare me and Louise", "how are we different?"), make EXACTLY ONE call with both personId and compareWithPersonId. - Do NOT make two separate get_profile calls in the same turn for a comparison request unless the first combined call fails. - A single call with compareWithPersonId returns both profiles in one response with a comparison object. Do NOT turn profile data into an invented focus track or report recommendation when get_family_overview recommendations are available. Profiles can explain tendencies, but they are not the source of truth for what to do next. If the API returns access_denied, the person hasn't shared their profile. Say so plainly and suggest using a shared report instead. The response includes the person's nickname and role (adult/teen/child). For children, summaries use situational language. For teens, summaries use developmental framing. Use these summaries as-is – they're already age-appropriate. Includes staleness warning when the test is over a year old. Requires personId from get_family_overview. Optional locale (da, en, sv, or de); if omitted, use the authenticated user's preferred language when available, otherwise da.

get_profile

Returns static product information about SAMRUM: what it is, how the test works, report types, focus tracks, the moment guide, methodology, privacy model, positioning, and useful links. Requires authentication. Call this when: - The user asks what SAMRUM is or how it works - The user asks about methodology ("is this like Myers-Briggs?", "is this scientific?") - The user asks about privacy or data handling - You need to explain a SAMRUM concept Do NOT call this if the user is asking about their own data, their family, or their reports – use get_family_overview to orient, then the relevant detail tool.

get_samrum_info

Renders the profile radar widget by fetching profile data directly. Call this when you want to display the interactive radar UI in MCP Apps-capable clients. Input: - personId: required - compareWithPersonId: optional (for two-profile overlay) - locale: optional This tool fetches the same profile payload shape as get_profile and then renders it via the widget template.

render_profile_radar

Returns the user's most recent moment guides with metadata, bridge hints, and extracted summaries. Use this when the user asks what their latest guide said, wants to revisit recent post-conflict guidance, or wants to see whether the same pattern keeps showing up. Optional limit (1-5, default 3) controls how many recent guides to return. Optional detail controls whether to return summary only (default) or include full guide content. Optional familyId scopes to one family for multi-family users. Optional locale (da, en, sv, or de) localizes labels and links; if omitted, use the authenticated user's preferred language when available, otherwise da.

get_recent_moment_guides

Returns a report with a structured summary and optionally the full stored report JSON. The structured summary extracts: key_patterns (up to 5 friction patterns), conflict_loops (ALL recurring conflict patterns with driving axes, trigger, and repair), experiments_count, and conversation_starters_count. This summary is always computed server-side – no extra LLM generation. Optional detail parameter: - summary (default): includes the structured summary but omits full_content. Prefer this 95% of the time – it has enough for a complete explanation of patterns, loops, and what to try. - full: includes full_content – the complete narrative JSON after privacy stripping. ONLY use this if the user asks for a VERY specific verbatim detail that is not in the summary (e.g. "read me the exact experiment wording" or "what exact words does it use about intimacy?"). Full content can be 5-15K tokens and risks context overload. Optional section parameter: - key_patterns - conflict_loops - experiments - conversation_starters - professional_help Use section when the user asks for one narrow part of the report and you want to keep context small. Call this when: - The user asks about a specific report ("explain my couple report", "what did the parent-child report say?") - The user asks about dynamics between specific people ("why do Mette and I always fight about the same thing?") - The user asks for conversation starters, experiments, or things to try from a report - The user wants to understand a pattern or conflict loop Do NOT call this to understand one person's individual tendencies – that's get_profile. Reports show what happens when tendencies meet. Do NOT turn report interpretation into an invented report or focus track recommendation when get_family_overview already returned availableNextSteps or trackOptions. Use server-side recommendations as the source of truth for which report or focus track comes next. Start with the structured summary for an overview. Only request detail="full" when the user asks for specifics. If the user says "show me" or "let me read" the report, offer the web link alongside a brief summary. For cross-report questions ("what's the theme across my reports?"), call get_report for each – the structured summaries are small enough that several fit in context easily. When needs_practitioner_bridge is true, include the practitioner_bridge_text naturally in your response. When guardrails include forbidden terms and symmetry rules, respect them when discussing this report. Requires authentication and a reportId from get_family_overview. Optional locale (da, en, sv, or de); if omitted, use the authenticated user's preferred language when available, otherwise da.

get_report