Server Quality Checklist

Tool Scores

• muovi_get_professionalA
  4.3/5.0
  Behavior4/5

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

  Annotations already indicate readOnlyHint=true, but the description adds valuable behavioral context: it states that phone, email, and whatsapp are never returned, and that the profile_url is the only sanctioned contact channel. This goes beyond annotations to manage expectations about what the tool does not return. No contradictions with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single fluid paragraph that lists the returned fields and key usage notes. It is efficient and covers necessary details without excessive verbosity. While a bullet list might improve scannability, the current structure is clear and concise.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simple input schema and lack of an output schema, the description adequately explains what the tool returns by listing fields manually. It also covers an important nuance (the sanctioned contact channel) and how to deep-link. Could be slightly improved by mentioning if pagination or rate limits apply, but overall complete for a single-param read tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema provides a description for the 'slug' parameter, but the description adds value by explaining how to obtain the slug ('Obtain from muovi_search_professionals') and clarifying it is a 'URL-safe slug'. This improves an AI agent's ability to provide the correct input.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it fetches the full public profile for a single verified professional by slug. It lists the specific fields returned (display name, headline, bio, etc.) and distinguishes from sibling tools like muovi_create_task_link by mentioning the sanctioned contact channel and deep-linking.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for use: retrieve a professional's profile by slug. It does not explicitly state when not to use this tool, but it implies that muovi_search_professionals is for search and muovi_create_task_link for deep-linking, giving enough guidance for an AI agent to choose appropriately.

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

• muovi_search_professionalsA
  4.4/5.0
  Behavior4/5

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

  Annotations already indicate readOnlyHint and openWorldHint. The description adds important behavioral details: returns a paginated list, lists specific fields (display name, headline, ratings, verifications, profile_url), and crucially states that no phone/email/whatsapp is ever returned. This goes beyond annotations, though no mention of rate limits or error handling.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences: first sentence defines purpose and filters, second explains return content and a key constraint, third gives usage guidance. It is front-loaded and every sentence adds value with no fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given 9 optional parameters and no output schema, the description adequately covers core information: filters, return fields, pagination, and direction to the detail tool. However, it could hint that slugs come from catalog endpoints (muovi_list_cities, muovi_list_services) to improve completeness for an agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 100% schema description coverage, the schema already documents each parameter. The description provides a high-level summary of filter criteria but does not add new semantic information beyond what is in the schema. Thus, baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description explicitly states the verb 'search', the resource 'verified service professionals in Argentina', and lists multiple filtering criteria (service type, city, neighborhood, etc.). It clearly distinguishes from sibling muovi_get_professional by stating use for discovery vs. full detail.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit guidance: 'Use this for discovery; use muovi_get_professional for the full detail payload.' This directly tells the agent when to use this tool versus the sibling, fulfilling the dimension well.

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

• muovi_list_citiesA
  4.5/5.0
  Behavior4/5

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

  Annotations declare readOnlyHint=true and openWorldHint=true. Description adds that each city has a stable slug and human-readable name, and neighborhoods are nested. No contradictions; adds behavioral context beyond annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences, each earning its place. Front-loaded with purpose, then details about slugs and usage. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter list call with no output schema, the description fully explains what is returned (cities with nested neighborhoods, slugs, human-readable names) and how to use it. Complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  No parameters exist, so schema coverage is 100% (empty). The description adds value by explaining the slug usage and output structure, which is the baseline expectation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it lists Argentine cities with active neighborhoods, and specifies that slugs are used for other tools. It distinguishes itself from sibling tools like muovi_search_professionals by explaining how the output maps to parameters.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly says 'Call this when you need to resolve a user's location wording to a Muovi city or neighborhood slug.' This is clear guidance. It doesn't explicitly state when not to use it, but the context is sufficient.

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

• muovi_get_reviewsA
  4.7/5.0
  Behavior5/5

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

  Annotations already declare readOnlyHint and openWorldHint. The description adds critical behavioral details: pagination, sorting, fields returned (rating, title, comment, truncated author name, role, service category, timestamp), and notably that full surnames are never returned. No contradictions.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, each carrying essential information. The first sentence states the core functionality and sorting; the second details output fields and usage context. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite lacking an output schema, the description thoroughly explains the return structure (rating, title, comment, author display name, role, service category, timestamp) and pagination behavior. This is complete for a read-only paginated list tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, but the description adds value by explaining the 'slug' parameter's provenance (obtain from muovi_search_professionals or muovi_get_professional) and clarifying the default limit (20) which is not in the schema. This enhances understanding.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it fetches paginated reviews for a single professional, sorted most-recent. It specifies the resource (reviews) and action (fetch), and differentiates from sibling tools which focus on professionals, cities, or services.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly states the use case: 'Use this to surface social-proof when recommending a professional.' While it doesn't mention when not to use or alternatives, the context is clear and the statement provides direct guidance.

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

• muovi_list_servicesA
  4.7/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, so the bar is lower. The description adds value by disclosing that each entry has a stable slug, a human-readable name, optional description, and especially the requires_matricula flag. This behavioral detail aids agent reasoning beyond what annotations supply.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Single paragraph, no filler. Front-loads the purpose, then details output fields, and ends with usage recommendation. Every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with no parameters and no output schema, this description is fully complete. It explains the return structure, the meaning of each field, and the tool's role in the larger workflow (mapping natural language to slugs for sibling tools).

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  No parameters exist (0 params), and schema coverage is 100%. Per rubric baseline 4, since there is nothing to add. The description could not add parameter meaning because there are none.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'List' and the resource 'every service category Muovi supports in Argentina'. It explicitly distinguishes the tool from siblings by explaining how its output (slugs) feeds into muovi_search_professionals and muovi_create_task_link, making its role unique.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit when-to-use guidance: 'Call this first when you need to map a user's natural-language request to a Muovi service slug.' Also explains that slugs are stable and reused elsewhere, giving clear context for invocation order.

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

• muovi_create_task_linkA
  4.9/5.0
  Behavior5/5

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

  Annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false) are fully supported: the description states 'makes no network call and creates no task' and 'pure formatter'. It adds context that the URL follows a specific format, which is useful beyond the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Four sentences, each essential: tool purpose, URL format, no-side-effect assertion, and usage guidance. Front-loaded and efficient with no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Even without an output schema, the description fully explains the return format and the broader workflow (user completes booking on-platform). It clarifies the limitation of agent-side task creation, making the tool's role in the flow complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, maintaining a baseline of 3. The description adds value by specifying the source of each slug (e.g., professional_slug from search or get, service_slug from list), providing execution context not in the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it builds a deep-link URL for the Muovi task creation flow, pre-filled with a professional and service. It distinguishes this from sibling tools by explicitly labeling it as a 'pure formatter' that makes no network calls or task creation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description says the tool should be used after selecting a professional and service, and the URL should be surfaced to the user for completing the booking on Muovi. It also warns that the agent cannot create tasks server-side, guiding appropriate use.

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