Server Quality Checklist

Tool Scores

• schedule_recurringC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions authentication requirements, which is helpful, but fails to describe other critical traits: whether this is a mutation (likely yes, given 'Set up'), what happens on success/failure, if there are rate limits, or if changes are reversible. For a tool with 6 required parameters and no annotations, this leaves significant gaps.

  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 efficiently structured in two sentences: the first states the purpose and resource, the second notes prerequisites. It's front-loaded with the core action and wastes no words, though it could be slightly more polished (e.g., combining sentences).

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

  Completeness2/5

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

  Given the complexity (6 required parameters, no annotations, no output schema), the description is incomplete. It lacks behavioral details (e.g., mutation effects, error handling), usage differentiation from siblings, and any information about return values. For a scheduling tool with significant user impact, this leaves too many unknowns for the 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?

  Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no additional parameter semantics beyond implying the context ('dog walking schedule'), which doesn't enhance understanding of individual parameters. This meets the baseline for high schema coverage but doesn't compensate with extra value.

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

  Purpose4/5

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

  The description clearly states the action ('Set up a recurring dog walking schedule') and resource ('with a specific walker on wagwalking.com'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from sibling tools like 'book_walk' or 'search_walkers', which likely handle one-time bookings or discovery rather than recurring schedules.

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

  Usage Guidelines2/5

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

  The description mentions prerequisites ('Requires WAG_EMAIL and WAG_PASSWORD') but provides no guidance on when to use this tool versus alternatives like 'book_walk' for single walks or 'search_walkers' for finding walkers. Without explicit when/when-not instructions or named alternatives, the agent lacks clear usage context.

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

• book_walkB
  3.2/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. It mentions authentication requirements (environment variables) which is valuable, but doesn't describe what happens when booking succeeds/fails, whether it's idempotent, rate limits, or confirmation details. For a booking tool with no annotations, this leaves significant behavioral gaps.

  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 appropriately sized with two sentences that each serve distinct purposes: stating the core functionality and specifying prerequisites. It's front-loaded with the main action. However, the second sentence about environment variables could be more integrated with the tool's purpose.

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

  Completeness3/5

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

  Given 7 parameters with 100% schema coverage but no annotations and no output schema, the description provides basic context about authentication but lacks information about return values, error conditions, or behavioral nuances. For a booking tool with multiple parameters, this leaves the agent with incomplete operational understanding.

  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?

  Schema description coverage is 100%, so the schema already documents all 7 parameters thoroughly. The description adds no additional parameter information beyond what's in the schema. According to guidelines, with high schema coverage (>80%), the baseline is 3 even with no param info in description.

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

  Purpose4/5

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

  The description clearly states the action ('Book a dog walking session') and target resource ('on wagwalking.com'), providing a specific verb+resource combination. However, it doesn't differentiate this booking tool from the 'schedule_recurring' sibling tool, which might handle recurring bookings versus this one-time booking.

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

  Usage Guidelines3/5

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

  The description implies usage context by mentioning environment variable prerequisites (WAG_EMAIL and WAG_PASSWORD), but doesn't explicitly state when to use this tool versus alternatives like 'schedule_recurring' or 'search_walkers' first. It provides some guidance but lacks explicit when/when-not instructions.

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

• get_walk_statusB
  3.2/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. It discloses authentication requirements and mentions GPS tracking behavior for in-progress walks, which adds useful context. However, it doesn't cover other behavioral aspects like error conditions, rate limits, or what happens with invalid booking IDs.

  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 appropriately sized with two sentences that each serve a purpose: the first states the core functionality, the second adds authentication requirements. It's front-loaded with the main purpose, though the authentication detail could potentially be moved to annotations if available.

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

  Completeness3/5

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

  For a single-parameter read operation with no annotations and no output schema, the description provides adequate but incomplete context. It covers authentication and GPS tracking behavior but lacks details about return format, error handling, or how to interpret different status values. More completeness would be helpful given the absence of structured metadata.

  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?

  Schema description coverage is 100%, so the schema already documents the single 'booking_id' parameter. The description doesn't add any additional meaning about the parameter beyond what's in the schema (e.g., format examples, validation rules). Baseline 3 is appropriate when schema does the heavy lifting.

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

  Purpose4/5

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

  The description clearly states the verb ('Get') and resource ('status of a current or past dog walk booking'), with specific details about GPS tracking for in-progress walks. However, it doesn't explicitly differentiate from sibling tools like 'get_pet_report' or 'view_walker_profile' which might also provide status-related information.

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

  Usage Guidelines2/5

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

  The description mentions authentication requirements ('Requires WAG_EMAIL and WAG_PASSWORD') but provides no guidance on when to use this tool versus alternatives like 'get_pet_report' or 'view_walker_profile'. There's no explicit when/when-not usage context or comparison to sibling tools.

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

• view_walker_profileB
  3.2/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full burden. It states this is a 'view' operation, implying read-only, but doesn't disclose behavioral traits like authentication needs, rate limits, or whether it's a public API. For a tool with zero annotation coverage, this is a significant gap.

  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, efficient sentence that front-loads the purpose and lists included data. It could be slightly more structured (e.g., separating core action from details), but it's appropriately sized with no wasted words.

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

  Completeness3/5

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

  Given no annotations, no output schema, and a simple parameter schema, the description provides basic purpose and scope. However, it lacks details on return format (e.g., structured data vs. HTML), error handling, or dependencies, making it minimally adequate but incomplete for robust use.

  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?

  Schema description coverage is 100%, with the parameter 'walker_id' documented as 'The walker/caregiver ID or profile slug'. The description doesn't add meaning beyond this, such as format examples or where to find the ID. Baseline 3 is appropriate when schema does the heavy lifting.

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

  Purpose4/5

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

  The description clearly states the action ('view') and resource ('dog walker's full profile'), specifying what information is included (bio, certifications, reviews, photos, pricing). It distinguishes from siblings like 'search_walkers' (list) and 'rate_walker' (action), though not explicitly. A 5 would require explicit sibling differentiation.

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

  Usage Guidelines3/5

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

  The description implies usage when needing detailed profile information, but doesn't explicitly state when to use this vs. alternatives like 'search_walkers' (for finding walkers) or 'get_pet_report' (for pet data). No exclusions or prerequisites are mentioned, leaving some ambiguity.

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

• search_walkersA
  3.5/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. It discloses that this is a search operation that returns walker cards with specific fields, which is helpful. However, it doesn't mention important behavioral aspects like whether this requires authentication, rate limits, pagination, or what happens if no walkers are found.

  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 perfectly concise with two sentences that each earn their place. The first sentence explains what the tool does and its main parameters, while the second describes the return format. No wasted words or redundant information.

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

  Completeness3/5

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

  For a search tool with no annotations and no output schema, the description provides adequate basic information about purpose and return format. However, it lacks details about authentication requirements, error conditions, pagination, or how results are sorted/filtered, which would be helpful for a search operation.

  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?

  Schema description coverage is 100%, so the schema already fully documents all 4 parameters. The description mentions the three main parameters (location, date, service_type) but doesn't add meaningful semantic context beyond what's in the schema. The baseline 3 is appropriate when schema does the heavy lifting.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: searching for available dog walkers on a specific website using location, date, and service type criteria. It specifies the verb 'search' and resource 'dog walkers', but doesn't explicitly differentiate from siblings like 'view_walker_profile' or 'book_walk'.

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

  Usage Guidelines3/5

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

  The description implies usage context by mentioning search criteria, but doesn't provide explicit guidance on when to use this tool versus alternatives like 'view_walker_profile' for detailed information or 'book_walk' for booking. No exclusions or prerequisites are mentioned.

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

• rate_walkerA
  3.9/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It adds value by specifying authentication requirements ('Requires WAG_EMAIL and WAG_PASSWORD') and the optional tip feature, but does not cover other important traits like rate limits, error handling, or what happens to existing reviews. It adequately describes the core mutation behavior without 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 front-loaded with the core purpose in the first sentence, followed by essential context (optional tip, authentication) in the second. Every sentence earns its place with no wasted words, making it highly efficient and easy to parse.

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

  Completeness3/5

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

  Given the tool's complexity (a mutation with authentication needs), no annotations, and no output schema, the description is moderately complete. It covers the purpose, prerequisites, and key parameters but lacks details on behavioral aspects like response format, error cases, or side effects, leaving some gaps for the agent to infer.

  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?

  Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema by mentioning the tip is optional and in dollars, but does not provide additional context like format examples for 'booking_id' or review length guidelines. Baseline 3 is appropriate as the schema does the heavy lifting.

  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 specific action ('Rate and review'), the target resource ('a walker'), and the context ('after a completed walk on wagwalking.com'). It distinguishes from siblings like 'search_walkers' or 'view_walker_profile' by focusing on post-walk evaluation rather than discovery or viewing.

  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 when to use this tool ('after a completed walk'), but does not explicitly state when not to use it or name alternatives. It implies prerequisites (completed walk, booking ID) but lacks explicit exclusions or comparisons to sibling tools like 'get_walk_status' for checking walk completion.

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

• get_pet_reportA
  4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries full burden and effectively discloses key behavioral traits: it's a read operation (implied by 'Get'), requires authentication ('Requires WAG_EMAIL and WAG_PASSWORD'), and specifies the data scope. However, it doesn't mention potential rate limits, error conditions, or response format details.

  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 efficiently structured in two sentences: the first clearly states purpose and content, the second specifies authentication requirements. Every element serves a purpose with no wasted words, making it easy to parse quickly.

  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?

  For a single-parameter read tool with no output schema, the description provides good context: purpose, content details, and authentication requirements. It could be more complete by mentioning response format or error handling, but covers the essential aspects well given the tool's simplicity.

  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?

  Schema description coverage is 100%, with the single parameter 'booking_id' well-documented in the schema. The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline score of 3 for high schema coverage without additional value.

  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 specific action ('Get the report card') and resource ('for a completed walk'), with detailed content listing ('photos, walker notes, potty breaks, behavior tags, and route map'). It distinguishes from siblings like 'get_walk_status' by focusing on post-walk reports rather than current status.

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

  Usage Guidelines3/5

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

  The description implies usage context by specifying 'for a completed walk' and authentication requirements, but doesn't explicitly state when to use this tool versus alternatives like 'get_walk_status' for ongoing walks or 'rate_walker' for feedback. It provides some guidance but lacks explicit comparisons.

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