Skip to main content
Glama

HomeMaster

by co.homemaster
OverviewDiscussionsAdmin

Find open dates and start times

find_times
Read-onlyIdempotent

Find real open dates, or start times on one date, for a booking at a postal code. Without date: the open dates in the next 14 days. With date only: that day's start times, each with its price. With date and end_date: the open dates in that range (at most 14 days). A booking can only start inside the booking window: a later date is refused, and the refusal names the last day. A weekly or bi-weekly plan carries on past it. Times are not held here: on the checkout page a picked time is held for 7 minutes, and a direct booking's time is held once it is paid.

Input Schema

NameRequiredDescriptionDefault
dateNoYYYY-MM-DD, Singapore date.
hoursNoCleaning only: visit length in hours (see find_services for the lengths we sell, e.g. 2, 3 or 4). When the customer has not said, use usual_hours on the cleaning entry of find_services (find_times and get_quote use it when hours is left out) and say it in your proposal; do not ask. Only if they ask how long their home needs, suggest from hours_by_home.
serviceYesRequired: the code of the service the customer asked for, from find_services (e.g. cleaning, aircon, sofa_cleaning). cleaning = home cleaning by the hour, a housekeeper's work (tidying, fridge, dishes, plants, vacuuming soft furnishings included); a deep, spring or move-out clean is a home clean with more hours, and a machine deep clean of one item is its own service. Every other service is booked by the job: give job_type and unit_count from its card.
end_dateNoYYYY-MM-DD. With date, return open dates in the range instead of times.
job_typeNoEvery service but cleaning: the job, a job_type from the service's card (find_services with its code), e.g. general_service for aircon. A service quoted for each job has one: its quotation visit (quotation_visit) or consultation.
frequencyNoCleaning only: one-time, weekly, or bi-weekly (every 2 weeks).one-time
unit_countNoEvery service but cleaning: how many, in the service's own unit from its card (units, pieces, hours, panels...). 1 for a quotation visit or a consultation.
postal_codeYes6-digit Singapore postal code, e.g. 238823.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / hours / description
      Previous value: -"Cleaning only: visit length in hours (see find_services for the lengths we sell, e.g. 2, 3 or 4). A customer unsure how long their home needs: the suggestion by home is hours_by_home on the cleaning entry of find_services."New value: +"Cleaning only: visit length in hours (see find_services for the lengths we sell, e.g. 2, 3 or 4). When the customer has not said, use usual_hours on the cleaning entry of find_services (find_times and get_quote use it when hours is left out) and say it in your proposal; do not ask. Only if they ask how long their home needs, suggest from hours_by_home."
  2. Changed1 schema field changed
    • changedInput schema / properties / service / description
      Previous value: -"Required: the code of the service the customer asked for, from find_services (e.g. cleaning, aircon, sofa_cleaning). cleaning = home cleaning by the hour, general housekeeping only: a deep clean, a spring clean, a move-out clean or one item cleaned is its own service. Every other service is booked by the job: give job_type and unit_count from its card."New value: +"Required: the code of the service the customer asked for, from find_services (e.g. cleaning, aircon, sofa_cleaning). cleaning = home cleaning by the hour, a housekeeper's work (tidying, fridge, dishes, plants, vacuuming soft furnishings included); a deep, spring or move-out clean is a home clean with more hours, and a machine deep clean of one item is its own service. Every other service is booked by the job: give job_type and unit_count from its card."
  3. Changed1 schema field changed
    • changedInput schema / properties / hours / description
      Previous value: -"Cleaning only: visit length in hours (see find_services for the lengths we sell, e.g. 2, 3 or 4)."New value: +"Cleaning only: visit length in hours (see find_services for the lengths we sell, e.g. 2, 3 or 4). A customer unsure how long their home needs: the suggestion by home is hours_by_home on the cleaning entry of find_services."
  4. Changed4 schema fields changed
    • changedInput schema / properties / job_type / description
      Previous value: -"Aircon only: the job, e.g. general_service, chemical_wash, chemical_overhaul (see find_services)."New value: +"Every service but cleaning: the job, a job_type from the service's card (find_services with its code), e.g. general_service for aircon. A service quoted for each job has one: its quotation visit (quotation_visit) or consultation."
    • changedInput schema / properties / service / description
      Previous value: -"Required: the service the customer asked for, from find_services. This tool checks a service booked online, one that find_services lists under services: cleaning = home cleaning by the hour (general housekeeping only; a deep clean, spring clean or move-out clean is a different service, under more_services). aircon = aircon servicing, checked here only while find_services lists it under services; while it is under more_services this tool answers with how it is booked."New value: +"Required: the code of the service the customer asked for, from find_services (e.g. cleaning, aircon, sofa_cleaning). cleaning = home cleaning by the hour, general housekeeping only: a deep clean, a spring clean, a move-out clean or one item cleaned is its own service. Every other service is booked by the job: give job_type and unit_count from its card."
    • removedInput schema / properties / service / enum
      Removed value: -[
-  "cleaning",
-  "aircon"
-]
    • changedInput schema / properties / unit_count / description
      Previous value: -"Aircon only: number of aircon units (fan coils)."New value: +"Every service but cleaning: how many, in the service's own unit from its card (units, pieces, hours, panels...). 1 for a quotation visit or a consultation."
  5. Changed1 schema field changed
    • changedInput schema / properties / service / description
      Previous value: -"Required: the service the customer asked for, from find_services. cleaning = home cleaning by the hour (general housekeeping only); aircon = aircon servicing, priced per job and number of units."New value: +"Required: the service the customer asked for, from find_services. This tool checks a service booked online, one that find_services lists under services: cleaning = home cleaning by the hour (general housekeeping only; a deep clean, spring clean or move-out clean is a different service, under more_services). aircon = aircon servicing, checked here only while find_services lists it under services; while it is under more_services this tool answers with how it is booked."
  6. Changed3 schema fields changed
    • removedInput schema / properties / service / default
      Removed value: -"cleaning"
    • changedInput schema / properties / service / description
      Previous value: -"cleaning = home cleaning by the hour; aircon = aircon servicing, priced per job and number of units."New value: +"Required: the service the customer asked for, from find_services. cleaning = home cleaning by the hour (general housekeeping only); aircon = aircon servicing, priced per job and number of units."
    • changedInput schema / required
      Previous value: -[
-  "postal_code"
-]New value: +[
+  "postal_code",
+  "service"
+]
  7. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the readOnly/idempotent/non-destructive annotations, it discloses that a later date is refused with the last day named, that weekly/bi-weekly plans carry past the window, and that times are not held here but held 7 minutes on checkout or once paid. These are non-obvious behavioral traits an agent could not infer from annotations or schema.

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

Conciseness5/5

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

It is front-loaded with the mode logic, then constraints, then hold semantics, in telegraphed sentences. Despite being dense, every sentence carries distinct information with no filler.

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

Completeness5/5

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

No output schema exists, so the description carries the return-value burden and does so, stating dates, start times with prices, and refusal messages. Combined with the window and hold behavior, an agent has everything needed to call and interpret the tool.

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

Parameters4/5

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

With 100% schema coverage the baseline is 3, but the description adds cross-parameter interaction semantics the schema does not convey — how date and end_date combine to switch output mode and the 14-day cap on ranges. It also acknowledges hours defaults via find_services, adding meaning beyond the field descriptions.

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

Purpose5/5

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

The description names a specific verb (find) and resource (open dates / start times) and enumerates the exact three mode behaviors. An agent can immediately tell this returns availability, not a quote or a booking, distinguishing it from get_quote and request_booking.

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

Usage Guidelines4/5

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

It precisely states the conditions selecting each mode (no date = next 14 days; date only = that day's times; date + end_date = range) and the booking-window constraint with refusal behavior. It does not explicitly name sibling alternatives like get_quote for pricing, leaving that 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.

All HomeMaster toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources