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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds genuinely new behavioral facts: it performs no action and opens no window, it returns screens/buttons/fields instructions, and it explains that the official WellnessLiving API is a paid developer subscription rather than an option here. The 'checked 9 Nov 2026' note is noise but the behavioral content is real.

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 core instruction and the browser-tool handoff come early, but the final API sentence is a long aside with an embedded quote and a timestamp that does not help an agent call the tool. Roughly a third of the text is tangential.

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?

With zero parameters, no output schema and full annotation coverage, the remaining burden is explaining what comes back; the description says it returns step-by-step screens/buttons/fields, but never clarifies whether any actual schedule information is included or how the guidance relates to the sibling wellnessliving_list_clients/book_* tools. Adequate to invoke, thin on what to expect.

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 tool takes no parameters, which is the baseline-4 case; there is nothing for the description to disambiguate. It does not, however, state the implicit scope of the schedule (own account only, which it does mention) or any date/range concept, so nothing is added beyond the empty schema.

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 name and title say 'List schedule', but the description says it 'Returns how to do it in WellnessLiving step by step ... and opens nothing by itself', so the tool actually produces guidance rather than schedule data. An agent can work out the real behavior from the text, but the name/description mismatch forces it to read past the first clause.

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 an explicit handoff: call this first for the step-by-step, then perform the steps 'with the cotlet_browser_* tools in the user's WellnessLiving Cloud Browser'. It also signals a when-not ('opens nothing by itself'). No comparison to sibling wellnessliving_* tools is offered, but the browser-tool routing is the relevant one.

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