v0.0.3

Tool-selection tuning. No new tools, no API changes — just rewrites of the descriptions Claude reads when picking which tool to call.

Why

Two real consumer chats analysed by the maintainer showed Claude reaching for list_polls + list_memberships and reconstructing per-user participation client-side, when get_user_activity was the canonical answer. The reconstruction is more expensive AND ambiguous: from a list_polls response alone you can't tell "didn't vote" from "abstained". This release rewires the descriptions so the right tool wins.

What changed

• get_user_activity — major rewrite. Framed as the primary entry point for any user-centric question, single OR multi-user. Documents the pattern: for an N-delegate comparison, call this tool N times (one per user). Example phrasings now spelled out: "compare delegate turnout across the BAC and TAC", "rank members of group N by participation", "build participation cards for each delegate". Reframes the cost as amortised — each per-user call reuses the same list_discussions fetches in the conversation — and spells out the canonical-stream advantage over a list_polls-based reconstruction.

• list_polls — cross-ref at the end: for per-user participation questions, prefer get_user_activity. Calls out the abstain-vs-didn't-vote ambiguity that list_polls cannot resolve.

• list_memberships — explicit "do NOT use this to construct a participation analysis" warning, redirecting to get_user_activity per member.

• list_events — warns against looping over every discussion; redirects to get_user_activity for any cross-discussion user-centric question, which does the fan-out server-side with concurrency control.

Tool counts

Unchanged: 8 reads + 4 writes + 2 b3 admin.

Mode	Tools
Cloud Run (readonly)	8
Local stdio	12
With LOOMIO_B3_API_KEY	14

Try it

"Compare participation between members of TAC and BAC for Q1."
"Build a participation card for each delegate in group 42."
"Who's our most engaged contributor since June?"

Claude should now reach for get_user_activity directly instead of synthesising the answer from list_polls + list_memberships.

Follow-up

The data-driven question — whether get_user_activity alone is enough, or whether a get_group_summary composite is also worth adding — is deferred until verbose production logs show whether description tuning closes the gap.

See CHANGELOG.md for the full entry.