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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so safety is covered; the description reinforces this by stating it 'opens nothing by itself' and only returns instructions. It also explains why browser automation is required (Weezevent's API is read-only and partner-restricted), which is genuine behavioral context beyond the annotations. It stops short of describing the shape or length of the returned guidance, though the follow-up tooling is clear.

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 purpose is front-loaded, but the middle sentence is a long run-on that mixes the return value, the no-side-effect guarantee, and the follow-up tooling. The closing sentence about Weezevent's REST API is useful justification but phrased as an aside and includes an oddly formatted check date, adding bulk to an otherwise short definition.

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 zero-parameter, guidance-returning tool with no output schema, the description tells the agent what comes back (screens, buttons, fields) and what to do next, which is the essential information. Nothing critical is missing, though a note on what happens if the user's account lacks refund capability would round it out.

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?

With zero parameters there is nothing to document, so the baseline of 4 applies. The description correctly implies a parameterless call and adds no misleading argument expectations.

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 states a specific action and resource: it returns step-by-step refund instructions for the user's own Weezevent account rather than performing the refund. It also distinguishes itself from the cotlet_browser_* tools, which are named as the way to actually execute the steps. The only gap is that it never contrasts itself with the other weezevent_* siblings, though the refund subject matter is distinct enough for an agent to disambiguate.

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?

It gives clear context for use (user's own Weezevent account) and an explicit follow-up path: use cotlet_browser_* tools in the Weezevent Cloud Browser to carry out the returned steps. It does not state explicit exclusions or prerequisites such as owning a refundable order, but the when-to-use condition is unambiguous.

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