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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals the cache vs on-demand behavior (~5ms vs ~3s), the absence of LLM calls during on-demand builds, the presence of a '_source' field in responses, and the 404 behavior for precompute_only when the cron hasn't run. These are non-obvious behaviors that an agent needs to understand for correct invocation and response interpretation.

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 somewhat long but every sentence carries meaningful information: content list, cache behavior, response marker, and special parameter guidance. It is front-loaded with the core purpose and then supplies necessary behavioral details. The length is justified given the tool's complexity, though it could be slightly tightened.

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 description covers the essential invocation context: what the tool returns, the two execution paths, response disambiguation, and when to use the special parameter. However, it leaves gaps around the 'date' and 'fallback_build' parameters, and does not mention any potential error cases beyond the 404. Given the lack of an output schema, this is still a fairly complete picture for an agent to use the tool correctly.

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 input schema has 0% description coverage, so the description must compensate. It provides detailed meaning for precompute_only and implies user_id is the target user for the briefing. However, it does not explain the 'date' or 'fallback_build' parameters at all, leaving their purpose ambiguous. The description adds value for some parameters but not all, so a middle score is appropriate.

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 identifies the tool as a daily briefing for a given user_id and enumerates the exact contents (regime, overnight futures, earnings_today, macro_today, watchlist_signals, news_highlights, risk_exposure, top_movers). This is a specific verb+resource combination and distinguishes the tool from siblings like tengu_v3_briefing_status by focusing on the briefing content rather than status.

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 explicitly states when to use the tool (daily briefing for a user) and provides clear usage constraints for the precompute_only parameter: 'Pass precompute_only=true ONLY when you specifically need to know whether the cron has already run (e.g. monitoring scripts)'. This gives concrete when-to-use and when-not-to-use guidance, and also explains the two serving modes (cache vs on-demand) without needing to consult alternatives.

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