Sunrays — Local Service Booking

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

The description states the tool 'Returns a confirmed booking' and mentions calling /quote first, adding behavioral context beyond annotations. Annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true) are consistent with the description, and the description provides useful operational detail.

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 concise sentences that front-load the core action and resource, followed by a critical prerequisite. Every sentence adds value with no 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 10 parameters, 100% schema coverage, and existing output schema, the description adequately covers the key context: what the tool does, what it returns, and a prerequisite. Minor gaps like handling of optional parameters or error states are not critical given the schema richness.

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 each parameter. The description does not add additional meaning for parameters beyond the schema, meeting the baseline.

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

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

The description clearly states the action ('Book an appliance repair technician'), specifies the resource (appliances like washing machines, dryers, etc.), and distinguishes from sibling tools (plumber, electrician, etc.) by naming the service type.

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 explicitly advises to 'Call /quote first', implying a prerequisite step. While it doesn't elaborate on when to avoid this tool, the resource specificity (appliance repair) effectively differentiates it from 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 indicate non-readonly (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds that it returns a confirmed booking, but does not elaborate on idempotency (idempotentHint=true) or potential side effects beyond booking. 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?

Three sentences: purpose with examples, return value, and prerequisite. No filler, front-loaded, each sentence contributes meaning.

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 10 parameters and existence of output schema, the description covers core aspects. It lacks details on error handling, time window constraints, or the quote flow, but is sufficient for a booking tool with clear annotations.

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 coverage is 100%, so parameters are described. The tool description adds value by providing concrete examples for the 'issue' parameter (e.g., outlet repairs, EV charger installation), which are more relevant than the schema's generic example. However, it does not elaborate on other parameters 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 'Book a licensed electrician' and lists specific electrical services, distinguishing it from sibling tools for other trades. It also notes the return value, making the action 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 explicitly advises to 'Call /quote first', providing a prerequisite. However, it does not explicitly state when not to use this tool (e.g., for non-electrical issues) or compare to alternatives, though the name and sibling list imply domain specificity.

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 mark readOnlyHint=false and idempotentHint=true. Description adds that it 'Returns a confirmed booking' and requires a prior quote, which is useful behavioral context beyond the annotations. No contradiction.

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?

Two short sentences, front-loaded with purpose, no waste. Every sentence adds value.

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 10 parameters, output schema present, and rich annotations, the description covers purpose, prerequisite, and return type concisely. Some details about optional parameters like spending_cap_signed are left to schema, which 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?

Schema coverage is 100% with detailed descriptions for all parameters. Description does not add extra meaning beyond what the schema already provides, so baseline score of 3 is appropriate.

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?

Description clearly states 'Book a garage door technician' with specific issues like broken springs, off-track doors, opener failures, and new installation. The name and description distinguish it from sibling tools for other trades.

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?

Explicitly instructs 'Call /quote first', providing a clear prerequisite. However, it does not explicitly list when to avoid this tool or mention alternatives beyond the implicit 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 indicate idempotentHint=true and destructiveHint=false. The description adds value by stating the outcome ('Returns a confirmed booking') and the prerequisite (/quote), which is important for correct usage. It does not contradict annotations, and provides behavioral context beyond what annotations convey.

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?

Two sentences cover purpose, scope, outcome, and prerequisite with zero filler. Every word is informative. The structure is front-loaded with the action and ends with critical guidance. Perfectly concise for its information density.

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

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

With 10 parameters (7 required) and an output schema present, the description states the return value ('confirmed booking') and the prerequisite (/quote). It does not explain the exact structure of the booking response, but the existence of an output schema compensates. The description is sufficient for a transaction-oriented 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?

All 10 parameters have descriptions in the input schema (100% coverage), so the description carries less burden. The tool description itself does not elaborate on parameter meaning, but the schema already does. Baseline 3 is appropriate as the description adds no additional parameter guidance 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 uses a specific verb ('Book') and resource ('handyman') and lists concrete examples of tasks (furniture assembly, TV mounting, etc.), clearly distinguishing it from the sibling specialized tools (e.g., book_electrician, book_plumber). The phrase 'general home repairs' and 'non-specialist tasks' explicitly sets its 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 explicitly advises when to use this tool ('general home repairs') and implies when not to (specialist tasks as covered by siblings). It also provides a critical prerequisite: 'Call /quote first.' This gives clear operational guidance beyond a simple listing.

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 indicate idempotency (idempotentHint=true) and non-destructiveness (destructiveHint=false). The description adds value by stating the prerequisite to call /quote, which is a behavioral requirement not covered by annotations. It does not contradict annotations, and despite lacking details on auth or rate limits, the combination is adequate.

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 extremely concise—two sentences that front-load the purpose and immediately follow with the return type and prerequisite. Every word is functional, with no redundancy or filler, 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 (10 parameters, 7 required), the description conveys core functionality, return value, and a key workflow step. The presence of an output schema (not provided in input but mentioned) reduces the need to detail return format. Minor gaps remain in explaining the /quote interaction, but overall context is sufficient.

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 for all 10 parameters, so the schema itself handles parameter semantics thoroughly. The description adds no additional meaning beyond what the schema provides, meeting the baseline expectation but not exceeding it.

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 'Book' and the resource 'HVAC technician', and lists specific services like heating/cooling failures, AC tune-ups, furnace inspections, duct cleaning, or smart thermostat installation. This distinguishes it from sibling tools such as book_electrician or book_plumber, 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 a clear prerequisite ('Call /quote first') which guides the agent on required prior steps. However, it does not explicitly state when to use this tool versus alternatives or provide exclusion criteria, leaving room for improvement in guiding 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?

The description adds that the tool returns a confirmed booking and mentions a prerequisite, but beyond that, behavioral details (e.g., what state changes occur, permissions needed) are not disclosed. Annotations already indicate idempotency and non-destructiveness, so the description does not need to repeat those.

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?

Two sentences with no wasted words. The first sentence states the purpose and scope, the second states the output and a key prerequisite. Highly 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 complexity (10 parameters, 7 required) and the presence of an output schema, the description covers the essential action and a critical prerequisite. It does not explain optional parameters like spending_cap_signed, but the schema descriptions cover those. Overall, it is sufficiently complete for a booking 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 provides 100% description coverage for all 10 parameters. The description does not add significant meaning beyond the schema; it only gives examples of the 'issue' parameter implicitly. Baseline 3 is appropriate.

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 uses the verb 'Book' and specifies the resource 'lawn care service' with explicit examples (mowing, edging, fertilization). This clearly distinguishes it from sibling tools like book_appliance_repair or book_plumber.

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?

It explicitly states 'Call /quote first', providing a clear prerequisite for using this tool. It does not specify when not to use it, but the sibling tool names imply that this tool is only for lawn care services.

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 indicate a mutation (readOnlyHint=false). The description adds context: high-urgency dispatch within 1 hour, returns a confirmed booking. However, it does not address the idempotentHint=true annotation, which could be misleading for a booking action.

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?

Three sentences front-load key information: service type, urgency, return value, and prerequisite. 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?

Given 10 parameters (7 required), siblings, and existence of output schema, the description covers the main purpose, usage order, urgency, and what to expect. It is complete for effective 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?

Input schema has 100% description coverage, so all parameters are documented. The description adds no additional parameter details beyond the schema, meeting 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 it books a locksmith and lists specific services (lockouts, rekeying, lock replacement, security upgrades). It distinguishes from siblings by focusing on locksmith-specific work.

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?

Explicitly states 'Call /quote first' as a prerequisite, and notes high-urgency capability for emergencies. This provides clear guidance on when and how to use the tool.

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 idempotent=true, destructiveHint=false, and readOnlyHint=false. The description adds that it 'Returns a confirmed booking' and mentions the prerequisite quote call. However, it does not disclose potential side effects like cancellation policies, refunds, or what happens if the quote is stale. The description provides moderate additional context beyond annotations.

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

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

The description is only two sentences: the first defines the tool's purpose and scope, the second states the output and prerequisite. It is front-loaded and every sentence adds value with no superfluous 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?

The tool has 10 parameters (7 required) and an output schema (not shown). The description covers the service types, return value, and prerequisite. However, it lacks details about error handling, quote expiration, or fallback behavior. Given the complexity of booking, the description is usable 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 coverage is 100%, so parameters are fully described. The description lists the pests but does not add parameter-level details beyond the schema. One parameter ('issue') has an example ('kitchen sink clog') that is misaligned with pest control, which could cause confusion. Overall, the description adds minimal semantic value 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 action ('Book'), the resource ('a pest control specialist'), and explicitly lists specific pests (rodents, ants, etc.) and general inspection. This differentiates it from sibling tools like book_plumber or book_electrician, providing high specificity.

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 includes a direct instruction to 'Call /quote first,' which serves as a prerequisite for using this tool. It implicitly tells when to use this tool (after getting a quote) but does not explicitly state when not to use it (e.g., without a quote). The sibling tools are for other services, so the context is clear.

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 a mutation (readOnlyHint=false) that is idempotent and non-destructive. The description adds valuable behavioral context: returns a confirmed booking or payment setup link, and the pre-requisite of calling /quote. 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?

Three sentences, front-loaded with the primary purpose, then output details, then usage instruction. Efficient and well-structured, though the pre-requisite instruction could be placed earlier.

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 set of sibling booking tools and the presence of an output schema, the description adequately covers the tool's purpose, output, and pre-requisite. The mention of specific plumbing issues provides sufficient 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%, providing thorough parameter definitions. The description adds minimal semantic value beyond listing typical issues (e.g., 'leaks, clogs'), which is already covered by the 'issue' parameter 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 explicitly states 'Book a licensed plumber' and lists specific plumbing issues (leaks, clogs, water heater, etc.), clearly identifying the resource and scope. It effectively distinguishes from sibling tools like book_electrician or book_hvac.

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 pre-requisite guidance: 'Always call /quote first to get the spending_cap_signed token.' However, it does not explicitly state when not to use this tool (e.g., for non-plumbing requests) or compare with 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 indicate the tool is not read-only, not destructive, but idempotent and open-world. The description adds that it returns a confirmed booking and that a prerequisite call to /quote is needed for certain cases. No contradictions with annotations. Could be more explicit about side effects or conflict handling, but overall good.

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 (two sentences plus a note) and front-loaded with key information (what it books). Every sentence adds value. It could be slightly more structured (e.g., bullet points), but it's efficient 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 complexity (10 params, 7 required) and the presence of an output schema, the description covers the essential use cases and explicitly mentions the limitation on large replacements. It does not explain error conditions or what happens with overlapping bookings, but it is complete enough for most 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 the baseline is 3. The description does not provide additional semantics beyond what the schema already offers for parameters like zip, issue, phone, etc. No parameter-specific details are added, so it meets the baseline without exceeding.

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 books a roofer for specific services (storm damage, shingle replacement, leak repair, gutter installation). It distinguishes from large custom replacements that require an on-site quote, avoiding confusion. The verb 'book' is specific and matches the tool's purpose.

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 indicates when to use the tool (for the listed minor repairs) and when not to (large custom replacements). It provides a clear action for excluded cases ('Call /quote first'). However, it does not explicitly contrast with sibling tools like book_handyman or book_plumber, which could cover overlapping issues.

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?

Beyond annotations (readOnlyHint=false, destructiveHint=false), the description explains that the tool logs requests and does not book, adding important behavioral context. No contradictions found. Slightly more detail on side effects could elevate to 5.

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 three sentences, each serving a distinct purpose: purpose, behavior, and usage guidance. It is front-loaded with the core definition. No unnecessary 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?

Given the tool's complexity (8 params, 2 required, output schema exists), the description covers purpose, behavior, and usage constraints thoroughly. It is complete for an agent to decide correctly.

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 description adds little beyond what the schema already provides. The examples in the description (e.g., 'carpet cleaning') are redundant with the schema's service_type_freetext 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 'Log a request for a service type not covered by the 10 named tools' and provides examples (carpet cleaning, dog walking), making the purpose unambiguous and distinct from 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 explicitly says 'Use this when none of the book_* tools match' and clarifies that it 'Does NOT book — adds to the waitlist', providing clear when-to-use and when-not-to-use guidance.

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