wafle_ads_recommendations_list

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

With readOnlyHint and idempotentHint annotations already covering safety, the description adds value by disclosing the return content: each card includes an action field that is a writer call, plus confidence, expected_impact, and severity. It also explains the data semantics (server-side truth vs Meta attribution), giving the agent insight beyond the raw read-only nature.

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 four sentences long and front-loaded with the core purpose. Each sentence earns its place: the cross-tab explanation gives context, the card field enumeration substitutes for an output schema, and the apply reference guides next steps. It is slightly more verbose than a minimal two-sentence version but still efficient and well-structured.

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?

For a read-only list tool with no output schema, the description is largely complete: it enumerates the card fields, explains the source of the recommendations, and points to the apply tool. Combined with the schema's parameter metadata (defaults, enums) and annotations, the agent has sufficient context to invoke and understand results, though extra details like pagination behavior are not mentioned.

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 description coverage is only 40% (slug and status have descriptions), leaving page, per_page, and severity undocumented. The description does not compensate for these gaps—it never mentions the parameter usage, defaults, or filtering options. The only hint is the status schema description which is already in the schema, so the tool description adds little to parameter understanding.

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 opens with a specific verb+resource: "List ads recommendations generated by wafle's AI engine," which clearly states the tool's function. It further distinguishes from siblings by explaining the recommendation content and explicitly referencing `wafle_ads_recommendation_apply` as the action tool, setting it apart from list-only and apply-only tools.

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 implies usage context by explaining what recommendations are and that applying them requires a separate tool, but it does not explicitly state when to use this over alternatives like `wafle_ads_anomalies_list` or `wafle_ads_performance_summary`. There are no exclusions or when-not-to-use instructions, only a follow-up action hint.

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