User Session Count

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds useful behavioral context beyond annotations — the 'daily' granularity and 'over time' time-series nature of the result — but doesn't disclose details like date inclusivity or response shape.

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 with no filler: the first states the action and resource, the second justifies its use case. The description is efficiently front-loaded with the core purpose before the application context.

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?

For a read-only query tool with 100% schema coverage and strong annotations, the description is largely adequate. 'Daily session counts' hints at the response shape, and the user-scoping is clear. Minor gaps remain — no mention of the exact output fields or date-range behavior — but with no output schema expected, the description carries acceptable weight.

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?

Schema description coverage is 100%, with well-documented parameters including the helpful hint to use rybbit_list_users for finding user IDs. The description's 'over time' phrasing loosely maps to startDate/endDate but adds no parameter-level detail beyond what the schema already provides, so the baseline of 3 applies.

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 states a specific verb ('Get') and a precise resource ('daily session counts for a specific user over time'), which clearly communicates scope. It differentiates from site-level siblings like rybbit_get_metric and rybbit_get_overview via the 'specific user' qualifier, though it doesn't explicitly name a sibling to contrast against.

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?

The second sentence ('Useful for analyzing individual user activity patterns and retention') provides an implied use case, which helps an agent know when to select this tool. However, it offers no exclusions or explicit alternatives, such as redirecting to rybbit_get_retention for cross-user cohort analysis or rybbit_live_users for real-time activity.

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