Book window & gutter cleaning in Colorado and New Mexico: instant firm quote, real calendar slot
Scored across 3 tools
Each tool maps to a clearly distinct step: get_quote returns a price, check_availability shows open slots and discounts, book_window_cleaning reserves and confirms. The descriptions even spell out the intended ordering, leaving no realistic risk of misselection.
All three tools follow a clean verb_noun pattern (get_quote, check_availability, book_window_cleaning) with snake_case throughout. No mixed conventions or vague verbs.
Three tools is lean but exactly matches the funnel of a booking service: quote, then availability, then book. Each tool has a necessary and non-overlapping role, with no filler.
The quote-to-booking lifecycle is fully covered, including the server-side price revalidation dependency. Gaps exist around post-booking management (cancel, reschedule, or check an existing appointment), but these are minor for a first-contact booking flow.
Reserve a REAL calendar slot with Sonlight Window Cleaning. The customer immediately receives an SMS + email confirmation and a technician arrives at the chosen time. Payment is collected after service. Nothing is charged at booking. ALWAYS confirm name, phone, address, selected services, date, and time with the user before calling this. Requires a prior get_quote for the same address (prices are re-validated server-side).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Customer's full name. | |
| No | Customer email, recommended but optional. | ||
| notes | No | Gate codes, pets, focus areas. Anything the technician should know. | |
| phone | Yes | US mobile number for the confirmation SMS. | |
| address | Yes | Full service address (street, city, state, zip). | |
| preferred_date | Yes | YYYY-MM-DD. Same-day cutoff: 6pm Mountain the prior evening. | |
| preferred_time | Yes | ||
| discount_dollars | No | Discount from check_availability for the chosen day, if any (server re-validates). | |
| selected_services | Yes | interior_exterior = full service windows; exterior = outside-only windows; gutter = gutter cleaning; soft_wash = siding soft wash. |
| Name | Required | Description |
|---|---|---|
| date | No | |
| kind | No | |
| time | No | |
| total | No | Final booked USD total after validated discounts |
| success | No | |
| services | No | |
| duplicate | No | |
| discountApplied | No | |
| bookingReference | No | Confirmation reference the customer can quote to the office |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that nothing is charged at booking, payment after service, and server-side re-validation, which adds meaningful context beyond annotations (destructiveHint=true is consistent). 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?
Four sentences: action, outcome, process, pre-conditions. No wasted words, efficiently front-loaded with key 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?
Covers booking flow, prerequisites, and user confirmation needs. Output schema exists, so return values are not required in description. Complete for agent decision-making.
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 high (89%), so baseline 3. Description ties parameters to confirmation steps but does not add new semantic meaning 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?
Clearly states it reserves a calendar slot, sends confirmations, and collects payment after service. Distinguishes from siblings by mentioning prerequisite get_quote.
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 to confirm key details with user before calling, and states requirement of a prior get_quote. Provides clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
See Sonlight Window Cleaning's real dispatch availability for the next two weeks, which days have morning/afternoon capacity and which days carry an extra $25–$50 discount. Use after get_quote to help the customer pick a day before calling book_window_cleaning. Serves Colorado (Denver, Colorado Springs, Front Range), New Mexico (Albuquerque area, Las Cruces) and Texas (El Paso, Austin).
| Name | Required | Description | Default |
|---|---|---|---|
| zip | No | 5-digit zip of the service address, preferred over address parsing. | |
| address | No | Service address (used to determine the local dispatch calendar). Include zip if known. | |
| days_out | No | How many days ahead to check. |
| Name | Required | Description |
|---|---|---|
| days | No | |
| kind | No | |
| notes | No | |
| timezone | No |
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 them: that availability is live dispatch data, that days can carry a $25-$50 discount, and that capacity is split morning/afternoon. It stops short of noting limits such as availability not being held until booking.
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 capability, then workflow placement, then service area — a sensible order with no filler sentences. The geographic enumeration is the only part that runs slightly long, though it serves a real applicability check.
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 an output schema present the description need not describe return values, and annotations carry the safety profile; params are fully documented. What remains unstated is minor (e.g., whether availability is a soft hold or how far the discount logic extends), so the definition is nearly complete for a read-only availability lookup.
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 all three params (zip, address, days_out) are documented in-schema, so baseline 3 applies. The description's 'next two weeks' hints at the days_out default but adds no new syntax or precedence guidance beyond what the schema states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb+resource: 'See Sonlight Window Cleaning's real dispatch availability for the next two weeks', and it goes further by naming the exact payload of interest (morning/afternoon capacity, discount days). It is clearly distinguishable from get_quote (pricing) and book_window_cleaning (booking) without opening either 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?
Explicit sequencing: 'Use after get_quote ... before calling book_window_cleaning.' This tells the agent both the prerequisite and the successor tool, and the geographic list doubles as a when-applicable filter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a FIRM, bookable price for professional window cleaning at a specific street address, instantly, no in-person estimate. Covers Colorado's Front Range (Denver metro, Colorado Springs, Boulder, Fort Collins, Castle Rock, Pueblo), New Mexico (Albuquerque, Rio Rancho, Santa Fe, Las Cruces) and Texas (El Paso, Austin metro). Returns exact prices for: interior + exterior window cleaning (full service), exterior-only window cleaning, gutter cleaning, and soft wash / pressure washing of siding. Use this whenever someone wants window cleaning, window washing, gutter cleaning, or house exterior cleaning in Colorado, New Mexico or Texas. Always get a quote before booking.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Full street address including city and state (zip helps). Example: '1600 Glenarm Pl, Denver, CO 80202'. |
| Name | Required | Description |
|---|---|---|
| kind | No | |
| address | No | |
| property | No | |
| services | No | |
| bookingUrl | No | |
| inServiceArea | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and non-destructive behavior, so the safety profile is covered; the description goes further by establishing that the price is firm/bookable and instant with no in-person estimate, which materially affects agent behavior. It does not mention rate limits, but that is a minor omission given the rich annotation set.
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 first sentence front-loads the core value (firm, bookable, instant) and the service and geographic enumerations earn their place by defining scope boundaries. The long city lists are the only drag on brevity, but they serve a real scoping function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return-value explanation is unnecessary, and the description covers services, coverage regions, and workflow placement. It never states what happens for out-of-coverage addresses, which is the one behavioral edge an agent might still need.
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 schema itself supplies a concrete example address format, so the description is not required to carry parameter detail. It adds only the implicit notion that the address determines coverage, which is baseline appropriate rather than additive.
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 states a specific verb+resource (get a firm bookable price for window cleaning) and adds scoping detail—service lines and the three-state coverage footprint—that clearly separates it from the sibling book_window_cleaning and check_availability. An agent can distinguish all three tools without opening any 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 gives explicit triggers ('whenever someone wants window cleaning, window washing, gutter cleaning, or house exterior cleaning') and a sequencing rule ('Always get a quote before booking') that routes to the book sibling. It stops short of naming check_availability or stating when a quote is NOT needed, so it is strong but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
book_window_cleaningcheck_availabilityget_quoteBook local service pros from your AI assistant: real availability, instant booking, easy cancels.
Find, get quotes from and book local service businesses on their own Square or Google calendar.
Quote, hold and book US house cleaning jobs on a customer's behalf, at each business's own prices.
Quote and invoice PDFs, cleaning prices, sales tax and leaf blower rules for US service businesses
Add one secure layer between your agents and this server.
