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

Annotations already establish read-only and open-world, and the description adds substantial context beyond them: the 3-page pagination ceiling, result ordering (declared trade first, then review score, other-trade businesses last), the exact return fields, and the explicit absence of phone/email/WhatsApp. It also discloses behavioral constraints an agent could otherwise violate, such as never stating how many professionals exist and never saying a check is unverified.

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 preconditions are front-loaded and most of the length is justified because there is no output schema, so field and ordering details must live here. It is nonetheless a dense block that mixes invocation guidance with presentation policy, and a few lines (e.g. how the card view renders photos) add little for the calling agent.

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 output schema and a 6-parameter search, the description carries the full burden and does: required inputs, result fields, ordering, pagination semantics, presentation rules and next-step tool routing. An agent has everything needed to call it correctly and to handle both the has_more and no-more-results cases.

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 description coverage is 100% and the schema already documents every parameter, including the slug sources (muovi_list_services, muovi_list_cities) and the page/has_more relationship. The description largely restates those dependencies rather than adding new meaning, and it never mentions the has_matricula or verified_identity filters or when to use the optional city override, so it does not exceed the baseline.

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?

Opens with a specific verb, resource, page size and scope: 'Find up to 5 Muovi professionals per page for one service in one barrio.' It also names the sibling boundary explicitly at the end ('Use muovi_get_professional with the id for the full profile'), so an agent can distinguish search from profile retrieval without opening either 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?

Gives explicit when-to-use rules and preconditions: both slugs are required and the agent must ask the user which service and barrio if unspecified. It also routes to concrete alternatives after results (muovi_create_task_link, muovi_create_task_draft with or without professional_id) and handles the has_more=false case with a named fallback rather than a dead end.

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