Sunrays — Local Service Booking

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

Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds value by stating the result is a confirmed booking and advising to get a quote first, but does not elaborate on other behavioral details like state changes or retry safety 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?

Two concise sentences: first states the core purpose, second provides critical usage guidance and return value. No fluff, front-loaded, and 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 the presence of an output schema (not shown but indicated), the description appropriately complements it by stating the return type ('confirmed booking'). The tool's purpose, required pre-step, and supported appliances are fully covered.

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 the input schema already fully describes all parameters. The description does not add parameter-specific semantics beyond the schema, 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 tool books an appliance repair technician for specific major appliances (washing machines, dryers, refrigerators, dishwashers, ovens, etc.), distinguishing it from sibling tools like book_electrician 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?

The description explicitly instructs 'Call /quote first' and lists the appliance types, making it clear when to use this tool and the prerequisite step before booking.

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 destructiveHint=true and idempotentHint=true, so the description's statement 'Returns a confirmed booking' aligns with a state-changing operation. The description adds the prerequisite 'Call /quote first', but does not elaborate on side effects (e.g., whether bookings can be cancelled) or provide additional behavioral context beyond what annotations offer.

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 long and efficiently conveys the tool's purpose, service scope, and a crucial prerequisite. It is front-loaded with the action and specific services, followed by the return type and instruction. There is no wasted language, though the placement of the /quote instruction at the end could be considered less prominent.

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 has 10 parameters (7 required) and an output schema, the description adequately outlines what the tool does and that it returns a booking. It references the /quote endpoint as a prerequisite, which provides important workflow context. However, it does not explain the booking confirmation process or any cancellation behavior, which might be expected for a complex 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 schema has 100% description coverage for all 10 parameters, so the schema already documents parameter meaning comprehensively. The description mentions specific service categories (e.g., 'outlet repairs') which relate to the 'issue' parameter, but does not add new semantic information beyond the schema. 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 'Book a licensed electrician' and lists specific electrical services (outlet repairs, breaker issues, etc.), which distinguishes it from sibling tools like book_plumber or book_hvac. The verb 'Book' combined with the resource 'licensed electrician' provides a specific and unambiguous 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 includes the instruction 'Call /quote first', which establishes a prerequisite for using this tool. However, it does not explicitly state when to use this tool versus alternatives (e.g., for non-electrical issues) or provide exclusion criteria. The context is clear but lacks explicit when-not 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 indicate destructiveHint=true and idempotentHint=true. The description adds context that the tool returns a confirmed booking and implies a quote step, which enriches the behavioral profile 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?

The description is two sentences, front-loading the purpose and a key usage hint. Every word is necessary; no fluff.

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 has 10 parameters, 7 required, and an output schema, the description is minimal. It covers the purpose and precondition but lacks guidance on required fields like caller_id or spending_cap_signed. The schema fills some gaps, but the description could be more comprehensive 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?

Schema description coverage is 100%, so the baseline is 3. The tool description does not add significant parameter-level detail beyond listing issues; it relies on the schema for parameter meanings.

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 specifies the verb (book), resource (garage door technician), and specific issues (broken springs, off-track doors, opener failures, installation). This distinguishes it from sibling tools like book_plumber or book_electrician by focusing on garage door services.

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 precondition ('Call /quote first') but lacks explicit guidance on when to use this tool versus alternatives. It does not compare against similar booking tools or state when not to use it.

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 destructive and idempotent behavior. The description adds that it returns a confirmed booking and requires a prior quote. This is adequate but doesn't disclose failure modes or side effects beyond what annotations suggest.

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?

Extremely concise: one sentence with examples plus a clear instruction. Every word adds value, front-loaded with 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 10 parameters (7 required) and an output schema, the description covers the tool's purpose and a critical prerequisite. However, it lacks guidance on what happens after booking, payment, or cancellation, relying on annotations for safety profile. Adequate but not 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?

Schema coverage is 100%, so baseline is 3. The description does not add parameter-specific semantics beyond the schema. It provides context for what the tool does but no param 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?

Description clearly states the tool books a handyman for general home repairs, listing specific examples that distinguish it from specialized sibling tools. The phrase 'non-specialist tasks' effectively differentiates from electrician, plumber, etc.

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?

Provides a crucial prerequisite: 'Call /quote first.' While it doesn't explicitly state when not to use, the sibling list and 'non-specialist tasks' imply exclusion of specialized work. Good but could be more explicit.

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 idempotentHint=true, so the tool is known to have side effects. The description adds that it returns a confirmed booking, which is useful but does not elaborate on payment, cancellations, or other behavioral implications. With annotations, the description adds marginal value.

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, concise and front-loaded with the purpose and key instructions. Every sentence adds value with 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?

The tool has 10 parameters with full schema coverage and an output schema exists. The description covers the booking action, return value, and a prerequisite. It is adequately complete but could mention spending cap implications or side effects given openWorldHint=true.

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 each parameter is already documented. The tool description does not add significant meaning beyond listing example services. 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 clearly states the tool books an HVAC technician for specific services like heating/cooling failures, AC tune-ups, etc. It distinguishes from sibling tools by specifying HVAC, while other tools cover different 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?

The description explicitly instructs to call /quote first, providing a clear prerequisite. However, it does not compare with sibling tools or specify when to use this over alternatives, but the tool name and context imply usage for HVAC 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?

Annotations already provide destructiveHint, openWorldHint, and idempotentHint. The description adds that the tool returns a confirmed booking and requires a quote first, which gives extra workflow 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?

Two concise sentences that front-load the main purpose and a key workflow instruction. 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 10 parameters and a sibling list of 11 tools, the description provides essential info (what it does, that booking is confirmed, call /quote first). Could add more about prerequisites or post-conditions but output schema exists, and annotations cover destructiveness.

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 already has 100% coverage with detailed parameter descriptions. The tool description does not add parameter-specific meaning; it only mentions the service category (lawn care), which indirectly relates to the 'issue' parameter but is not necessary.

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 lawn care services and lists specific services (mowing, edging, fertilization, etc.), distinguishing 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?

The description implies usage via service list and name, but does not explicitly state when to use this tool versus alternatives. The instruction 'Call /quote first' provides a procedural hint but lacks exclusion criteria.

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 destructiveHint=true and readOnlyHint=false. The description adds that it can dispatch urgently and returns a confirmed booking, complementing the annotations without 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 sentences, front-loaded with the core purpose, followed by key usage tips. 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?

For a complex tool with 10 parameters and many siblings, the description covers main use cases, urgency, and the quoting prerequisite. Output schema exists, so return value explanation 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?

Schema covers 100% of parameters with descriptions. The description adds minimal extra parameter meaning (e.g., urgency context). 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 clearly states 'Book a locksmith' and lists specific services (lockouts, rekeying, lock replacement, security upgrades). It distinguishes from sibling tools like book_plumber and book_electrician by naming the trade and services.

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?

Provides context: 'High-urgency capable — can dispatch within 1 hour for emergencies' and advises to 'Call /quote first'. It doesn't explicitly exclude scenarios, but the tool name and sibling list make differentiation 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 already declare idempotentHint=true and destructiveHint=true. Description adds that the tool returns a confirmed booking and requires a prior quote, which is useful 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?

Two sentences, no fluff. Key information is front-loaded: action, resource, pest types, outcome, and prerequisite.

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 has 10 parameters (7 required) and an output schema, the description adequately covers the main purpose, outcome, and prerequisite. Could mention return format briefly, but not necessary due to 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 coverage is 100%, so baseline 3 applies. Description does not elaborate on parameter usage beyond what the schema already specifies; it only adds the prerequisite quote call.

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?

Clearly states the action ('book'), resource ('pest control specialist'), and specific pest types (rodents, ants, etc.). Distinguishes from sibling tools like book_plumber or book_electrician by specializing in pest control.

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?

Provides explicit prerequisite ('Call /quote first') and outcome ('Returns a confirmed booking'). Does not specify when not to use or list alternatives, but the sibling set implies specialization.

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 value beyond annotations by disclosing return value (confirmed booking with price and dispatch time) and fallback (payment setup link). It aligns with destructiveHint=true. No contradictions.

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

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

The description is two sentences, front-loaded with core purpose, and every sentence adds value. 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 the presence of an output schema and comprehensive annotations, the description adequately covers what the agent needs to know. It specifies scope, prerequisite, and outcomes.

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 the baseline is 3. The description adds context such as the spending_cap_signed parameter being optional and its usage, which improves parameter understanding.

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 licensed plumber for specific issues (leaks, clogs, etc.), distinguishing it from sibling tools like book_electrician. The verb 'book' and resource 'plumber' are explicit.

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 instructs to call /quote first for a spending_cap_signed token, providing a key prerequisite. It does not explicitly state when not to use the tool, but the sibling list implies exclusivity to plumbing.

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 provide idempotentHint and destructiveHint. The description adds that the tool returns a confirmed booking, which is useful. However, it does not disclose potential side effects like charges or how idempotency works. The mention of calling /quote first hints at a workflow but lacks detail on what /quote does.

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 a call to action. It front-loads the purpose, then includes limitations and instructions. Every sentence adds value, though the structure could be slightly improved by grouping related 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 complexity (10 parameters, 7 required) and the presence of a full schema and output schema, the description covers the essential aspects: purpose, limitations, and prerequisite. It does not detail the output format or error conditions, but this is partially covered by the output schema. Overall, it is sufficiently complete for an agent to use 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 coverage is 100%, so the baseline is 3. The description adds examples for specific parameters (e.g., 'issue' includes concrete problems) but does not provide significant additional meaning beyond what is already in the schema. No new constraints or formatting details are given.

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 that the tool books a roofer for specific services like storm damage assessment, shingle replacement, roof leak repair, or gutter installation. It also distinguishes itself by explicitly noting that large custom roof replacements are not available, which helps differentiate from other 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 provides clear guidance on when to use the tool (for roof repair services) and when not to use it (large custom roof replacements require on-site quote). It also instructs to 'Call /quote first', indicating a prerequisite step. However, it does not explicitly compare with sibling tools beyond the note about large replacements.

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?

Describes behavioral traits beyond annotations: states it does NOT book, logs a request, and adds to waitlist for future demand signaling. Annotations mark destructiveHint: true, consistent with creating a waitlist entry.

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, each earning its place: first defines purpose and examples, second clarifies behavior and usage condition. No fluff.

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 8 parameters (2 required), full schema coverage, annotations present, and an output schema, the description completes the picture by explaining purpose, exclusion from siblings, and behavioral nuance.

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 covers 100% of parameters with descriptions, so baseline is 3. Description does not add additional semantics beyond the overall context of the 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?

Description states verb 'Log a request' and specific resource 'service type not covered by the 10 named tools', with concrete examples. Distinguishes from sibling book_* tools by explicitly stating this is for unmatched services.

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 says to use when 'none of the book_* tools match the user's need' and clarifies that it does not book but adds to waitlist, giving clear when-to-use and what-not-to-expect.

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