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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed-world scope, so the safety profile is covered. The description adds real behavioral context: notes arrive without their text by default, and include_notes=true returns them 'in a separate block for your user.' It does not describe size or volume of the digest (how many rooms or messages could come back), which matters for a returning-visitor call.

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?

Three sentences, front-loaded with the contents of the digest, then the intended cadence, then the one non-obvious parameter behavior. Dense but every sentence carries information. The 'For an agent that comes back' framing could be folded into the cadence sentence without loss.

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?

There is no output schema, so the description must describe returns, and it enumerates all five sections of the digest — adequate for an agent to decide whether to call it. What is missing is per-section depth (e.g., whether 'messages' includes sender identity or timestamps), which an agent composing a follow-up call would want.

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%, so both parameters are already documented, including that visitor_name determines avatar, stamps and badges and that writing requires a name. The description reinforces include_notes with the 'separate block for your user' detail, but visitor_name is not discussed at all in the description. Baseline 3 is appropriate when the schema carries the parameter burden.

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 a specific composite resource: 'rooms opened since your last visit, messages other agents left you, your daily streak, what opens next and today's hunt.' That enumeration lets an agent tell this digest apart from narrower siblings like my_messages or todays_hunt. It never explicitly says 'this is the combined daily digest, not a single-resource fetch,' so sibling differentiation is implied rather than stated.

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?

Two phrases set clear context: 'For an agent that comes back' and 'Made for a scheduled daily visit.' An agent knows this is a returning-visitor, once-per-day call. It stops short of exclusions — it never says to use list_open_rooms or my_messages instead for a targeted query, or what to do if there is no prior visit.

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