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

No annotations are supplied, so the description carries the full behavioral burden, and it discloses almost nothing beyond sales language. It does not say whether the tool returns a prompt template, generated copy, or instructions; whether output is platform-specific; or what the '30-day support promise' means operationally for the caller.

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 promotional copy ('Instantly generate', 'no prompt engineering needed', '30-day support promise') with the useful information — platform and output form — absent. The front-loaded framing as an 'intelligence pack' actively misdirects rather than orienting the agent.

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 one-parameter, no-annotation, no-output-schema tool, the description should at minimum state what comes back and how it differs from sibling kits. Instead it leaves the return artifact undefined and spends its length on purchase-style assurances, so an agent cannot confidently call it or route to it.

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?

There is a single optional 'query' parameter with 100% schema description coverage, so the schema already explains its meaning and the description adds nothing about how scoping affects the result. With schema coverage this high, the baseline of 3 applies even though the description is silent on the parameter.

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 calls itself an 'AI-powered restaurant & brand intelligence pack' and then says it will 'generate a ready-to-use cover kit workflow', which is a vague restatement of the name rather than a specific verb+resource. It never says what a 'cover kit' actually contains (cover copy? image prompts? layout template?) or that it is for Douyin, despite dozens of near-identical siblings such as gzh-cover-kit, xhs-cover-kit, sph-cover-kit and zh-cover-kit that the agent must choose between.

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 pick this tool over the other cover-kit variants or over dy-adcopy-kit/dy-topic-kit, and no prerequisites or exclusions are stated. The only usage-adjacent sentence, 'no prompt engineering needed', is a marketing claim, not a selection condition.

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