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

The annotations (readOnlyHint=true, destructiveHint=false) would be puzzling for a tool named 'reschedule', and the description resolves that by declaring it only returns instructions and performs no action. It also discloses the key environmental constraint — ZenMaid offers no public API, REST endpoints, webhooks or programmatic access — which tells the agent why the browser workflow is mandatory.

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 behavior and follow-up workflow are front-loaded in the first two clauses, which is exactly right. The trailing API note is somewhat repetitive ('ZenMaid's official API: ZenMaid has no public API') and cites a dated check, so it costs more words than the single fact it conveys.

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 no parameters, no output schema and read-only annotations, the definition supplies everything an agent needs: what the tool returns (screen/button/field steps), what it does not do, and which tool family completes the task. Nothing material is left unstated for a tool of this complexity.

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 are zero parameters and additionalProperties is false, so there is nothing for the description to disambiguate; the baseline of 4 applies. The only mild gap is that it never states which appointment identifier must be supplied to the downstream browser workflow, though that is outside this tool's 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 description gives a specific verb and resource ('Reschedule appointment in the user's own ZenMaid account') and immediately clarifies the actual output: step-by-step ZenMaid screens, buttons and fields. That distinguishes it from the cotlet_browser_* siblings, which perform the clicking, so an agent can tell the two apart without inspecting any schema.

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 states explicitly that this tool 'opens nothing by itself' and that the actual reschedule is done afterwards with the cotlet_browser_* tools in the ZenMaid Cloud Browser, naming the alternative family and the ordering condition. That is an explicit when-to-use and when-this-stops rule rather than an inference.

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