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

Annotations only declare the safety/idempotency profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false), so the description adds real value beyond them: content is persisted verbatim rather than re-summarized, the artifact becomes permanent dashboard state, and it is silently injected into generate_strategy/generate_campaign prompt context going forward. It does not cover permissions, reversibility/cleanup of a saved brief, or rate limits, which keeps it short of a 5.

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 core action and its persistence/visibility effects, then the when-to-use rule, then the revision alternative. The clause about 'summarizing it back to the user and losing it' is slightly rhetorical but still carries usage meaning; otherwise the text is tight.

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, and the description compensates by pointing to where the saved brief's id lives (dashboard Research page URL, or a prior call's result). Combined with the disclosed downstream effects and the verbatim-save guarantee, an agent has enough to call correctly, though it never states what the call itself returns.

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 kind, title, brandId, content and sourceNote are already fully documented in the schema, including the enum semantics and the domain-register example. The description adds no parameter-level detail beyond noting where an existing brief's id comes from, so the baseline 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?

States a specific verb and resource (saves AI-synthesized research as a permanent document against a brand) and immediately names the downstream consumers, generate_strategy and generate_campaign, plus dashboard visibility. It distinguishes itself cleanly from update_research_brief and list_research_briefs, so an agent can pick it without opening a schema.

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?

Explicit trigger ('use this whenever a conversation produces real research worth keeping, instead of just summarizing it back to the user'), explicit anti-pattern (do not save a duplicate), and an explicit named alternative (update_research_brief) with the condition that selects it. Nothing is left to inference.

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