get_morning_briefing

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

With no annotations provided, the description carries the burden, but it's a read-only aggregation tool so there's inherently low risk. The description discloses what's included and that it returns both summary and detailed sections. It doesn't mention pagination, rate limits, or whether email content is included in full, but for a zero-parameter aggregation tool this is reasonably transparent.

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 description is well-structured with clear bullet points listing aggregation categories and a concrete example of the return format. It's efficient without being sparse, though the 'Returns:' block somewhat duplicates what's already stated in the opening line and could be trimmed.

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?

The tool has zero parameters, no annotations, and an output schema exists, so the description's job is to clarify what data is pulled and how it's presented. It covers the aggregation scope well and gives a representative output example. For a zero-parameter aggregator with an output schema, this is reasonably complete, though it could mention whether the briefing is time-limited to 'today' or included other windows.

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?

The tool has zero parameters, and with 100% schema coverage there's nothing to explain. The baseline of 4 for zero-parameter tools applies here since there are no parameter semantics to add meaning to, and the description's sample output format ('3 meetings, 2 pending replies, 1 overdue item') provides helpful context about what the results look like.

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 clearly states the tool aggregates a comprehensive morning briefing including calendar events, emails, overdue items, pending replies, and waiting items. It distinguishes from siblings like get_daily_briefing and get_briefing_summary by being specifically a morning briefing that aggregates multiple categories, providing a clear summary example.

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 description explains what data is aggregated and shows a sample summary format, implying it's the go-to for a consolidated morning overview. However, it doesn't explicitly state when NOT to use it versus alternatives like get_daily_briefing or get_briefing_summary, and there's no mention of prerequisites or timing considerations.

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