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

Adds substantial context beyond the annotations: terms are stored as keyed fingerprints, never as text, so they cannot be listed back; effects surface as markings in reports; and the write touches only this server's memory, never the Google Ads account. That last clause also reconciles the destructiveHint=false annotation with the "forget_all clears the account" behavior.

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?

Front-loads the purpose and then packs the four actions into compact fragments, so every clause carries information. The telegraphic style ("keep = the business sells this: ...") and the unexplained opener "Unlimited plan." cost it some readability.

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 still covers what an agent needs: preconditions, per-action effects, data-storage model, report visibility, and blast radius. Nothing essential for calling it correctly is missing.

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 67% and the action enum has no inline descriptions, so the description carries real weight: it defines all four action values and their downstream reporting effects. It also clarifies the matching rule for terms ("exactly as in the report, case and extra spaces do not matter"), reinforcing the schema note.

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: it saves the user's decision on search terms for one account so later sessions don't ask again. It also distinguishes itself from siblings by naming the downstream effects on negative_keywords_file and find_wasted_spend, so an agent can tell it apart from search_terms without opening either 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?

Gives an explicit precondition ("Only call it after the user said so") and defines each of the four actions with their consequences, which effectively encodes when to choose keep vs handled vs forget. It does not name a sibling alternative to use for reading or reviewing stored terms, but the action semantics cover most selection decisions.

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