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

Goes well beyond the annotations by disclosing the sign-in/auth prerequisite, the asynchronous state ('while the site is still being read, the result says so and a later call continues'), and the exact side-effect boundary ('nothing is published... never by this tool'). These are precisely the behavioral facts an agent cannot get from readOnlyHint=false / destructiveHint=false.

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-loaded with the core action, then the prerequisites and the async caveat. Sentences are dense but each carries new information; the parenthetical aside about the client asking for sign-in is slightly awkward but earns its place as an auth note.

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?

Covers purpose, auth, async continuation, and the no-publish guarantee, and an output schema exists so return values need not be spelled out. The one gap is that it never names the tool to call back for the still-reading case, leaving that handoff implicit.

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% and the enum on page_type is fully documented ('Detected when omitted'), so the schema does the heavy lifting. The description adds no syntax, format, or example beyond what site_url and page_type already state.

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 artifact: 'Creates branded Open Graph image designs for a site,' and clarifies the output is a picker link rather than a published image. It does not name any sibling, so an agent still has to infer that wait_for_design is the continuation path from the vague phrase 'a later call continues.'

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 clear triggering context (needs a getwowlink account and a sign-in, so it is not a fire-and-forget call) and a firm boundary that this tool never publishes. It stops short of explicitly naming the alternative to use while the site is still being read, which is the main routing decision an agent faces here.

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