lilo Vacation Rentals

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

Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds value by specifying the return format (risk assessment level, identified concerns, recommended actions), which isn't covered by annotations. However, it doesn't disclose additional behavioral traits like rate limits, authentication needs, or data sources used for analysis.

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 description is appropriately concise with two sentences: one stating the purpose and outputs, and another specifying the parameters. It's front-loaded with the core function. There's minimal waste, though it could be slightly more structured by explicitly separating input guidance from output details.

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?

Given the tool's complexity (risk analysis with multiple optional inputs) and lack of output schema, the description does a good job covering the essentials: purpose, parameters, and return format. With annotations providing safety context, it's mostly complete, though adding more behavioral context (e.g., analysis methodology) could enhance it further.

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%, with all three parameters clearly documented in the schema. The description mentions the same parameters (booking_id, message_content, guest_profile) but doesn't add meaningful semantics beyond what's in the schema, such as how they interact or which combinations are most effective. Baseline 3 is appropriate given the schema does the heavy lifting.

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 clearly states the tool's purpose: analyzing vacation rental bookings or guest interactions for threats and risks, with specific outputs (risk assessment level, concerns, recommended actions). It distinguishes from some siblings like 'assess_extended_stay_squatter_risk' by being more general, but doesn't explicitly differentiate from similar tools like 'analyze_guest_communication_risk' or 'detect_guest_communication_risk'.

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?

The description implies usage context by specifying what to pass (booking_id, message_content, guest_profile) for analysis, suggesting it's for evaluating existing bookings or communications. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like 'screen_guest_before_booking' (pre-booking) or 'assess_vacation_rental_booking_risk' (similar function), leaving room for ambiguity.

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

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

Annotations declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds value by specifying the output includes 'risk assessment, evidence documentation, and response guidance for hosts,' which goes beyond annotations. However, it doesn't disclose behavioral traits like rate limits, authentication needs, 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.

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

The description is concise and front-loaded, stating the core purpose in the first sentence. The second sentence adds output details and alias information efficiently. Both sentences earn their place, but minor improvements could make it more structured (e.g., separating output details into a bullet list).

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?

Given the tool's complexity (risk analysis with multiple parameters) and lack of output schema, the description is moderately complete. It outlines the purpose and output components but doesn't detail the format of 'risk assessment' or 'evidence documentation.' With annotations covering safety, it's adequate but could benefit from more context on output structure or usage scenarios.

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%, so parameters are well-documented in the schema. The description doesn't add any parameter-specific information beyond what's in the schema (e.g., it doesn't explain how 'conversation_history' affects analysis). With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate with extra semantic details.

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 clearly states the tool's purpose: 'Analyze guest messages at a vacation rental for concerning patterns.' It specifies the verb ('analyze'), resource ('guest messages'), and context ('vacation rental'). However, it doesn't explicitly differentiate from sibling tools like 'analyze_booking_threat_risk' or 'detect_guest_message_threat_pattern', which appear to have overlapping domains.

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?

The description implies usage context ('for concerning patterns' and 'for hosts') but doesn't provide explicit guidance on when to use this tool versus alternatives. It mentions an alias ('detect_guest_communication_risk'), which helps identify a direct alternative, but doesn't explain differences from other risk analysis tools in the sibling list.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds value by specifying the return format ('risk assessment and recommended actions'), which is useful context beyond annotations. However, it does not disclose other behavioral traits like rate limits, authentication needs, 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.

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

The description is efficiently structured in three sentences: purpose, return value, and parameters. Each sentence earns its place by providing essential information without redundancy, making it easy for an agent to parse quickly.

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?

Given the tool's complexity (risk analysis with optional parameters) and the absence of an output schema, the description is mostly complete. It covers purpose, return values, and parameters, but could improve by detailing the format of the risk assessment or examples of recommended actions to fully compensate for the missing output schema.

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%, so the schema already documents all three parameters. The description lists the parameters ('booking_id, message_content, and/or guest_profile') but does not add meaning beyond what the schema provides, such as explaining how they interact or which combinations are most effective. The baseline score of 3 is appropriate when the schema does the heavy lifting.

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 clearly states the specific action ('analyze'), resource ('guest interaction at a vacation rental'), and outcome ('potential risks', 'risk assessment and recommended actions'). It explicitly distinguishes this tool from its sibling 'analyze_booking_threat_risk' by noting it's an alias, helping the agent avoid duplication.

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?

The description provides clear context for when to use this tool ('analyze a guest interaction... for potential risks') and mentions an alternative ('alias for analyze_booking_threat_risk'), but does not explicitly state when NOT to use it or compare it to other risk-related siblings like 'detect_guest_communication_risk' or 'assess_vacation_rental_booking_risk'.

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

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

Annotations indicate readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds that answers are 'grounded in verified data,' which provides useful context about data reliability. However, it does not disclose other behavioral traits like response format, potential limitations (e.g., unanswered questions), or any rate limits. With annotations covering safety, a 3 is appropriate as the description adds some value but not rich behavioral details.

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 description is efficiently structured: it starts with the core purpose, provides concrete examples, and ends with parameter requirements. Every sentence earns its place, with no redundant or vague language, making it easy to parse and front-loaded with essential information.

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?

Given the tool's moderate complexity (interactive Q&A), rich annotations (readOnlyHint, destructiveHint), and 100% schema coverage, the description is mostly complete. It covers purpose, usage examples, and parameter requirements. However, without an output schema, it does not describe the return format (e.g., structured answer, confidence score), which is a minor gap for an agent invoking the 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?

Schema description coverage is 100%, with clear descriptions for all parameters (property_id, question, guest_id). The description mentions that property_id and question are required, and provides examples of question content, but does not add significant meaning beyond what the schema already documents. Baseline 3 is correct when the schema does the heavy lifting.

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 clearly states the tool's purpose: 'Ask a natural language question about a vacation rental property and get an answer grounded in verified data.' It specifies the verb ('ask'), resource ('vacation rental property'), and outcome ('answer grounded in verified data'), distinguishing it from sibling tools like 'get_vacation_rental_faqs' or 'get_vacation_rental_details' which provide static information rather than interactive Q&A.

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?

The description provides clear context for when to use this tool: for asking natural language questions about vacation rentals, with examples like 'What is the WiFi password?' and 'What time is check-out?'. It mentions the required parameters (property_id and question text) but does not explicitly state when not to use it or name specific alternatives among the many sibling tools, though the examples help differentiate its interactive nature from static lookup tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds valuable behavioral context beyond annotations by specifying what the tool evaluates (stay duration against laws) and what it returns (risk level, state laws, recommendations). It doesn't mention rate limits, authentication needs, or data sources, but provides meaningful operational context.

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 description is perfectly concise with three sentences that each serve distinct purposes: stating the tool's purpose, explaining its evaluation logic, and specifying required parameters. There's no wasted language, and the information is front-loaded with the core functionality stated immediately.

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?

For a read-only tool with good annotations and full schema coverage, the description provides sufficient context about what the tool does and returns. The main gap is the lack of output schema, so the description doesn't detail the structure of 'risk level, relevant state laws, and preventive recommendations.' However, given the tool's straightforward analytical purpose, the description is reasonably complete.

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?

With 100% schema description coverage, the input schema already documents all four parameters thoroughly. The description mentions three parameters (check_in_date, check_out_date, state code) but doesn't add semantic meaning beyond what the schema provides. It omits 'property_id' entirely. The baseline score of 3 reflects adequate parameter documentation primarily through the 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 clearly states the tool's purpose with specific verbs ('assess', 'evaluates') and resources ('guest establishing tenancy rights', 'extended vacation rental stay', 'jurisdiction-specific tenant protection laws'). It distinguishes itself from sibling tools by focusing specifically on squatter risk assessment for extended stays, unlike broader risk analysis tools like 'assess_vacation_rental_booking_risk' or communication-focused tools.

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?

The description implies usage context through its focus on extended stays and jurisdiction-specific laws, suggesting it should be used for longer-term vacation rentals where tenancy rights become relevant. However, it doesn't explicitly state when to use this tool versus alternatives like 'assess_vacation_rental_booking_risk' or provide clear exclusions for short-term stays.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds valuable context about what the tool returns ('risk level, identified concerns, and suggested protective actions') and mentions default behavior for 'include_guest_risk'. It doesn't disclose rate limits or authentication needs, but with annotations covering safety, this provides good supplemental behavioral insight.

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 description is a single, well-structured sentence that efficiently covers purpose, parameters, and output. It's front-loaded with the core function and avoids any redundant or unnecessary information, making it highly effective for quick comprehension.

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?

Given the tool's complexity (risk assessment with recommendations), lack of output schema, and rich annotations, the description is mostly complete. It explains the return content but could benefit from more detail on risk categories or example outputs. However, it adequately supports the agent's understanding for a read-only tool with clear parameters.

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%, with both parameters ('booking_id' and 'include_guest_risk') fully documented in the schema. The description mentions these parameters and the default for 'include_guest_risk', but doesn't add significant meaning beyond what's already in the schema descriptions. This meets the baseline for high schema coverage.

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 clearly states the specific action ('Assess risk factors'), target resource ('vacation rental booking'), and output ('risk level, identified concerns, and suggested protective actions'). It distinguishes from siblings like 'analyze_booking_threat_risk' by focusing on comprehensive risk assessment with protection recommendations rather than just threat analysis.

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?

The description implies usage context through 'risk factors' and 'protection recommendations', suggesting it's for evaluating booking safety. However, it doesn't explicitly state when to use this tool versus alternatives like 'screen_guest_before_booking' or 'predict_booking_chargeback_probability', nor does it mention prerequisites or exclusions.

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

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

Annotations indicate readOnlyHint=false and destructiveHint=true, which the description aligns with by implying a write operation ('Assign'). The description adds valuable context beyond annotations by specifying that it handles 'primary and backup cleaner assignments' and 'turnover between bookings,' clarifying the operational scenario. However, it does not detail potential side effects, error conditions, or confirmation 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?

The description is two sentences: the first states purpose and scope, the second lists parameters. It is front-loaded with essential information, avoids redundancy, and every sentence contributes directly to tool understanding without waste.

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?

For a destructive tool with no output schema, the description adequately covers the basic operation and parameters. However, it lacks details on return values, error handling, or confirmation steps, which could be important for safe invocation. Given the annotations provide safety hints, the description is minimally complete but could be more informative.

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%, so parameters are well-documented in the schema. The description lists the parameters ('property_id, cleaner_id, booking_id, optional role (primary/backup), and scheduled_date') but adds minimal semantic value beyond the schema, such as explaining relationships between parameters or usage nuances. Baseline 3 is appropriate given high schema coverage.

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 clearly states the specific action ('Assign a cleaner'), target resource ('to a vacation rental property turnover between bookings'), and scope ('Supports primary and backup cleaner assignments'). It distinguishes itself from sibling tools by focusing on cleaner assignment rather than analysis, booking, verification, or other functions listed among the siblings.

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?

The description implies usage for assigning cleaners during turnover periods, but does not explicitly state when to use this tool versus alternatives (e.g., 'get_rental_cleaning_schedule' for viewing schedules). No exclusions or prerequisites are mentioned, leaving the agent to infer context from the tool's purpose alone.

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

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

Annotations indicate readOnlyHint=false and destructiveHint=true, but the description adds valuable context beyond this: it explains financial details ('Host receives 100% of nightly rate; 3% guest service fee added at checkout'), the notification process ('notifies the host'), and return values. It doesn't contradict annotations, as 'destructiveHint=true' aligns with creating a booking record, but could mention irreversible aspects more explicitly.

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 description is front-loaded with key actions and structured efficiently in two sentences: one for the booking process and fees, another for operations and prerequisites. Every sentence adds value without redundancy, making it easy to parse quickly.

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?

Given the tool's complexity (destructive booking operation) and lack of output schema, the description is mostly complete: it covers purpose, usage guidelines, financial behavior, and return values. However, it could improve by detailing error cases or confirmation steps, but annotations help fill gaps, making it sufficient for agent use.

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%, so the schema already documents all 8 parameters. The description adds no specific parameter semantics beyond what the schema provides, such as format examples or constraints. It implies parameters like 'property_id' and dates but doesn't enhance their meaning, meeting the baseline for high schema coverage.

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 clearly states the tool's purpose with specific verbs ('Book', 'Creates', 'calculates', 'notifies') and resources ('vacation rental property'), distinguishing it from siblings like 'check_vacation_rental_availability_and_pricing' by emphasizing the booking action. It explicitly differentiates from risk analysis or search tools in the sibling list.

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?

The description provides explicit usage guidance: 'Always call check_vacation_rental_availability_and_pricing first.' This clearly states a prerequisite and distinguishes when to use this tool versus alternatives, such as availability checks or risk assessments among siblings.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds useful context about what information is returned (permits, application processes, fees, renewal schedules), which goes beyond annotations, but does not detail behavioral aspects like rate limits, authentication needs, or data freshness.

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 description is efficiently structured in two sentences: the first states the purpose and return values, the second specifies parameters. Every sentence adds necessary information with zero waste, making it front-loaded and appropriately sized.

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?

Given the tool's moderate complexity (3 parameters, 1 required), rich annotations (readOnlyHint, destructiveHint), and 100% schema coverage, the description is largely complete. It explains the purpose, return values, and parameter usage. However, without an output schema, it could benefit from more detail on return format or limitations, but annotations help cover safety aspects.

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%, with clear descriptions for all parameters (state, city, property_id). The description adds minimal value by noting that state is required and city/property_id are optional, but does not provide additional semantic context beyond what the schema already documents.

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 clearly states the specific action ('Check what permits and licenses are required') and resource ('to operate a short-term rental at a specific location'), distinguishing it from siblings like 'get_short_term_rental_regulations' or 'get_str_insurance_requirements' by focusing on permit requirements for a specific location rather than general regulations or insurance.

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?

The description implies usage by specifying the target (short-term rental permits at a location) and listing parameters, but does not explicitly state when to use this tool versus alternatives like 'get_short_term_rental_regulations' or provide exclusions. The context is clear but lacks explicit guidance on alternatives.

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

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

Annotations declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds valuable behavioral context beyond this: it specifies 'real-time' availability/pricing, discloses financial details ('Host receives 100% of nightly rate; 3% guest service fee at checkout'), and mentions what the tool returns (availability, total price, capacity check, conflicting bookings). While it doesn't cover rate limits or error handling, it significantly enhances transparency 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.

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

The description is highly concise and well-structured: two sentences that front-load the core functionality and follow with critical usage guidance. Every sentence earns its place—the first defines purpose and output, the second adds financial context and prerequisite rule—with zero wasted words or redundancy.

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?

Given the tool's complexity (real-time checks with financial implications), the description is mostly complete. It explains the tool's purpose, output, financial context, and usage sequence. However, there is no output schema, and the description doesn't detail the return format (e.g., structure of 'conflicting bookings'). With annotations covering safety and schema covering inputs, the description provides strong context but leaves some output ambiguity.

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%, with all parameters well-documented in the schema (e.g., property_id as 'Property UUID or lilo_code', dates in YYYY-MM-DD format). The description adds no additional parameter semantics beyond what the schema provides, such as explaining how guest_count affects pricing or capacity. Given the high schema coverage, a baseline score of 3 is appropriate as the description doesn't compensate but doesn't need to.

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 clearly states the tool's purpose with specific verbs ('Check real-time availability and pricing') and resource ('vacation rental property'), distinguishing it from siblings like 'book_vacation_rental_direct' (which books) or 'get_vacation_rental_details' (which retrieves static info). It explicitly mentions what it returns (availability, pricing, capacity check, conflicting bookings), making the purpose unambiguous.

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?

The description provides explicit usage guidance: 'Always call this BEFORE book_vacation_rental_direct.' This clearly indicates when to use this tool (as a prerequisite check) versus its sibling 'book_vacation_rental_direct' (for actual booking). It also implies an alternative (the booking tool) and sets a clear sequence, leaving no ambiguity about its role.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds valuable context by specifying the return data (protection status, tier, features, timestamp), which goes beyond annotations and helps the agent understand the output structure without an output schema.

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 description is a single, efficient sentence that front-loads the purpose and lists the return values clearly. There is no wasted verbiage, and every part of the sentence contributes essential information.

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?

Given the tool's low complexity (1 parameter, no output schema) and rich annotations, the description is mostly complete. It specifies what is returned, compensating for the lack of output schema. However, it could slightly improve by mentioning error cases or prerequisites, but it's sufficient for effective use.

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%, with the parameter 'property_id' fully documented in the schema. The description does not add any additional meaning or details about the parameter beyond what the schema provides, so it meets the baseline of 3.

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 clearly states the specific action ('Check whether a vacation rental property is actively protected by lilo') and the resource ('vacation rental property'), distinguishing it from siblings like 'get_vacation_rental_details' or 'get_vacation_rental_onboarding_status' by focusing on protection status rather than general information or onboarding.

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?

The description implies usage for checking protection status but does not explicitly state when to use this tool versus alternatives (e.g., 'get_vacation_rental_onboarding_status' might overlap). It provides context but lacks explicit guidance on exclusions or named alternatives.

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

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

Annotations indicate readOnlyHint=true and destructiveHint=false, which the description aligns with by describing a checking operation. The description adds valuable context beyond annotations by specifying the temporal scope ('during the tournament') and the types of compliance details returned, enhancing the agent's understanding of what to expect without contradicting annotations.

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 description is a single, well-structured sentence that efficiently conveys purpose, scope, output details, and parameter guidance. It is front-loaded with key information and avoids redundancy, making every word count without unnecessary elaboration.

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?

Given the tool's complexity (checking compliance with specific parameters), the description is mostly complete: it covers purpose, scope, output types, and parameter notes. However, without an output schema, it could benefit from more detail on return format or error handling, but annotations and schema coverage mitigate this gap adequately.

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%, with clear descriptions for 'city' and 'property_id'. The description adds minimal semantics by noting that city is required and property_id is optional, but does not provide additional details like city format or property_id usage beyond what the schema already covers, meeting the baseline for high schema coverage.

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 clearly states the verb ('Check') and resource ('World Cup 2026 specific short-term rental compliance requirements'), specifying the scope ('for the 16 US host cities') and output details ('special regulations, surge pricing rules, enhanced permit requirements, and safety standards'). It effectively distinguishes itself from sibling tools like 'get_short_term_rental_regulations' by focusing on tournament-specific requirements.

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?

The description implies usage context by mentioning 'during the tournament' and lists sibling tools, but does not explicitly state when to use this tool versus alternatives like 'get_short_term_rental_regulations' or 'get_philadelphia_world_cup_2026_info'. It provides some guidance through scope but lacks explicit comparisons or exclusions.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds valuable context beyond annotations by specifying the comparison scope (up to 5 properties) and the key metrics included, which helps the agent understand what behavioral output to expect. However, it does not mention rate limits, authentication needs, 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.

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

The description is a single, well-structured sentence that efficiently conveys the tool's purpose, scope, and key metrics without any redundant information. It is front-loaded with the core action and appropriately sized for the tool's complexity.

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?

Given the tool's moderate complexity (comparison of multiple properties), the description is mostly complete. It lacks an output schema, so the description does not explain return values, but it compensates by listing the key metrics compared. With annotations covering safety and the schema fully documenting parameters, the description provides sufficient context for agent use, though output details are missing.

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%, with the parameter 'property_ids' fully documented in the schema as an array of strings with a max of 5 items. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or ID sourcing. Baseline 3 is appropriate when the schema handles all parameter documentation.

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 clearly states the specific action ('compare'), resource ('vacation rental properties'), scope ('up to 5'), and key metrics ('price, bedrooms, bathrooms, amenities, reputation score, and protection status'). It distinguishes itself from sibling tools like 'get_vacation_rental_details' or 'search_vacation_rentals_by_amenities' by emphasizing side-by-side comparison rather than individual retrieval or filtering.

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?

The description implies usage when comparing multiple properties, but does not explicitly state when to use this tool versus alternatives like 'get_vacation_rental_details' for single properties or 'search_vacation_rentals_by_amenities' for filtering. It provides basic context (comparing up to 5 properties) but lacks explicit exclusions or named alternatives.

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

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

Annotations provide readOnlyHint=false and destructiveHint=true, indicating a mutation operation with destructive potential. The description adds valuable context beyond annotations by specifying that it 'Supports one-time and recurring tasks' and listing the task_type enum values, which helps the agent understand the tool's capabilities. However, it doesn't mention authentication requirements, rate limits, or what exactly gets destroyed (e.g., whether existing tasks are overwritten).

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 description is efficiently structured in two sentences: the first states the purpose and key features, the second lists parameters with clear required/optional distinction. Every word serves a purpose with no redundancy or fluff, making it easy to parse quickly.

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?

For a creation tool with 8 parameters, 100% schema coverage, and annotations indicating destructive mutation, the description provides adequate context about what the tool does and what parameters it accepts. However, without an output schema, it doesn't describe what the tool returns (e.g., task ID, confirmation message), leaving a minor gap in completeness for the agent's understanding of the full operation.

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%, with all parameters well-documented in the schema (including enums for priority and task_type, and format for due_date). The description lists parameters and provides the task_type enum values, but adds minimal semantic value beyond what the schema already provides. The baseline of 3 is appropriate given the comprehensive schema coverage.

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 clearly states the specific action ('Create a new maintenance task') and resource ('for a vacation rental property'), distinguishing it from sibling tools like 'get_rental_maintenance_schedule' (which retrieves rather than creates) and 'assign_cleaner_to_rental_turnover' (which handles cleaning assignments rather than maintenance tasks). It specifies the scope of supported task types (one-time and recurring).

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?

The description implies usage by listing required parameters and optional ones, but does not explicitly state when to use this tool versus alternatives. It mentions 'Supports one-time and recurring tasks' which provides some context, but lacks explicit guidance on prerequisites, when-not-to-use scenarios, or named alternatives among siblings.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds useful behavioral context: it returns 'risk assessment, evidence documentation, and response guidance for hosts' and includes 'guest/property cross-referencing.' However, it doesn't disclose other behavioral traits like rate limits, authentication needs, or error conditions. With annotations covering safety, a 3 is appropriate—the description adds some value but not rich behavioral details.

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 description is appropriately sized and front-loaded: the first sentence states the core purpose, and the second adds differentiation from a sibling tool. Every sentence earns its place with no wasted words, making it efficient and easy to parse.

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?

Given the tool's complexity (risk analysis with multiple parameters) and lack of output schema, the description is reasonably complete. It explains the purpose, distinguishes from a sibling, and hints at return values ('risk assessment, evidence documentation, and response guidance'). However, without an output schema, more detail on return structure would be helpful, but the description compensates adequately for a non-critical analysis 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?

Schema description coverage is 100%, so the schema already documents all 5 parameters thoroughly. The description implies the tool uses 'guest/property cross-referencing' (hinting at booking_id, guest_name, property_id) and 'conversation context analysis' (hinting at conversation_history), but doesn't add syntax or format details beyond what the schema provides. Baseline 3 is correct when schema does the heavy lifting.

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 clearly states the tool's purpose: 'Analyze guest messages for risk patterns in vacation rental communications.' It specifies the verb ('Analyze'), resource ('guest messages'), and domain context ('vacation rental communications'). It also explicitly distinguishes from sibling 'detect_guest_message_threat_pattern' by stating it's 'more comprehensive' and includes 'documentation and guest/property cross-referencing.'

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?

The description provides clear context for when to use this tool: analyzing guest messages for risk patterns. It explicitly mentions an alternative ('detect_guest_message_threat_pattern') and explains this tool is 'more comprehensive.' However, it doesn't specify when NOT to use it or mention other potential alternatives among the many sibling tools, which prevents a perfect score.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds useful context about the tool's focus on 'concerning patterns' and 'risks to the vacation rental host,' and mentions the return format ('threat assessment and recommended response'). However, it doesn't disclose behavioral details like rate limits, authentication requirements, or how the analysis is performed beyond what annotations provide.

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 description is concise and well-structured in two sentences: the first explains the purpose and inputs, and the second states the output. It avoids unnecessary details and is front-loaded with the core functionality. However, it could be slightly more efficient by combining ideas more tightly.

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?

Given the tool's moderate complexity (analyzing messages for threats), the description covers the basic purpose, inputs, and outputs. However, there's no output schema, so the description must fully explain return values, which it does minimally ('threat assessment and recommended response'). With annotations covering safety, it's adequate but lacks depth on behavioral aspects like error handling or analysis methodology.

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%, so the input schema already documents all parameters thoroughly. The description mentions 'message text and optional conversation_history for context,' which aligns with the schema but doesn't add significant semantic value beyond it. The baseline score of 3 is appropriate since the schema handles most parameter documentation.

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 clearly states the tool's purpose: 'Analyze a guest message or conversation for concerning patterns that may indicate risks to the vacation rental host.' It specifies the verb ('analyze'), resource ('guest message or conversation'), and goal ('detect risks'). However, it doesn't explicitly differentiate from similar siblings like 'detect_guest_communication_risk' or 'analyze_guest_communication_risk', which appear to have overlapping functions.

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?

The description provides some usage context by mentioning 'optional conversation_history for context' and specifying the input parameters. However, it doesn't explicitly state when to use this tool versus alternatives like 'detect_guest_communication_risk' or 'analyze_booking_threat_risk', nor does it outline any prerequisites or exclusions for its use.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds useful context about the return format ('full property data including...') and optimization for AI consumption, but doesn't disclose behavioral traits like rate limits, authentication needs, or error conditions beyond what annotations provide.

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 description is efficiently structured in two sentences: the first states the purpose and parameter, the second details the return data and optimization. Every phrase adds value with zero wasted words, and key information is front-loaded.

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?

For a read-only tool with good annotations and a simple single-parameter schema, the description provides adequate context about what data is returned and the tool's optimization. However, without an output schema, more detail about the return structure would be helpful, and it doesn't address potential limitations or error 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% with only one parameter fully documented. The description reinforces the parameter's purpose ('by its lilo code') and provides an example format ('e.g. PROP-2343'), but doesn't add significant meaning beyond what the schema already provides. 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.

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

The description clearly states the specific action ('Fetch complete details'), resource ('vacation rental property'), and identifier mechanism ('by its lilo code'). It distinguishes from sibling tools by specifying it returns comprehensive property data rather than performing analysis, booking, or searching functions.

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?

The description provides clear context for when to use this tool ('for a specific vacation rental property by its lilo code') and implies it's for 'AI deep research consumption.' However, it doesn't explicitly state when not to use it or name alternative tools for similar purposes.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds useful context about the tool's purpose (finding similar rentals) and default behavior (limit default 5), but does not disclose additional behavioral traits like how similarity is determined, response format, or error handling. With annotations covering safety, the description adds some value but not rich behavioral details.

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 description is two sentences, front-loaded with the core purpose followed by usage context and parameter hints. Every sentence earns its place with no wasted words, making it efficient and well-structured for quick understanding.

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?

Given the tool's moderate complexity (2 parameters, read-only operation), the description covers purpose, usage, and basic parameter info. However, there is no output schema, and the description does not explain return values or similarity criteria. With annotations providing safety context, it is mostly complete but could benefit from more behavioral detail for a higher score.

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%, with clear descriptions for both parameters (property_id and limit). The description adds minimal semantics by mentioning property_id accepts 'UUID or lilo_code' and limit is 'optional (default 5)', but this mostly repeats or slightly elaborates on schema info. 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.

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

The description clearly states the verb 'find' and resource 'vacation rentals similar to a given property', making the purpose specific. It distinguishes from siblings like 'search_vacation_rentals_by_location' or 'compare_vacation_rentals_side_by_side' by focusing on similarity based on a property ID rather than location, amenities, or direct comparison.

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?

The description provides clear context for when to use this tool: 'Useful for recommending alternatives when a property is unavailable or when the traveler wants to compare similar options.' This gives practical scenarios, but it does not explicitly state when not to use it or name specific alternatives among siblings, which prevents a score of 5.

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

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

Annotations indicate readOnlyHint=false and destructiveHint=true, confirming this is a mutation with potential side effects. The description adds valuable context beyond annotations by specifying that it 'Creates an alert' and involves 'lilo's protection system,' which clarifies the behavioral impact. It does not detail rate limits or auth needs, but with annotations covering safety, this provides sufficient transparency.

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 description is front-loaded with the core purpose in the first sentence, followed by additional details in two concise sentences. Every sentence adds value: the first defines the action, the second explains the outcome, and the third provides usage and parameter guidance. There is no wasted text, making it efficient and well-structured.

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?

For a mutation tool with destructiveHint=true and no output schema, the description is reasonably complete. It covers purpose, usage context, and parameters, though it lacks details on response format or error handling. Given the annotations provide safety context and schema covers parameters, this is adequate but could be enhanced with output expectations.

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%, with clear descriptions for all parameters (booking_id, reason, risk_indicators). The description adds minimal semantics by mentioning 'Requires booking_id and reason' and 'Optional: array of risk_indicators,' but this mostly repeats what the schema already states. 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.

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

The description clearly states the specific action ('Flag a vacation rental booking for enhanced monitoring') and resource ('booking'), distinguishing it from sibling tools like 'analyze_booking_threat_risk' or 'assess_vacation_rental_booking_risk' which analyze rather than flag. It specifies the system involved ('lilo's protection system') and the outcome ('Creates an alert'), making the purpose unambiguous.

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?

The description provides clear context for when to use this tool ('when a host identifies concerning behavior'), which helps differentiate it from analysis tools. However, it does not explicitly state when not to use it or name specific alternatives among the many siblings, such as 'report_rental_inventory_issue' for other issues, leaving some ambiguity in tool selection.

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

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

Annotations indicate readOnlyHint=true and destructiveHint=false, which the description aligns with by describing a forecasting operation. The description adds valuable behavioral context beyond annotations by specifying the return content (seasonal trends, event-driven demand spikes, occupancy predictions, pricing recommendations), which helps the agent understand the output format and scope.

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 description is front-loaded with the core purpose and efficiently lists return values and parameters in two sentences. It avoids unnecessary details, though it could be slightly more structured (e.g., separating return items with bullets).

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?

Given the tool's moderate complexity (forecasting with 3 parameters), annotations cover safety (read-only, non-destructive), and the description adds output details, it is mostly complete. However, without an output schema, the description could benefit from more specifics on return format (e.g., structured data types), but it adequately conveys the key information for agent use.

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%, so the schema already documents all parameters. The description mentions the parameters ('location (required), date_range_start, and date_range_end') but does not add significant semantic details beyond what the schema provides, such as format examples or constraints. Baseline 3 is appropriate as the schema handles most of the parameter documentation.

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 clearly states the tool's purpose with specific verbs ('forecast booking demand') and resources ('vacation rentals in a specific location over a date range'). It distinguishes from siblings by focusing on demand forecasting rather than risk analysis, booking, or compliance checks, which are covered by other tools like 'analyze_booking_threat_risk' or 'check_vacation_rental_availability_and_pricing'.

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?

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or compare it to similar tools like 'search_vacation_rental_market' or 'get_vacation_rental_pricing_analysis', leaving the agent to infer usage context.

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

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

Annotations indicate destructiveHint=true and readOnlyHint=false, suggesting this is a write operation that may have side effects. The description adds valuable context beyond annotations by specifying the 3% guest service fee and confirming it's a generation operation (not just a read). There's no contradiction with annotations - 'generate' aligns with destructiveHint=true as it likely creates/modifies feed data.

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 description is efficiently structured in two sentences: first stating the core purpose and business value, second covering required parameters. Every element earns its place with no redundant information. It's appropriately sized for a tool with 2 parameters and clear functionality.

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?

For a tool with 2 parameters, 100% schema coverage, and annotations covering safety profile, the description provides good contextual completeness. It explains the business purpose (direct booking via Google Search), mentions the service fee, and covers parameter basics. The main gap is lack of output schema, so the description doesn't specify what the generated feed looks like, but this is partially compensated by mentioning output format options.

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?

With 100% schema description coverage, the input schema already fully documents both parameters (host_id as 'Host UUID to generate feed for' and format as 'Output format: xml or json (default xml)'). The description repeats this information but doesn't add meaningful semantic context beyond what's in the schema. 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.

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

The description clearly states the specific action ('Generate a Google Vacation Rentals XML feed'), the resource ('for a host's properties'), and the business purpose ('Enables direct booking via Google Search results with a 3% guest service fee'). It distinguishes itself from sibling tools by focusing on feed generation rather than analysis, booking, or verification operations.

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?

The description provides clear context about when to use this tool (to enable direct booking via Google Search results), but doesn't explicitly state when not to use it or name specific alternatives among the many sibling tools. The mention of '3% guest service fee' implies a cost consideration, which is helpful guidance.

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

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

Annotations indicate readOnlyHint=false and destructiveHint=true, suggesting a write operation with potential destructive effects. The description adds value by clarifying the output ('tax documentation... for tax filing') and the optional quarter parameter, but it does not elaborate on the destructive nature (e.g., what gets modified or overwritten) or other behavioral traits like permissions or rate limits.

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 description is front-loaded with the core purpose, followed by parameter guidance in two efficient sentences. Every sentence adds value: the first defines the tool's function and components, and the second specifies parameter requirements and options, with no redundant or vague language.

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?

Given the tool's complexity (tax documentation generation with destructive hints) and lack of an output schema, the description is adequate but incomplete. It covers the purpose and parameters well but does not detail the output format, potential side effects from destructiveHint, or error conditions, leaving gaps for an AI agent to infer behavior.

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%, with clear descriptions for year, host_id, and quarter. The description adds minimal semantics by reiterating that host_id is a UUID and quarter is optional (1-4), but it does not provide additional context like format examples or usage scenarios beyond what the schema already documents.

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 clearly states the specific action ('Generate tax documentation') and resource ('for short-term rental income'), with detailed components like 'occupancy tax calculations, income summaries, and reporting data for tax filing.' It effectively distinguishes itself from sibling tools focused on risk analysis, booking, compliance, and other rental management functions.

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?

The description implies usage by specifying required parameters (host_id and year) and an optional quarter for quarterly reports, but it does not explicitly state when to use this tool versus alternatives or provide context about prerequisites. No sibling tools overlap in tax documentation generation, so differentiation is inherent but not articulated.

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

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

Annotations indicate readOnlyHint=true and destructiveHint=false, covering safety. The description adds valuable behavioral context beyond annotations: it specifies the output includes 'verified evidence of guest consent, check-in documentation, and interaction history', which helps the agent understand what the generated packet contains. 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.

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

The description is two sentences, front-loaded with the core purpose and efficiently listing parameters. Every sentence adds value without waste, making it easy to scan and understand quickly.

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?

For a tool with good annotations (read-only, non-destructive) and full schema coverage, the description is mostly complete. It adds output details (evidence types in the packet), though no output schema exists. It could improve by specifying format (e.g., PDF bundle) or usage timing, but gaps are minor given the context.

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%, so the schema fully documents parameters. The description mentions parameters ('Pass booking_id (UUID), optional dispute_id, and disputed amount in cents') but adds no additional meaning beyond the schema's descriptions. 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.

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

The description clearly states the specific action ('Generate a chargeback defense packet') and resource ('for a payment dispute on a vacation rental booking'), with details about the evidence included. It distinguishes from sibling tools like 'get_dispute_defense_packet_for_booking' by specifying the packet is for chargebacks and includes verified evidence types.

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?

The description implies usage context (payment disputes on vacation rentals) and mentions optional parameters, but does not explicitly state when to use this tool versus alternatives like 'get_dispute_defense_packet_for_booking' or 'get_dispute_evidence_bundle_for_booking'. No exclusions or prerequisites are provided.

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

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

Annotations provide readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds value by specifying the output includes 'independently verified evidence', which clarifies the nature of the generated packet beyond what annotations convey. However, it lacks details on format, size, or any limitations like rate limits.

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 description is a single, efficient sentence that front-loads the core purpose and includes the alias information without unnecessary elaboration. Every word contributes to understanding the tool's function.

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?

Given the tool's complexity (generating evidence packets), annotations cover safety, and schema fully describes inputs, the description is mostly complete. However, without an output schema, it could benefit from more detail on the packet format or evidence types, though the mention of 'independently verified evidence' partially compensates.

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%, with clear descriptions for booking_id, amount, and dispute_id. The description does not add any parameter-specific details beyond the schema, such as explaining how amount or dispute_id affect the output. Baseline score of 3 is appropriate as the schema adequately documents parameters.

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 clearly states the specific action ('Generate a dispute defense packet with independently verified evidence') and resource ('for a vacation rental payment dispute'), distinguishing it from siblings like 'get_chargeback_defense_for_booking' by noting it's an alias, and from other tools that analyze risk or manage bookings rather than generating evidence packets.

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?

The description implies usage context ('for a vacation rental payment dispute') and mentions an alternative ('Alias for get_chargeback_defense_for_booking'), but does not explicitly state when to use this tool versus other dispute-related tools like 'get_dispute_evidence_bundle_for_booking' or 'predict_booking_chargeback_probability', leaving some ambiguity.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds valuable context beyond annotations by specifying what the bundle includes ('all verified interactions, consent records, and documentation') and the purpose ('for dispute resolution'), which helps the agent understand the output's nature and use case. No contradiction 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.

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 content, the second specifies required parameters. Every sentence adds essential information with zero wasted words, making it easy to parse and front-loaded with key details.

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?

Given the tool's moderate complexity (2 parameters, no output schema), annotations cover safety (read-only, non-destructive), and the description clarifies the bundle's contents and purpose. However, without an output schema, the description could better explain the return format (e.g., file type, structure) to fully prepare the agent for what to expect.

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%, with both parameters (booking_id and dispute_type) fully described in the schema. The description adds minimal semantic value by restating the parameter names and dispute_type values, but does not provide additional context like format examples or usage nuances beyond what the schema already covers.

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 clearly states the specific action ('Generate a complete evidence bundle') and resource ('for dispute resolution on a vacation rental booking'), including the scope ('all verified interactions, consent records, and documentation'). It distinguishes from sibling tools like 'get_chargeback_defense_for_booking' or 'get_evidence_timeline_for_rental' by focusing on comprehensive bundle generation rather than specific defenses or timelines.

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?

The description implies usage context by mentioning 'dispute resolution' and listing dispute_type values, but does not explicitly state when to use this tool versus alternatives like 'get_dispute_defense_packet_for_booking' or 'query_vacation_rental_evidence_chain'. It provides basic parameter guidance but lacks explicit when/when-not instructions or named alternatives.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds useful context about the return format ('events in order with timestamps, types, and verification status'), but does not disclose behavioral traits like pagination, rate limits, or authentication needs beyond what annotations provide.

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 description is front-loaded with the core purpose, followed by filtering and return details in two efficient sentences. Every sentence earns its place without redundancy, making it appropriately sized and well-structured.

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?

Given the tool's moderate complexity (4 parameters, no output schema), the description is complete enough for a read-only operation with good annotations. It covers purpose, filtering, and return format, though it could benefit from mentioning any limitations (e.g., max date range) or error handling for missing parameters.

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%, so the schema already documents all four parameters. The description adds marginal value by mentioning 'Filter by date range' and 'specific booking', which aligns with the schema's 'start_date', 'end_date', and 'booking_id', but does not provide additional syntax or format details beyond what the schema specifies.

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 clearly states the tool's purpose with specific verbs ('Get a chronological timeline') and resources ('evidence records for a vacation rental property or specific booking'), distinguishing it from siblings like 'query_vacation_rental_evidence_chain' or 'verify_vacation_rental_evidence_record' by focusing on timeline retrieval rather than querying or verification.

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?

The description provides clear context for when to use this tool ('Filter by date range') and implies usage for chronological evidence retrieval. However, it does not explicitly state when not to use it or name specific alternatives among siblings, such as 'query_vacation_rental_evidence_chain' for non-chronological queries.

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

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

Annotations provide readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds valuable context beyond annotations by specifying the exact data returned (total_spots, spots_claimed, etc.) and confirming no parameters are required, which helps the agent understand the tool's behavior without relying solely on annotations.

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 description is front-loaded with the core purpose, followed by specific return details, and ends with a clear statement about parameters. Every sentence adds value without redundancy, making it efficient and well-structured.

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?

For a tool with 0 parameters, read-only annotations, and no output schema, the description provides sufficient context by detailing the return values and confirming no inputs. However, it lacks information on potential errors or rate limits, which could be useful for full completeness.

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?

With 0 parameters and 100% schema description coverage, the baseline is 4. The description explicitly states 'No parameters required,' which reinforces the schema and adds clarity, preventing any confusion about input needs.

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 clearly states the tool's purpose with specific verbs ('Check how many founding member spots remain') and identifies the resource ('lilo's vacation rental protection'). It distinguishes itself from sibling tools by focusing on membership availability rather than risk analysis, booking, or other functions listed among siblings.

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?

The description implies usage context by specifying what data is returned (spots and pricing), but it does not explicitly state when to use this tool versus alternatives. No exclusions or prerequisites are mentioned, leaving the agent to infer usage based on the purpose alone.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, establishing this as a safe read operation. The description adds valuable context beyond annotations by specifying what data is returned (three specific metrics) and confirming no parameters are needed. It doesn't mention rate limits, authentication requirements, or response format details, but provides useful behavioral information about the tool's scope and output.

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 description is perfectly front-loaded with the core purpose in the first clause, followed by specific return details, and ends with the crucial parameter information. Every sentence earns its place, with zero wasted words or redundant information. The structure moves from general to specific in a logical flow.

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?

For a zero-parameter read-only tool with good annotations, the description provides excellent coverage of purpose, output details, and parameter requirements. The main gap is the absence of an output schema, so the agent doesn't know the exact structure of the returned data. However, the description does specify the three metrics that will be included, which provides substantial guidance for a simple stats retrieval 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?

With 0 parameters and 100% schema description coverage, the baseline would be 4. The description explicitly states 'No parameters required,' which reinforces what the empty input schema already shows. This clear confirmation adds value by eliminating any potential ambiguity about whether parameters might be optional rather than truly absent.

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 clearly states the verb ('Get') and resource ('aggregate statistics about the lilo vacation rental protection network'), specifying the exact data returned (total properties protected, evidence integrity status, active protection capabilities). It distinguishes itself from sibling tools like 'check_vacation_rental_protection_status' by focusing on network-wide aggregates rather than individual property status.

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?

The description provides clear context for when to use this tool ('Get aggregate statistics'), and explicitly states 'No parameters required' which helps the agent understand this is a simple data retrieval operation. However, it doesn't explicitly mention when NOT to use it or name specific alternatives among the many sibling tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds context about what types of recommendations are returned (restaurants, coffee shops, etc.) and mentions filtering capability, which provides useful behavioral details beyond the annotations. However, it doesn't disclose rate limits, authentication needs, or result format.

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 description is appropriately concise with two sentences that efficiently convey the core functionality. The first sentence states the purpose and return values, the second explains filtering. No wasted words, though it could be slightly more structured with bullet points for the recommendation types.

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?

For a read-only tool with good annotations and full schema coverage, the description provides adequate context about what the tool returns. However, without an output schema, it doesn't specify the structure or format of recommendations (e.g., distance, ratings, addresses). The description covers the basics but leaves return format ambiguous.

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%, so the schema already fully documents both parameters. The description mentions filtering by type which aligns with the 'type' parameter, but adds no additional semantic context beyond what's in the schema. This meets the baseline expectation when schema coverage is complete.

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 clearly states the tool's purpose: 'Get local recommendations near a vacation rental property' with specific resources listed (restaurants, coffee shops, etc.). It distinguishes itself from most siblings by focusing on local recommendations, though it doesn't explicitly differentiate from 'get_neighborhood_info_for_rental' which might overlap in scope.

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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, timing, or how it differs from similar tools like 'get_neighborhood_info_for_rental' or location-based search tools in the sibling list. Usage is implied but not explicitly stated.

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

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

Annotations indicate read-only and non-destructive behavior, which the description aligns with by using 'Get' (implying retrieval). The description adds valuable context beyond annotations by specifying the types of neighborhood information returned (safety scores, walkability, etc.), which helps the agent understand the tool's output scope. No contradictions with annotations are present.

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 description is efficiently structured in two sentences: the first states the tool's purpose with specific details, and the second provides usage context. Every word adds value, with no redundancy or unnecessary information, making it easy to parse and understand quickly.

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?

Given the tool's moderate complexity (retrieval of neighborhood data), the description is complete enough with annotations covering safety (read-only, non-destructive) and the description outlining the information scope. However, the lack of an output schema means the agent must infer the return format from the description alone, which is adequate but could be more precise about data structure or limitations.

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?

The input schema has 100% description coverage, with the single parameter 'property_id' clearly documented. The description does not add any parameter-specific details beyond what the schema provides, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't need to.

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 clearly states the tool's purpose with specific verbs ('Get neighborhood information') and resources ('for a vacation rental location'), listing concrete information types like safety scores, walkability, and amenities. It distinguishes itself from sibling tools like 'get_vacation_rental_details' or 'get_local_recommendations_near_rental' by focusing on neighborhood characteristics rather than property details or specific recommendations.

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?

The description implies usage context ('Helps travelers understand the area around a property'), suggesting it's for travel planning or property evaluation. However, it lacks explicit guidance on when to use this tool versus alternatives like 'get_local_recommendations_near_rental' or 'get_vacation_rental_details', and does not mention any prerequisites or exclusions.

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

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

The description adds useful context beyond annotations: it specifies the return content (historic sites, celebrations, visitor numbers, accommodation predictions) and notes 'No parameters required.' The annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description doesn't add behavioral details like rate limits or authentication requirements, but provides adequate context given 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.

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

The description is perfectly concise and front-loaded: a single sentence that immediately states the tool's purpose, specifies what it returns, and notes the parameter situation. Every word earns its place with zero wasted text.

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?

For a parameterless read-only tool with good annotations, the description is nearly complete. It specifies what information will be returned (historic sites, celebrations, visitor numbers, accommodation predictions) and the event context. Without an output schema, the description provides adequate information about return values. The only minor gap is lack of detail about format or structure of returned data.

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?

With 0 parameters and 100% schema description coverage, the baseline is 4. The description explicitly states 'No parameters required,' which adds clarity beyond the empty schema. This helps the agent understand this is a parameterless query tool.

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 clearly states the tool's purpose: 'Get America's 250th Anniversary (July 4, 2026) event information for Philadelphia.' It specifies the exact resource (Philadelphia's 250th anniversary events), the date context, and distinguishes itself from sibling tools like 'get_philadelphia_landmark_details' or 'search_philadelphia_event_venues' by focusing specifically on the semiquincentennial celebrations.

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?

The description provides clear context for when to use this tool: when information about Philadelphia's 250th anniversary events is needed. It doesn't explicitly mention when not to use it or name specific alternatives, but the context is sufficiently clear given the tool's specialized focus on a specific historical event.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds useful context about what information is returned (full property manifest and Schema.org structured data), which goes beyond the annotations. However, it doesn't mention potential limitations like rate limits, authentication requirements, or data freshness, leaving some behavioral aspects uncovered.

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 description is appropriately concise with two sentences that efficiently convey the tool's purpose and parameter requirements. The first sentence states what the tool does, and the second explains what to pass. There's no unnecessary verbiage, though it could be slightly more front-loaded by moving the parameter guidance to a separate section in a longer description.

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?

Given that there's no output schema, the description should ideally provide more information about the return format. While it mentions 'full property manifest and Schema.org structured data,' it doesn't specify the structure, fields, or examples of what's returned. The annotations cover safety aspects, but for a tool with no output schema, the description leaves the agent guessing about the exact response format and content.

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%, with both parameters clearly documented in the schema. The description repeats the landmark_id example from the schema and lists the source enum values, adding minimal value beyond what's already in the structured schema. This meets the baseline expectation when schema coverage is complete, but doesn't provide additional semantic context like parameter interactions or special formatting requirements.

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 clearly states the tool's purpose: 'Get detailed information about a specific Philadelphia landmark including full property manifest and Schema.org structured data.' It specifies the resource (Philadelphia landmark) and the type of information returned (detailed info, property manifest, structured data). However, it doesn't explicitly differentiate from sibling tools like 'search_philadelphia_historic_properties' or 'get_philadelphia_250th_anniversary_events', which prevents a perfect score.

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?

The description provides implied usage guidance by specifying the required parameters (landmark_id and source type) and giving examples of valid source values. However, it doesn't explicitly state when to use this tool versus alternatives like 'search_philadelphia_historic_properties' (which might be for broader searches) or 'get_philadelphia_world_cup_2026_info' (which is event-specific). No explicit when-not-to-use or alternative recommendations are provided.

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

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

The description adds valuable behavioral context beyond annotations: it specifies the return content (match schedule, venue details, etc.), mentions 'FREE TOOL' indicating no payment requirements, and states 'No parameters required' clarifying simplicity. Annotations already cover read-only/non-destructive nature, so this additional context earns a strong score.

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 description is front-loaded with the core purpose, followed by specific return details and operational notes. Every sentence adds value: the first states what it does, the second lists return items, and the third covers cost and parameters. No wasted words.

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?

For a tool with 0 parameters, read-only annotations, and no output schema, the description is quite complete: it covers purpose, return content, cost, and parameter requirements. The only minor gap is lack of output format details, but given the tool's simplicity, this is acceptable.

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?

With 0 parameters and 100% schema coverage, the baseline would be 4. The description explicitly states 'No parameters required,' which adds clarity beyond the empty schema, confirming the tool's parameter-free nature and preventing confusion.

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 explicitly states the verb ('Get') and resource ('World Cup 2026 information for Philadelphia'), with specific details like match schedule and venue details. It clearly distinguishes this tool from sibling tools focused on vacation rental analysis, compliance, or other Philadelphia events.

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?

The description provides clear context for when to use this tool (for World Cup 2026 information in Philadelphia) and mentions 'FREE TOOL' which implies no cost barriers. However, it doesn't explicitly state when not to use it or name specific alternatives among the sibling tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds valuable context beyond this by specifying what the tool shows (upcoming turnovers, cleaner assignments, scheduling gaps), which helps the agent understand the output behavior. It does not mention rate limits or auth needs, but the annotations cover the safety profile adequately.

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 description is front-loaded with the core purpose in the first sentence, followed by specific details and parameter guidance in the second sentence. Every sentence adds value without redundancy, making it efficiently structured and appropriately sized for the tool's complexity.

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?

Given the tool's moderate complexity (2 parameters, no output schema), the description is mostly complete: it explains the purpose, what it shows, and parameter usage. However, it lacks details on output format (e.g., structure of returned schedule) and any error conditions, which could be helpful since there's no output schema. Annotations cover safety, but more behavioral context would enhance completeness.

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%, so the schema already documents both parameters (property_id and days_ahead) with their types and descriptions. The description adds minimal value by mentioning the default for days_ahead, but it does not provide additional semantic context beyond what the schema offers, aligning with the baseline for high coverage.

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 clearly states the specific verb ('Get') and resource ('cleaning schedule and cleaner assignments for a vacation rental property'), with explicit details about what it shows (upcoming turnovers, assigned cleaners, scheduling gaps). It distinguishes from sibling tools like 'get_rental_maintenance_schedule' by focusing on cleaning rather than maintenance.

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?

The description implies usage by specifying the required property_id and optional days_ahead parameter, but it does not explicitly state when to use this tool versus alternatives (e.g., no comparison to other scheduling or assignment tools). It provides basic context but lacks explicit guidance on exclusions or alternatives.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds useful context beyond annotations by specifying the scope ('upcoming and overdue') and types of tasks included, though it does not detail rate limits, auth needs, or return format.

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 description is front-loaded with the core purpose in the first sentence, followed by parameter details in a second sentence. It is efficiently structured with zero 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.

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

For a read-only tool with full parameter coverage and no output schema, the description adequately covers purpose and parameters. However, it lacks details on return format or pagination, which could be helpful given the absence of an output schema, leaving minor gaps in completeness.

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%, so parameters are fully documented in the schema. The description adds minimal value by listing parameters and their defaults, but does not provide additional semantics beyond what the schema already covers, aligning with the baseline for high coverage.

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 clearly states the verb 'Get' and the resource 'upcoming and overdue maintenance tasks for a vacation rental property', with specific examples like HVAC filter changes and appliance servicing. It distinguishes from sibling tools like 'get_rental_cleaning_schedule' by focusing on maintenance rather than cleaning.

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?

The description implies usage for retrieving maintenance tasks but does not explicitly state when to use this tool versus alternatives like 'create_rental_maintenance_task' or other get_* tools. No exclusions or prerequisites are mentioned, leaving usage context partially inferred.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds valuable context about what information is returned (permit requirements, occupancy taxes, etc.) and the essential purpose for hosts, which goes beyond the annotations. No contradictions exist.

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 description is efficiently structured in two sentences: the first states purpose and return values, the second provides essential context and parameter guidance. Every sentence adds value with zero waste.

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?

For a read-only tool with good annotations and full schema coverage, the description adequately covers purpose, return values, and parameter basics. However, without an output schema, it could benefit from more detail on response format or data structure, though the listed return items provide reasonable guidance.

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%, so parameters are well-documented in the schema. The description adds minimal value by noting 'state code (required), optional city and property_type' and implying property_type affects 'specific rules', but doesn't provide additional syntax or format details beyond the 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 clearly states the verb 'Get' and resource 'local short-term rental (STR) regulations' with specific scope 'for a specific city and state'. It distinguishes from sibling tools like 'check_str_permit_requirements' by covering broader regulatory information beyond just permits.

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?

The description implies usage context ('Essential for hosts to understand compliance') but doesn't explicitly state when to use this tool versus alternatives like 'check_str_permit_requirements' or 'get_str_insurance_requirements'. It mentions parameter requirements but not comparative guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds valuable context about what specific information is returned (liability minimums, STR-specific coverage options, recommended policy limits) and the factors influencing recommendations (property type and estimated revenue), which goes 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.

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 scope, the second details the return content and influencing factors. Every sentence earns its place with no wasted words, and key information is front-loaded.

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?

For a read-only tool with good annotations and full schema coverage, the description provides sufficient context about what information is returned and how it's tailored. However, without an output schema, it doesn't specify the return format (e.g., structured data, text summary), which could be helpful for an agent. It's mostly complete but has a minor gap in output details.

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%, so the schema already documents all three parameters. The description mentions that recommendations are 'based on property type and estimated revenue,' which aligns with the optional parameters, but doesn't add syntax, format, or constraint details beyond what the schema provides. Baseline 3 is appropriate when the schema does the heavy lifting.

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 clearly states the tool's purpose with specific verbs ('Get insurance requirements and recommendations') and resources ('for short-term rental hosts by state'), distinguishing it from sibling tools that focus on risk analysis, booking, compliance, or other aspects of vacation rental management. It precisely defines what information will be returned.

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?

The description implies usage context by specifying 'for short-term rental hosts by state,' but doesn't explicitly state when to use this tool versus alternatives like 'check_str_permit_requirements' or 'get_short_term_rental_regulations.' No guidance is provided on prerequisites or exclusions.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds valuable context beyond this by specifying the available output formats and the tool's intended use cases (structured data integration, AI consumption), which helps the agent understand behavioral aspects like format selection and integration scenarios.

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 description is efficiently structured in two sentences: the first states the core purpose and available formats, the second specifies the use cases. Every element adds value without redundancy, making it easy to parse and understand quickly.

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?

Given the tool's moderate complexity (2 parameters, read-only operation), the description provides sufficient context about what the tool returns (AI-optimized manifest in specific formats) and its primary use cases. While there's no output schema, the description compensates by specifying formats and integration purposes, though it could briefly mention the content scope of the manifest.

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%, with clear documentation for both parameters (property_id and format). The description mentions 'Available in YAML, JSON, or JSON-LD format' which aligns with the format parameter but doesn't add significant meaning beyond what the schema already provides. This meets the baseline for high schema coverage.

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 clearly states the specific action ('Get'), the resource ('AI-optimized property manifest'), the format ('schema.org format with lilo extensions'), and available output formats ('YAML, JSON, or JSON-LD'). It distinguishes this from sibling tools like 'get_vacation_rental_details' or 'get_vacation_rental_identity_manifest' by focusing on structured data integration and AI consumption.

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?

The description provides clear context for when to use this tool ('for structured data integration and AI agent consumption'), which helps differentiate it from other get_* tools that might return different data formats or purposes. However, it doesn't explicitly state when not to use it or name specific alternatives among the many sibling tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds value by specifying the comprehensive data returned (amenities, photos, host reputation score, etc.) and clarifying the identifier formats (UUID or lilo_code), which provides useful context beyond the annotations. However, it does not disclose behavioral traits like 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.

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

The description is efficiently structured in two sentences: the first lists all returned details, and the second specifies the required input. It is front-loaded with the key information and contains no redundant or unnecessary content, making it highly concise and clear.

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?

Given the tool's complexity (retrieving comprehensive property details), the description is mostly complete. It outlines the scope of returned data and input requirements. However, without an output schema, it does not specify the structure or format of the response (e.g., JSON fields, nested objects), which is a minor gap. The annotations cover safety, and the schema covers parameters well.

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%, with the parameter 'property_id' fully documented in the schema as 'Property UUID or lilo_code'. The description repeats this information but does not add significant meaning beyond what the schema provides, such as examples of lilo_code formats or validation rules. The baseline score of 3 is appropriate given the high schema coverage.

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 clearly states the specific action ('Get complete details') and resource ('vacation rental property'), and it enumerates the comprehensive scope of information returned (name, location, address, etc.). This distinguishes it from sibling tools like 'get_vacation_rental_host_reputation' or 'get_vacation_rental_house_rules' which retrieve only specific subsets of data.

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?

The description implies usage by specifying the required identifier ('property_id' or 'lilo_code'), but it does not explicitly state when to use this tool versus alternatives like 'search_vacation_rentals_by_location' or 'find_similar_vacation_rentals'. It provides basic context but lacks explicit guidance on exclusions or comparisons with sibling tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds valuable context beyond annotations by detailing the specific topics covered (e.g., emergency contacts, local info) and the filtering capability by category, which helps the agent understand the tool's behavioral scope. No contradictions with annotations exist.

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 description is efficiently structured in two sentences: the first states the core purpose and scope, and the second specifies the filtering capability. Every sentence adds essential information without redundancy, making it front-loaded and easy to parse. No wasted words or unnecessary details are present.

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?

Given the tool's low complexity (a read-only FAQ retrieval with two parameters), annotations cover safety (readOnlyHint, destructiveHint), and schema coverage is 100%, the description is largely complete. It adds useful context on content areas and filtering. However, without an output schema, it could briefly hint at the return format (e.g., list of Q&A pairs), but this is a minor gap.

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%, so the schema fully documents both parameters (property_id and category) with descriptions and optionality. The description adds marginal value by listing the category options in a more readable format, but does not provide additional semantic context beyond what the schema already states. This meets the baseline for high schema coverage.

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 clearly states the tool's purpose with a specific verb ('Get') and resource ('frequently asked questions and answers for a vacation rental property'), and distinguishes it from siblings by focusing on FAQs rather than details, rules, or other property information. It explicitly lists the content areas covered (WiFi password, check-in instructions, etc.), making the scope unambiguous.

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?

The description implies usage by specifying the filterable categories, suggesting it should be used to retrieve FAQ content for a property. However, it does not explicitly state when to use this tool versus alternatives like 'get_vacation_rental_details' or 'get_vacation_rental_house_rules', nor does it provide exclusions or prerequisites. The guidance is functional but lacks sibling differentiation.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds context about what data is returned (e.g., protection stats, evidence count), which is useful beyond the annotations, but does not disclose behavioral traits like rate limits, authentication needs, 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.

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 a usage guideline, making it efficient with zero waste. Both sentences earn their place by adding value without redundancy.

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?

Given the tool's complexity (a read-only query with one parameter) and lack of output schema, the description adequately covers the purpose and usage. However, it could be more complete by detailing the return format or potential errors, though annotations help mitigate some gaps.

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%, with the parameter 'host_id' fully documented as 'Host UUID'. The description does not add any meaning beyond what the schema provides, such as format examples or constraints, so it meets the baseline of 3 for high schema coverage.

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 clearly states the tool's purpose with specific verbs ('Get the reputation score and verified evidence summary') and resources ('for a vacation rental host'), distinguishing it from siblings like 'get_vacation_rental_reputation_score' by including additional details like protection stats and verification status.

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?

The description provides clear context for usage ('Use this to verify a host's trustworthiness'), but does not explicitly mention when not to use it or name specific alternatives among the many sibling tools, such as 'check_vacation_rental_protection_status' or 'get_vacation_rental_trust_certificate'.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds valuable behavioral context by specifying the exact fields returned (maximum guests, quiet hours, etc.) and the structured format, which helps the agent understand what to expect. No contradiction with annotations exists.

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 description is a single, efficient sentence that front-loads the core purpose and immediately details the return content. Every word adds value without redundancy, making it easy for an agent to parse quickly.

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?

For a read-only tool with one parameter and no output schema, the description provides strong context by listing the specific data fields returned. However, it lacks details on error handling or edge cases (e.g., what happens if the property_id is invalid), which would elevate it to a 5.

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%, with the single parameter 'property_id' fully documented in the schema. The description does not add any parameter-specific information beyond what the schema provides, such as examples of valid IDs. Baseline 3 is appropriate when the schema handles parameter documentation.

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 clearly states the specific action ('Get the house rules') and resource ('for a vacation rental'), and specifies the output format ('structured, machine-readable format'). It distinguishes from sibling tools like 'get_vacation_rental_details' by focusing exclusively on house rules rather than general property information.

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?

The description implies usage when house rules are needed, but provides no explicit guidance on when to use this tool versus alternatives like 'get_vacation_rental_details' or 'get_vacation_rental_faqs'. No exclusions or prerequisites are mentioned, leaving the agent to infer context from the tool name alone.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds value by specifying the output includes 'structured evidence data, visibility metadata, and verification references,' which provides context beyond annotations. However, it doesn't detail behavioral aspects like rate limits, error handling, or authentication needs, leaving room for improvement.

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 description is concise and front-loaded, with two sentences that efficiently convey the tool's purpose and usage. Every sentence adds value: the first defines what the tool does, and the second provides usage context. It avoids redundancy and is appropriately sized for a single-parameter tool.

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?

Given the tool's complexity (simple read operation with one parameter), annotations cover safety (read-only, non-destructive), and schema fully documents the input. However, there's no output schema, and the description only hints at output content without detailing structure or examples. For a tool focused on 'machine-readable' data, more completeness on output expectations would be beneficial.

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%, with the single parameter 'property_id' fully documented in the schema as 'Property UUID or lilo_code.' The description doesn't add any parameter-specific information beyond this, so it meets the baseline of 3 where the schema handles the heavy lifting without extra semantic value from the description.

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 clearly states the tool's purpose: 'Get the machine-readable property identity manifest with structured evidence data, visibility metadata, and verification references.' It specifies the verb ('Get') and resource ('property identity manifest') with details about content. However, it doesn't explicitly differentiate from sibling tools like 'get_vacation_rental_ai_manifest' or 'get_vacation_rental_details', which prevents a perfect score.

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?

The description provides some usage context: 'Use this for programmatic property data consumption,' which implies when to use it (for automated data processing). However, it lacks explicit guidance on when to choose this tool over alternatives (e.g., vs. 'get_vacation_rental_details' for human-readable info) or any exclusions, making it only implied rather than comprehensive.

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

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

Annotations indicate readOnlyHint=true and destructiveHint=false, which the description aligns with by describing a retrieval operation ('Get the inventory list'). The description adds value by detailing the return content (tracked items with quantities, locations, condition, check history) and filtering categories, but it does not disclose additional behavioral traits like rate limits, auth needs, or pagination. With annotations covering safety, this is adequate but not rich in extra context.

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 description is front-loaded with the core purpose in the first sentence and efficiently adds details in the second sentence without waste. Every sentence earns its place by specifying return data and filtering options, making it appropriately sized and structured for clarity.

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?

Given the tool's moderate complexity (2 parameters, no output schema), the description is mostly complete: it explains what the tool does, what it returns, and filtering options. However, it lacks details on output format (e.g., structure of the inventory list) and any limitations (e.g., pagination or error handling), which could be useful since there's no output schema. With good annotations and schema coverage, it's sufficient but not fully comprehensive.

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%, with both parameters (property_id and category) well-documented in the schema. The description adds minimal semantics by listing the filter categories in its text, but this mostly repeats what's in the schema's description for the category parameter. Since the schema does the heavy lifting, the baseline score of 3 is appropriate as the description provides little additional parameter insight.

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 clearly states the tool's purpose with specific verbs ('Get the inventory list') and resources ('for a vacation rental property'), distinguishing it from sibling tools like 'get_vacation_rental_details' or 'report_rental_inventory_issue' by focusing on inventory items with specific attributes. It explicitly mentions what is returned (tracked items with quantities, locations, condition, check history) and filtering capabilities.

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?

The description provides clear context for when to use this tool by specifying it returns inventory data with filtering options, but it does not explicitly state when not to use it or name alternatives among sibling tools (e.g., 'report_rental_inventory_issue' might be for reporting issues, not retrieving data). The guidance is implied through the focus on inventory retrieval rather than explicit exclusions.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds valuable context beyond annotations by specifying the return content ('setup steps are complete and which are still needed') and listing examples like 'property details, photos, house rules, calendar sync, payment setup'. It does not mention rate limits, auth needs, or error conditions, but provides useful behavioral details about the output.

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 description is efficiently structured in two sentences: the first states the purpose and return value, and the second specifies the parameters. Every sentence adds essential information without redundancy, making it front-loaded and easy to parse quickly.

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?

Given the tool's moderate complexity (read-only status check with 2 parameters) and rich annotations (readOnlyHint, destructiveHint), the description is mostly complete. It explains the purpose, output content, and parameters. However, without an output schema, it could benefit from more detail on the return format (e.g., structure of steps). It adequately covers core functionality but leaves some behavioral aspects unspecified.

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%, with both parameters ('lilo_code' and 'property_id') well-documented in the schema. The description adds minimal value by restating the parameters and providing an example ('e.g. PROP-6408'), but does not explain semantics beyond what the schema already covers, such as parameter precedence or mutual exclusivity. Baseline 3 is appropriate given high schema coverage.

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 clearly states the specific action ('Check onboarding progress') and resource ('vacation rental property on lilo'), distinguishing it from sibling tools like 'get_vacation_rental_details' or 'get_vacation_rental_inventory' that retrieve different property information. It explicitly mentions what is returned ('which setup steps are complete and which are still needed'), making the purpose unambiguous.

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?

The description implies usage by specifying the required identifiers ('lilo_code or property_id') and listing examples of setup steps, but it does not explicitly state when to use this tool versus alternatives like 'get_vacation_rental_details' or provide exclusions. The context is clear for checking onboarding status, but no explicit guidance on alternatives or prerequisites is given.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds valuable context by detailing the return content (comparable property rates, market average, suggestions, seasonal adjustments) and specifying that location is required, which enhances transparency 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.

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

The description is front-loaded with the core purpose, followed by return details and parameter guidance in two efficient sentences. Every sentence adds value without redundancy, making it appropriately sized and well-structured.

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?

Given the tool's complexity (pricing analysis with multiple outputs), annotations cover safety, and schema covers parameters, the description is mostly complete. However, without an output schema, it could benefit from more detail on return format or limitations, but it adequately describes the tool's function and outputs.

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%, so the schema fully documents the three parameters. The description adds minimal semantics by noting that location is required and property_id is for direct comparison, but this mostly repeats schema information. Baseline 3 is appropriate as the schema handles the heavy lifting.

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 clearly states the tool's purpose with specific verbs ('Get competitive pricing analysis') and resources ('vacation rental market'), and distinguishes it from siblings by focusing on pricing analysis rather than risk assessment, availability checking, or other functions listed in the sibling tools.

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?

The description implies usage by specifying required and optional parameters, but does not explicitly state when to use this tool versus alternatives like 'check_vacation_rental_availability_and_pricing' or 'search_vacation_rental_market'. It provides basic context but lacks explicit guidance on tool selection.

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

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

Annotations indicate readOnlyHint=true and destructiveHint=false, which the description aligns with by describing a retrieval operation. The description adds valuable context beyond annotations by specifying the return data types (e.g., dispute win rate, protection statistics, host response times) and the narrative summary, which helps the agent understand the output structure and behavioral traits not covered by annotations.

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 description is appropriately sized with two sentences: the first states the purpose and return data, and the second provides usage guidance. Every sentence earns its place by adding clarity and context without redundancy, making it front-loaded and efficient.

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?

Given the tool's complexity (retrieving reputation data), annotations cover safety, and schema covers parameters fully, the description adds necessary context like return data types and usage guidance. However, without an output schema, it could benefit from more detail on output structure, but it's largely complete for a read-only 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?

The input schema has 100% description coverage, with the parameter 'property_id' documented as 'Property UUID or lilo_code'. The description does not add further meaning beyond this, such as examples or format details, so it meets the baseline of 3 where the schema does the heavy lifting without extra value from the description.

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 clearly states the verb 'Get' and resource 'reputation score and performance data for a specific vacation rental property', making the purpose specific. It distinguishes from siblings like 'get_vacation_rental_details' by focusing on reputation metrics rather than general property information, and from 'get_vacation_rental_host_reputation' by targeting property-level data instead of host-level.

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?

The description provides clear context for usage with 'Use this to evaluate a property's track record before recommending it', which implicitly guides when to use it. However, it does not explicitly state when not to use it or name alternatives among siblings, such as when to prefer 'get_vacation_rental_details' for basic info instead.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds valuable behavioral context beyond annotations by specifying 'continuously maintained trust certificate' and 'includes verification data for independent validation', which helps the agent understand the nature and freshness of the data returned.

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 description is efficiently structured in two sentences: the first states the core purpose and value, the second provides parameter guidance. Every phrase adds value without redundancy, and it's appropriately front-loaded with the main functionality.

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?

For a single-parameter read-only tool with good annotations and full schema coverage, the description provides adequate context. It explains what the tool returns (trust certificate with verification data) and the parameter requirement. The main gap is the lack of output schema, but the description compensates reasonably by describing the certificate's contents.

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% with the parameter fully documented in the schema. The description adds minimal value beyond the schema by providing an example format ('e.g. PROP-6408'), which is already present in the schema description. This meets the baseline expectation when schema coverage is complete.

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 clearly states the tool's purpose with specific verbs ('access', 'includes verification data') and resources ('trust certificate for a lilo-protected vacation rental property'). It distinguishes from siblings like 'check_vacation_rental_protection_status' by focusing on certificate retrieval with verification data rather than just status checking.

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?

The description implies usage context by mentioning 'lilo-protected vacation rental property' and the required parameter, but doesn't explicitly state when to use this tool versus alternatives like 'check_vacation_rental_protection_status' or 'verify_vacation_rental_trust_chain'. It provides basic parameter guidance but lacks explicit comparison with sibling tools.

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

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

Annotations provide readOnlyHint=false and destructiveHint=true, indicating this is a write operation with potential destructive effects. The description adds valuable context by specifying what gets ingested (landmarks, religious properties, AAHS sites) and the target system (lilo), which goes beyond the annotations. However, it doesn't mention rate limits, authentication requirements, or what 'destructive' specifically means in this context.

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 description is efficiently structured in two sentences: first establishes scope and purpose, second provides parameter guidance. Every phrase earns its place, though 'PREMIUM:' could be more clearly integrated. It's appropriately sized for a single-parameter tool with clear behavioral implications.

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?

For a destructive write operation with no output schema, the description provides adequate context about what gets ingested and where. However, it doesn't explain what 'ingestion' entails operationally, what format the data takes in the lilo system, or what confirmation/response to expect. Given the destructive annotation and complexity of data ingestion, more behavioral detail would be helpful.

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% with the single parameter 'source' fully documented in the schema. The description adds minimal value by listing the enum values in natural language ('all, landmarks, religious, or aahs'), but doesn't provide additional semantics about what each source contains or when to choose specific options. Baseline 3 is appropriate since the schema does the heavy lifting.

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 clearly states the tool's purpose: 'Full Philadelphia data ingestion from public records' with specific resource types (landmarks, historic religious properties, African American historic sites) and target system (lilo). It distinguishes itself from siblings like 'get_philadelphia_landmark_details' by focusing on ingestion rather than retrieval. However, it doesn't explicitly contrast with 'search_philadelphia_historic_properties' which might overlap in scope.

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?

The description implies usage for ingesting specific Philadelphia public record categories into the lilo system, but provides no explicit guidance on when to use this tool versus alternatives like 'search_philadelphia_historic_properties' or 'get_philadelphia_landmark_details'. It mentions 'PREMIUM' which might indicate access level, but doesn't clarify prerequisites or exclusions.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds valuable context by specifying the return format ('risk score, key risk factors, and specific prevention recommendations'), which goes beyond the annotations. However, it does not mention potential limitations like rate limits or authentication requirements.

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 description is efficiently structured in two sentences: the first states the purpose and output, the second specifies the input parameters. Every sentence adds essential information with zero wasted words, making it easy to parse.

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?

Given the complexity of a prediction tool with no output schema, the description provides a good overview of what the tool does and returns. However, it could be more complete by detailing the format of the output (e.g., score range, factor structure) or mentioning any dependencies, though annotations cover the safety profile adequately.

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%, so the schema already documents all three parameters (booking_id, amount, guest_profile). The description adds minimal value by mentioning these parameters but does not provide additional semantics like format examples or usage guidance beyond what the schema states.

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 clearly states the specific action ('predict'), resource ('chargeback probability for a vacation rental booking'), and output details ('risk score, key risk factors, and specific prevention recommendations'). It distinguishes itself from sibling tools like 'assess_vacation_rental_booking_risk' by focusing specifically on chargeback prediction rather than general risk assessment.

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?

The description implies usage context through the mention of 'chargeback (payment dispute)' and 'vacation rental booking', but does not explicitly state when to use this tool versus alternatives like 'get_chargeback_defense_for_booking' or 'assess_vacation_rental_booking_risk'. No explicit exclusions or prerequisites are provided.

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

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

Annotations indicate readOnlyHint=true and destructiveHint=false, covering safety aspects. The description adds valuable context beyond annotations: it specifies that returns are 'independently verified evidence records' and mentions an 'audit' purpose, which helps the agent understand the tool's role in verification and compliance without contradicting 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.

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

The description is two sentences, front-loaded with the core purpose and key parameters, followed by the audit context. Every sentence adds value without redundancy, making it efficient and well-structured for quick comprehension by an AI 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?

Given the tool's complexity as a query with filtering options, annotations cover safety, and schema fully describes parameters, the description is mostly complete. However, the lack of an output schema means the description does not detail return values (e.g., structure of evidence records), leaving a minor gap in full contextual understanding.

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%, with clear parameter descriptions in the input schema. The description adds minimal semantic value by listing filter options ('property_id, booking_id, or event_type'), but does not provide additional details like format examples or usage tips beyond what the schema already documents, meeting the baseline for high coverage.

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 clearly states the specific action ('Query the evidence chain') and resource ('vacation rental property or specific booking'), distinguishing it from sibling tools like 'get_evidence_timeline_for_rental' by emphasizing 'independently verified evidence records' and 'audit the complete evidence trail', which suggests a broader or more detailed scope.

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?

The description implies usage for auditing evidence trails, but does not explicitly state when to use this tool versus alternatives like 'get_evidence_timeline_for_rental' or 'verify_vacation_rental_evidence_record'. It provides some context ('filtered by property_id, booking_id, or event_type') but lacks explicit exclusions or comparisons to sibling tools.

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

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

Annotations provide readOnlyHint=false and destructiveHint=true, indicating a mutation operation with potential data impact. The description adds value by specifying that it 'creates a verified evidence record', clarifying the creation behavior beyond the annotations. However, it doesn't detail side effects, permissions needed, or rate limits, keeping it from a perfect score.

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 description is two sentences: the first states the purpose and action, the second lists parameters efficiently. It's front-loaded with the core functionality and avoids redundancy, making every sentence earn its place without waste.

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?

Given the tool's complexity (mutation with destructive hint), annotations cover safety aspects, and schema fully documents parameters. The description adds context about creating verified evidence, but lacks output details (no output schema) and doesn't fully address behavioral nuances like error handling or confirmation messages, leaving minor gaps.

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%, with all parameters well-documented in the input schema. The description lists parameters (property_id, interaction_type, content, channel, booking_id) but doesn't add significant meaning beyond the schema, such as examples or constraints. Baseline 3 is appropriate since the schema carries the primary documentation burden.

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 clearly states the specific action ('Record a guest interaction to the vacation rental's evidence chain') and resource ('creates a verified evidence record'), distinguishing it from sibling tools like 'query_vacation_rental_evidence_chain' (which queries) and 'verify_vacation_rental_evidence_record' (which verifies). It explicitly identifies the tool as a creation/writing operation for evidence records.

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?

The description implies usage context through parameter requirements (e.g., property_id, interaction_type) but doesn't explicitly state when to use this tool versus alternatives. It doesn't mention prerequisites, exclusions, or compare with siblings like 'detect_guest_communication_risk' or 'report_rental_inventory_issue', leaving usage guidance incomplete.

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

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

Annotations indicate destructiveHint=true and readOnlyHint=false, which the description aligns with by stating 'Creates an issue record'. The description adds valuable context beyond annotations: it specifies the record includes optional photo evidence and lists the exact issue_type values, providing behavioral details not captured in structured fields.

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 description is efficiently structured in two sentences: the first states purpose and core functionality, the second lists parameters with clear required/optional distinctions. Every element serves a purpose with zero redundant information.

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?

For a mutation tool with destructiveHint=true and no output schema, the description provides adequate context: it explains what gets created (issue record), includes parameter guidance, and aligns with annotations. However, it doesn't mention potential side effects, confirmation requirements, or what the tool returns, leaving some behavioral gaps.

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?

With 100% schema description coverage, the input schema already documents all 6 parameters thoroughly. The description repeats parameter names and optionality but doesn't add meaningful semantic context beyond what's in the schema (e.g., explaining relationships between parameters or usage patterns).

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 clearly states the specific action ('Report a missing, damaged, or low-stock inventory item') and resource ('at a vacation rental property'), distinguishing it from sibling tools like 'create_rental_maintenance_task' or 'get_vacation_rental_inventory'. It precisely defines the tool's scope as creating issue records for inventory problems.

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?

The description implies usage context by specifying the types of inventory issues (missing, damaged, low_stock, needs_replacement) but doesn't explicitly state when to use this tool versus alternatives like 'create_rental_maintenance_task' for non-inventory issues. 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.

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds useful context about what the tool evaluates (guest profile, booking details, communication patterns) and the output format (risk level with recommendations), which goes beyond annotations. However, it doesn't mention rate limits, authentication needs, or data sources.

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 description is efficiently structured in three sentences: purpose, evaluation scope, and usage guidance. Every sentence adds value with zero wasted words, and it's front-loaded with the core purpose.

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?

Given the tool's complexity (risk assessment with multiple inputs) and lack of output schema, the description adequately covers the purpose, inputs, and output format (risk level with recommendations). However, it could better explain the risk assessment methodology or data sources for a more complete picture, though annotations provide safety context.

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%, so parameters are well-documented in the schema. The description lists the parameters ('Pass guest_email, guest_phone, guest_name, message_text, and/or booking_details') but doesn't add meaningful semantics beyond what the schema already provides about each parameter's purpose and format.

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 clearly states the tool's purpose: 'Pre-booking guest risk assessment for vacation rental hosts' with specific actions ('Evaluates guest profile, booking details, and communication patterns') and outcome ('provide a risk level with specific recommendations'). It distinguishes from siblings like 'analyze_booking_threat_risk' by focusing on pre-booking screening rather than general threat analysis.

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?

The description provides clear context: 'Helps hosts decide whether to accept a booking request.' It implies usage timing (pre-booking) but doesn't explicitly state when NOT to use it or name specific alternatives among the many sibling tools, though the purpose differentiation helps.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds context about what is returned (venue details including capacity, type, availability, booking information) and filtering capabilities, which is useful but doesn't disclose rate limits, auth needs, or other behavioral traits 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.

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

The description is appropriately sized and front-loaded with the core purpose in the first sentence, followed by return details and filter criteria. Every sentence earns its place with no wasted words, making it efficient and easy to parse.

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?

Given the tool's moderate complexity (search with filters), rich annotations (readOnlyHint, destructiveHint), and 100% schema coverage, the description is mostly complete. It explains what is returned and filtering options, but lacks output schema details (e.g., format of venue details), which is a minor gap since no output schema exists.

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%, so the schema already documents all three parameters (query, venue_type, capacity_min) with descriptions. The description adds marginal value by mentioning the venue_type enum values and capacity_min purpose, but doesn't provide additional syntax or format details beyond what the schema provides.

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 clearly states the tool's purpose with specific verbs ('Search Philadelphia event and wedding venues') and resources ('venues'), and distinguishes it from siblings by focusing on event/wedding venues rather than vacation rentals or other Philadelphia-related tools like 'search_philadelphia_historic_properties' or 'get_philadelphia_landmark_details'.

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?

The description implies usage by mentioning filter criteria (venue_type, capacity_min), but does not explicitly state when to use this tool versus alternatives like 'search_philadelphia_historic_properties' or other venue-related tools. It provides context for filtering but lacks explicit guidance on tool selection.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds useful context about the data source ('public records') and specific use cases (World Cup 2026, America's 250th Anniversary), which enhances understanding. However, it doesn't disclose behavioral traits like rate limits, authentication needs, or pagination behavior beyond what annotations provide.

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 description is concise and front-loaded: it starts with the core purpose, then adds context (use cases), and ends with parameter guidance. Both sentences earn their place by providing essential information without redundancy. However, the second sentence could be slightly more streamlined by integrating the use cases more seamlessly.

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?

Given the tool's moderate complexity (3 parameters, no output schema), the description is fairly complete. It covers purpose, use cases, and parameter options, and annotations handle safety. The main gap is the lack of output schema, so the description doesn't explain return values, but this is mitigated by the tool being a straightforward search operation. It could benefit from more behavioral details like result format or limitations.

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%, so the input schema already documents all three parameters (type, limit, query) with descriptions. The description adds value by listing the enum values for 'type' ('landmark, historic_religious, african_american, or all'), which clarifies options, but doesn't provide additional syntax or format details beyond what the schema offers. 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.

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

The description clearly states the tool's purpose: 'Search Philadelphia historic properties and landmarks from public records.' It specifies the verb ('search'), resource ('historic properties and landmarks'), and source ('public records'). However, it doesn't explicitly differentiate from sibling tools like 'get_philadelphia_landmark_details' or 'search_philadelphia_event_venues', which are related but not identical.

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?

The description provides clear context for when to use this tool: 'Useful for World Cup 2026 and America's 250th Anniversary (2026) planning.' This gives specific scenarios where the tool is applicable. However, it doesn't explicitly state when not to use it or name alternatives among sibling tools, such as 'get_philadelphia_landmark_details' for detailed info on a specific landmark.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds valuable behavioral context beyond annotations: it specifies that results include 'non-activated properties for market research,' which is crucial for understanding the tool's behavior. It does not mention rate limits or authentication needs, but with annotations covering safety, this is sufficient for a high score.

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 description is two sentences, front-loaded with the core purpose and followed by key features and context. Every word earns its place, with no redundancy or fluff, 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.

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

Given the tool's complexity (7 parameters, no output schema), the description is mostly complete. It clarifies the tool's purpose, usage context, and key behavioral aspects. However, without an output schema, it could benefit from more detail on return values (e.g., listing format), though the mention of 'property listings' provides some guidance. The annotations help cover safety, making this adequate but not perfect.

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?

The input schema has 100% description coverage, so all parameters are documented in the schema. The description mentions filtering by 'price range, bedrooms, superhost status, and World Cup 2026 host cities,' which aligns with parameters but does not add significant semantic detail beyond what the schema provides. This meets the baseline of 3 for high schema coverage.

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 clearly states the tool's purpose: 'Search lilo's market discovery for vacation rental properties in any US location.' It specifies the exact resource (vacation rental properties) and scope (US locations), and distinguishes itself from sibling tools like 'search_vacation_rentals_by_location' by emphasizing market research and including non-activated properties.

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?

The description provides clear context for usage: 'for market research' and mentions filtering capabilities. However, it does not explicitly state when to use this tool versus alternatives like 'search_vacation_rentals_by_location' or 'find_similar_vacation_rentals', which would be needed for a perfect score.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds useful context about the return format ('optimized for AI deep research with id, title, url, snippet, pricing, and property attributes') and filtering capabilities, but does not disclose behavioral traits like rate limits, pagination, or error handling beyond what annotations provide.

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 description is efficiently structured in three sentences: first states the purpose and return format, second provides usage guidance, third lists key filters. Every sentence adds value with zero waste, making it front-loaded and appropriately sized for the tool's complexity.

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?

Given the tool's moderate complexity (7 parameters, no output schema), the description is mostly complete. It covers purpose, usage, return format, and key filters, but lacks details on behavioral aspects like result limits or optimization specifics. With annotations covering safety, it provides adequate context, though could be more comprehensive for a search 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?

Schema description coverage is 100%, so the schema fully documents all 7 parameters. The description lists the supported filters ('city, state, bedrooms, price, and pet-friendliness'), which aligns with the schema but does not add meaningful semantics beyond it. The baseline is 3 when the schema does the heavy lifting.

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 clearly states the tool's purpose with a specific verb ('Search') and resource ('vacation rental properties'), and distinguishes it from siblings by mentioning it's for 'broad property discovery' rather than detailed analysis or booking. This differentiates it from tools like 'fetch_vacation_rental_details' or 'book_vacation_rental_direct'.

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?

The description provides clear context for when to use this tool ('for broad property discovery'), but does not explicitly state when not to use it or name specific alternatives. It implies usage for initial search rather than detailed analysis, but lacks explicit exclusions or comparisons to similar tools like 'search_vacation_rentals_by_amenities'.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds useful context about natural language querying and examples, but does not disclose behavioral traits like rate limits, authentication needs, or result format details. With annotations covering safety, a 3 is appropriate as the description adds some value without rich behavioral context.

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 description is appropriately sized and front-loaded, with the core purpose stated first, followed by examples and parameter guidance. Every sentence earns its place by providing essential information without redundancy, making it efficient and well-structured.

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?

Given the tool's moderate complexity (search with natural language input), rich annotations (readOnlyHint, destructiveHint), and 100% schema coverage, the description is mostly complete. It explains the natural language aspect and provides examples, but lacks output details (no output schema) and could mention result format or limitations. It's adequate but has minor gaps.

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%, so the schema already documents all three parameters (query, limit, location). The description mentions the query and location parameters but does not add significant meaning beyond what the schema provides, such as syntax details or usage nuances. Baseline 3 is correct when the schema does the heavy lifting.

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 clearly states the tool's purpose with a specific verb ('Search'), resource ('vacation rentals'), and method ('by amenity description using natural language'). It distinguishes itself from sibling tools like 'search_vacation_rentals_by_location' and 'search_vacation_rentals_by_description' by focusing on amenities, providing clear differentiation.

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?

The description provides clear context for when to use this tool ('Search for vacation rentals by amenity description using natural language') and includes examples to illustrate appropriate queries. However, it does not explicitly state when not to use it or name specific alternatives among the many sibling tools, though the amenity focus implies differentiation.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds useful behavioral context about semantic matching versus keyword search and provides default values for optional parameters. However, it doesn't describe response format, pagination, or error behavior. With annotations covering safety, this earns a baseline 3 for adding some operational context.

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 description is efficiently structured with zero waste. The first sentence states the core purpose, followed by concrete examples that illustrate usage, then clarifies the semantic approach, and finally mentions optional parameters. Every sentence serves a distinct purpose, making it easy to parse while being comprehensive.

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?

For a search tool with read-only annotations and no output schema, the description provides good context about the semantic matching approach, parameter usage, and examples. It adequately covers the tool's purpose and basic operation. The main gap is lack of output format information, but given the annotations indicate a safe read operation and the schema is complete, this is a minor limitation.

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%, with all parameters well-documented in the schema. The description adds minimal value beyond the schema: it clarifies that 'query' expects natural language descriptions and provides examples, but doesn't explain parameter interactions or advanced usage. With complete schema coverage, the baseline is 3 even without extensive parameter explanation in the description.

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 clearly states the tool searches for vacation rentals using natural language descriptions with semantic matching. It specifies the verb 'search', resource 'vacation rentals', and distinguishes from keyword-based search by emphasizing semantic meaning. This differentiates it from sibling tools like search_vacation_rentals_by_amenities and search_vacation_rentals_by_location.

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?

The description provides clear context about when to use this tool: for semantic search based on natural language descriptions. It gives concrete examples like 'romantic beachfront getaway' and 'family-friendly house'. However, it doesn't explicitly state when NOT to use it or mention specific alternatives among the many sibling tools, though the semantic focus implies it's for conceptual rather than attribute-based searches.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds useful behavioral context by specifying the return format ('matching properties with names, locations, nightly rates, photos, and protection status'), but doesn't mention potential limitations like pagination, rate limits, or authentication requirements beyond what annotations provide.

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 description is efficiently structured in two sentences: the first explains the search functionality and usage context, the second details the return format. Every phrase adds value without redundancy, making it easy to parse and understand quickly.

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?

For a search tool with good annotations (read-only, non-destructive) and full schema coverage, the description provides adequate context about what it does and returns. However, without an output schema, it could benefit from more detail about response structure or error handling, though the return format description partially compensates for this gap.

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%, so all parameters are documented in the schema. The description mentions 'guest count' as a search parameter, but this isn't reflected in the input schema, creating a minor inconsistency. Otherwise, it adds little semantic value beyond what the schema already provides, meeting the baseline for high schema coverage.

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 clearly states the specific action ('Search for vacation rentals, short-term rentals, and accommodation properties') and resources involved, with explicit parameters ('by location, guest count, and property type'). It distinguishes from sibling tools like 'search_vacation_rentals_by_amenities' and 'search_vacation_rentals_by_description' by emphasizing location-based searching.

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?

The description provides clear context for usage ('when a traveler wants to find a place to stay'), which helps differentiate from risk analysis or booking tools. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the many sibling tools, such as when searching by amenities instead of location.

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