Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

readOnlyHint=true already establishes the safety profile, so the description is free to spend its words elsewhere — and it does, disclosing the fixed 7-day aggregation window and that unanswered check-ins are included in the result set. It doesn't cover pagination, group-size limits, or what identifies each member row, which keeps it short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: the first front-loads the returned data, the second states the intended decision it enables. No filler, no restating the tool name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema published, the description usefully enumerates the returned metrics and the time window, which is what an agent needs to trust the result. Minor gaps remain around result shape (one row per member?) and whether members with no activity appear at all.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is a single required parameter with 0% schema description coverage, so the description bears the burden. "Each member of a group" makes clear the parameter scopes to one group, but it never states the identifier form (ID vs. name) or how an invalid/unknown groupId behaves. Adequate but not compensating for the empty schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource (a group's members) and enumerates exactly what is reported: workout days, food-log days over 7 days, last log dates, and unanswered check-ins. That verb+resource+payload specificity makes the tool's job unambiguous, though it never contrasts itself with close siblings such as get_client_progress, get_habit_compliance, or list_group_assignments.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

"Use it to say who needs a nudge" implies the coaching/at-risk-member scenario but is a purpose statement rather than a when-to-use rule. There is no guidance on when to pick this over per-client tools or check-in listing tools, and no prerequisites or exclusions are stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.