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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavior context by disclosing that day entries are returned with their IDs (enabling follow-up mutation) and that the payload spans several distinct sections. It says nothing about size, defaults for absent data, or empty-state behavior, which keeps it at a solid 3 rather than higher.

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?

The definition is two dense sentences with zero filler: every clause in the first names a returned section, and the second is a pure routing instruction. The long enumeration makes it a run-on that is harder to scan than a bulleted list would be, but no sentence could be removed without losing returned-field information.

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, the description must carry the return-value burden, and it does so by naming each dashboard section rather than saying 'returns dashboard data'. For a multi-section read-only dashboard with a single well-documented optional parameter, that is close to complete; only the date's effect on non-entry sections remains unspecified.

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 coverage is 100% and the single 'date' parameter is already documented as YYYY-MM-DD defaulting to today. The phrase 'saisies d'un jour (entries)' weakly implies the date scopes the entries section, but the description never clarifies whether the goal, streak, or challenge sections are affected by the date or always reflect 'now'. Baseline 3 is right since the schema carries the parameter meaning.

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 enumerates exactly what this dashboard surfaces: today's and week's screen time, daily goal, streak, active_challenge, focus session, day entries with their IDs, proposed challenges and challenge_history. That is a precise resource inventory that an agent can match to a user request. It falls short of 5 only because the retrieval verb is implicit in the noun phrase 'Temps d'écran' rather than stated outright.

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?

It explicitly routes two adjacent intents away from this tool: entering screen time goes to dandori_save with entity screen_time, and setting the limit goes to dandori_action with set_screen_time_goal. This gives the agent both the correct alternative name and the exact parameter to use, leaving nothing to inference about when not to call this dashboard.

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