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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, and 'Read-only.' is consistent with them. Beyond that it discloses genuinely useful behavior: photos are added by the person on Muovi (not through this server), the address is confirmed on Muovi's map, and `photo_policy` indicates whether photos help. It stops short of describing any rate limits or error behavior, and much of the text is workflow rather than tool behavior.

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?

Purpose and routing are front-loaded, but the body sprawls across several concerns (slot field anatomy, collection protocol, urgency exception, photo policy, address confirmation) without separation, and repeats the `slots`/`description` destination more than once. Every idea is relevant, but the framing as one long paragraph makes it harder to scan.

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?

There is no output schema, and the description compensates by enumerating the returned slot shape (`key`, `question_es`, `type`, `options`, `value_format`, `required`, `ask_if`) and the `photo_policy` field. Combined with the routing to `muovi_create_task_draft` and the field-validation guidance, an agent has everything needed to call and consume this tool.

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?

A single parameter with 100% schema coverage and an example value in the schema gives a baseline of 4. The description adds that the slug must come from `muovi_list_services`, which is the one piece of selection meaning the schema string alone doesn't convey.

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 first sentence gives a specific verb and resource ('List the fields Muovi takes for one service') and explicitly positions it relative to siblings by naming `muovi_create_task_draft` as its consumer and `muovi_list_services` as the source of the slug. An agent can distinguish it from every other muovi_* tool without opening a 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?

Explicit sequencing is given: read this before calling `muovi_create_task_draft`, obtain the slug from `muovi_list_services`, ask one question per message and wait for the answer, and treat `flexible` urgency as complete without a date. It also states what not to do (don't ask optional slots as a list) and where the address/photo steps live.

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