HomeMaster

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds real behavioral context beyond that: the answer source is HomeMaster's own service guide, the `answered_from_guide=false` fallback semantics, and the ~20s latency warning. Only missing is anything about output shape, which is minor here.

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 tight sentences, front-loaded with the purpose, then provenance, then the exclusion routing. The aside about Helen/WhatsApp conveys provenance rather than filler, and nothing is repeated from the schema or annotations.

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 one-parameter, no-output-schema tool, the description covers purpose, domain scope, answer provenance, a parseable fallback signal (`answered_from_guide`), latency expectations, and sibling routing. An agent has everything required to select and call it 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 0% for the single `question` parameter, so the description must carry the load, and it does by enumerating acceptable question topics and implicitly bounding the domain of valid input. It does not restate the min/maxLength constraints, but the semantic scope is clear.

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?

States a specific verb+resource ('Ask HomeMaster a question about its services and policies') and immediately scopes what kinds of questions are in-bounds (clean inclusions, supplies, pets, cancelling/rescheduling, preparation). It is immediately distinguishable from siblings like get_quote, find_times, and find_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?

Gives explicit when-to-use (policy/service questions) and explicit when-not-to-use, naming the alternatives: 'Not for prices or times: use get_quote and find_times.' This is exactly the routing information an agent needs.

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 readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral value beyond that: the full state machine (declined, expired, awaiting payment with link, finding expert, booked with next visit, done/cancelled) and a data boundary ('Never includes the customer's details'). It does not cover error behavior for a bad reference.

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 purpose is front-loaded, the state list is dense but each item is meaningful, and the closing constraints are terse. No sentence is wasted.

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 no output schema, the description usefully enumerates the possible status values, which is exactly what an agent needs. It stops short of describing invalid/expired-reference error handling, but is otherwise complete for a single-param read tool.

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

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

Schema coverage is 100% and the single parameter is already documented in the schema (hmr_ prefix, returned by request_booking). The description echoes the source of the reference but adds no format or validation detail beyond the schema, so baseline 3 is correct.

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?

States a specific verb and resource ('Where a request_booking request stands') and enumerates the concrete states it can return. It is clearly distinguished from the sibling request_booking, which creates the request this tool inspects.

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 ties itself explicitly to a request_booking request and redirects changes to 'the customer messages Helen on WhatsApp', which tells the agent this is read-only and where to route mutations. It lacks an explicit 'use after request_booking' trigger, but 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 already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description meaningfully adds that availability is a function of which workers operate near the address, hinting that results reflect a real-world supply condition rather than a static lookup. It does not cover latency, caching or any auth context, hence not a 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?

Two tight sentences with no filler, and the action plus its sequencing constraint are front-loaded. The second sentence earns its place by justifying why a separate check exists.

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?

There is no output schema, and the description's wording ('check whether a service is available') implicitly conveys a boolean-ish availability result, which is enough for an agent to act. It could be slightly more explicit about what an unavailable answer means for next steps, but nothing critical is missing for a read-only two-parameter check.

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% and the service enum is fully documented in the schema, so the schema carries the parameter burden. The description only gestures at the 'service' parameter ('a service is available') and adds no format or default detail beyond what the schema already states, so the 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?

States a specific verb ('check') and resource ('service availability at a Singapore postal code') and situates the call in the workflow ('before looking for times'), which cleanly separates it from siblings like find_times and find_services. The added 'coverage depends on which cleaners or technicians work near the address' explains the underlying notion of coverage rather than just restating the name.

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?

Gives clear ordering guidance ('before looking for times'), which tells an agent when to reach for this tool rather than jumping straight to find_times. It does not name alternatives explicitly or state any exclusion conditions, so it stops short of a full when/when-not/alternatives treatment.

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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely useful behavioral context annotations cannot express: prices are list prices in SGD with GST included, and this is a discovery step rather than a quoter. It stops short of describing pagination or caching, but for a zero-arg catalog read that is minor.

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?

One dense sentence describing contents followed by a short routing instruction. Front-loaded with the resource and geography, with zero filler and no repetition of the title.

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 no output schema, the description carries the burden of saying what comes back, and it does: services, per-service options, and list prices with tax treatment. It also positions the tool in the workflow relative to get_quote, which is everything an agent needs to call a zero-argument read 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?

The tool takes no parameters, so per the rubric the baseline is 4. Schema coverage is 100% and there is nothing parameter-wise for the description to explain or compensate for.

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?

States a specific verb and resource ('List what HomeMaster sells in Singapore') and enumerates the concrete content returned (cleaning visit lengths/frequency, aircon jobs/unit counts, list prices in SGD with GST). The scope words 'Singapore' and 'list prices' separate it cleanly from get_quote's exact-price-with-offers output.

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 directs sequencing ('Call this first when you need the options') and names the alternative and the condition that selects it ('For an exact price with offers, use get_quote'). Nothing is left for the agent to infer.

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 readOnly, idempotent, non-destructive, and closed-world, so safety is covered. The description adds genuine non-obvious behavior: the word 'real' implies live availability, and the closing note explains that times are not held by this call — the checkout page holds a slot for 7 minutes — which is exactly the kind of lifecycle context annotations cannot 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?

Front-loaded with the core purpose, then three tightly parallel mode clauses, then the holding caveat. Every sentence carries distinct information and nothing is repeated from the schema.

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 an 8-parameter, no-output-schema tool this is nearly complete: it explains what each input mode returns (open dates, or start times with prices) and the 14-day cap, compensating for the absent output schema. It does not cover failure modes such as an invalid or unserviceable postal code, which keeps it from 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%, so the baseline is 3 and the schema already documents every parameter's format, enum, and default. The description goes beyond it by explaining the interaction between date and end_date and by noting that a date-only lookup returns times with their price, adding cross-parameter semantics the schema does not express.

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?

States a specific verb and resource ('Find real open dates, or start times ... for a booking at a postal code') and immediately signals the distinguishing scope of the tool. An agent can tell it apart from find_services, get_quote, and request_booking without opening a schema.

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 maps the three parameter combinations to three distinct behaviors (no date = next 14 days of dates; date only = that day's times; date + end_date = dates in range, max 14 days), which is effectively a when-to-use guide. It never names a sibling alternative such as find_services or get_quote, so it stops short of explicit routing.

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 cover safety (readOnly, idempotent, non-destructive, closed-world), so the description's job is to disclose result semantics — and it does: evening rates are returned separately, and weekly/bi-weekly cleans return both the prepaid 3-visit pack and per-visit pricing. It doesn't state whether prices are cached, currency, or expiry, but the behavioural disclosure is well above the annotation baseline.

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 what the tool returns, then the parameter guidance. The middle sentence is somewhat compound and the closing clause about packs is dense, but no sentence is padding.

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 no output schema, the description must convey the return shape, and it does describe the prepaid-pack vs per-visit distinction for recurring cleans. Missing currency/format details and whether the quote expires, but for a zero-required-parameter price lookup it is largely 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 the baseline is 3, but the description adds interaction semantics the schema does not: date+start_time together produce a slot-exact quote, while omitting them yields a length/job-level price. That conditional relationship is the key to using the seven optional parameters correctly.

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?

States a specific verb+resource with scope: 'the price the checkout will show a new customer'. It even characterises whose price it is (new customer) and mentions evening rates and vouchers, which distinguishes it from find_services (what we sell) and find_times (when it's available).

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 tells the agent to supply date and start_time 'from find_times' for an exact slot figure, and what happens without them (price for that length or job). It names the upstream sibling tools that feed the parameters, so the routing decision is unambiguous.

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 only declare readOnly=false, idempotent=true, destructive=false. The description adds substantial context beyond them: the WhatsApp confirmation card, the 60-minute decision window, that nothing is booked until the customer taps 'Yes', that the slot is not held while they decide, and the payment-link flow. These are exactly the behavioral traits an agent needs and cannot get from the 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?

Front-loads the core purpose and then layers workflow, caveat, return reference, alternative tool, and the customer-consent warning. Each sentence carries a distinct fact, though the middle section is dense and could be split for easier scanning.

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 9-parameter mutation tool with no output schema, the description supplies the missing pieces: what happens after the call, what the return reference is for, and which tool follows up. Nothing an agent needs to invoke it correctly is absent.

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 reiterates 'use a start time from find_times' and {'Cleaning only'} for hours/frequency, but those facts are already present in the schema field descriptions, so it adds little semantic value beyond what is structured.

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?

States a specific verb and resource ('Ask HomeMaster to book a home clean for the customer') and immediately separates itself from the sibling 'start_booking' by restricting scope to cleaning ('for aircon use start_booking'). An agent can identify the tool without opening the schema.

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?

Gives explicit preconditions (use a start time from find_times; ask the customer before sending because it messages their phone) and names the alternative for a different service. Both when-to-use and when-not-to-use are covered.

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 only declare the safety profile (readOnly, idempotent, non-destructive); the description adds the operational traits an agent actually needs: nothing is charged, the customer flow on the page, the 7-minute time hold, the WhatsApp 6-digit verification, and the payment-responsibility boundary. This is substantive context beyond the structured hints.

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 purpose and the no-charge caveat are front-loaded, and each sentence carries distinct information. The customer-flow sentence is longer than strictly needed for tool selection, but it is relevant for an agent that must instruct the customer, so trimming would cost 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?

With no output schema, the description still says what is returned (a filled-in checkout link to hand to the customer) and who does the remaining steps. Combined with the schema-level parameter documentation and the annotations, an agent has everything needed to call it and act on the result.

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% and the enums/defaults (service, frequency) are documented in the schema itself, so the baseline of 3 applies. The description only alludes to 'the address and the visit' being pre-filled and does not add format or constraint detail 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?

Opens with a concrete verb and artifact: get a checkout link with address and visit pre-filled. It immediately bounds the action ('nothing is booked or charged by this tool'), which is exactly the distinction an agent needs from the sibling request_booking.

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?

Names the alternative (request_booking) and the precise condition that selects it: booking FOR the customer for home cleaning, confirmed by one tap on WhatsApp. It also states the agent-side rule ('never pay on the customer's behalf'), leaving no routing inference to the agent.

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