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

With no annotations supplied, the description carries the full burden of behavioral disclosure and mostly fails to meet it. It does not say whether invoking the tool produces a document, a template, or instructions the caller must then execute; nor does it describe side effects, required context, or response shape. '30-day support promise' is a commercial claim, not an operational trait an agent can act on.

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, of which two are promotional padding ('AI-powered', 'no prompt engineering needed', '30-day support promise') that give an agent no actionable selection signal. The one substantive clause is buried mid-sentence rather than front-loaded as the tool's function.

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 simple single-parameter tool the description is structurally thin where it matters: it never states what the caller receives or how to use the optional query to scope the output. Because there is no output schema and no annotations, the description is the only source of that information and does not provide it. The 'prompt kit' framing actually raises unresolved questions about whether this tool executes anything at all.

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 single optional 'query' parameter is fully described in the schema (100% coverage), so the schema already supplies its meaning. The description adds nothing about how the query scopes the generated planner, leaving the only parameter choice entirely to the schema. Baseline 3 is appropriate when schema coverage is complete.

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 phrase 'generate a ready-to-use store campaign planner workflow' does name a verb and a resource, so the intent is guessable. But the framing is dominated by marketing language ('AI-powered restaurant & brand intelligence pack', 'full prompt kit') rather than a functional statement of what the tool returns. Among many campaign-related siblings (campaign-idea-generator, ugc-campaign-builder, viral-campaign-sop, store-traffic-plan), nothing here distinguishes this tool from any of them.

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?

There is no guidance on when to invoke this versus the numerous other campaign and store-planning siblings, and no mention of when not to use it. The only contextual claim is that no prompt engineering is needed, which is a sales point rather than a routing rule.

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