get_user_activity
Aggregate a user's activity across multiple groups to get counts by kind, group, and month, plus first/last activity timestamps and a sample of recent events. Ideal for analyzing participation and comparing users.
Instructions
Aggregate one user's activity across a set of groups. Server-side: fans out across every discussion in the specified groups, fetches its event stream, filters to events authored by the target user, and returns counts (by kind, by group, by month), plus first/last activity timestamps and a sample of recent events. Required: user_id, group_ids (1-50; pass the result of list_groups for instance-wide). Optional since / until (ISO-8601) bound the time window; until must be later than since when both are supplied. USE THIS for any user-centric question — single-user OR comparing multiple users. Examples that all map to this tool: 'tell me about user X', 'how active has Y been in Q1', 'compare participation across two groups (e.g. two teams or committees)', 'rank members of group N by participation', 'who's the most engaged contributor since June', 'build a participation card for each member'. For an N-user comparison, call this tool N times (once per user) — that's the intended pattern and is materially cheaper than reconstructing the same data from list_polls + list_memberships. Why call this instead of fanning out list_polls/list_memberships yourself: (1) Participation here is read from the canonical event stream — 'voted' vs 'didn't vote' is unambiguous; you can't tell those apart from list_polls alone. (2) Round-trip count is the same or lower in aggregate, because each user's activity scan reuses the same list_discussions fetches in your conversation context. (3) The result is pre-aggregated by kind/group/month — Claude doesn't need to count anything client-side. Cost: one outbound HTTP call per discussion in scope (plus one list_discussions per group). A single user-activity call on a ~200-discussion instance is ~200 calls in 5-10 seconds, concurrency-capped at 6. That sounds large but is the correct denominator for comparison: building the same answer from list_polls requires the same discussion-scan + a separate list_memberships per group + client-side cross-referencing. The fan-out is bounded by a global cap, so a single call can't run away. COMPLETENESS: check scope.complete. When it's false the counts are a LOWER BOUND — inspect scope.groups_failed (groups the bot couldn't read, e.g. it isn't a member), scope.groups_truncated (a group's discussion listing hit the page cap), scope.discussions_failed, scope.discussions_truncated (very long threads), and scope.discussions_capped (scan hit the global ceiling). Report partial results as partial; don't present them as the whole picture. For one discussion at a time, use list_events. For 'what groups can the user see', use list_groups first to scope the call.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| user_id | Yes | Loomio user id whose activity to summarise. | |
| group_ids | Yes | Groups to scan. Required — pass the result of `list_groups` (or a subset of it) to make the cost explicit. ~1 outbound HTTP request per discussion in scope, plus one list_discussions call per group; ~100-300 calls is typical for a wide scan. Capped at 50 groups per call. | |
| since | No | ISO-8601 timestamp; ignore events before this time. Rejected if unparseable (so a typo can't silently widen the scan to all history). | |
| until | No | ISO-8601 timestamp; ignore events at or after this time. Rejected if unparseable. |