Skip to main content
Glama

search

Start here. Every result carries trust (facts with who vouches for each and until when, lapsed facts, the job record); trust never changes the order, the price, who is eligible or what needs approval. A search result is not a promise: prices and windows are as of availability_checked_at, and only a booked job is committed. Every business line carries facts_confirmed_at (when its owner last confirmed its facts: a save, CommonTape's switch-on or a Yes on the daily email; null if never), stale (true when that is more than 7 days ago or never) and stale_reason in plain words; a stale business ranks after fresh ones (order_keys: outcome, freshness, nice_met, price, rotation). Describe the cleaning job once and get the businesses that can do it: matches (each with one exact price or a needs list, a quote_token and bookable windows, so you can go straight to hold) needs_more (businesses that take the job but whose price needs something the job did not state: a needs list and a plain why) owner_must_quote (businesses that take the job but whose owner quotes it: a plain why, no price, nothing to hold) and near_misses with the reasons they missed (each a plain code and a label). Each match carries booking_authority: auto (books on its own) or approval_required with its reasons (owner_approves_every_job, over_auto_book_limit, business_not_listed, special_request, or the ask-first key); outcome conditional = approval is needed for something the customer asked for, and book returns pending_approval. book may still ask when it said auto (the owner tightened the setting), never the reverse. It is the business's say-so only: your customer's permission to book or spend is yours to keep. Never assume a business does something not in its answer. Anything not on the word list goes in special_requests as plain text. Job conditions go in inputs.conditions (cond.same_day cond.next_day cond.weekend cond.evening cond.holiday cond.pets cond.no_free_parking cond.stairs_no_lift cond.very_dirty cond.nobody_home cond.mould cond.infestation cond.post_construction cond.gated_entry cond.lockbox_entry): each adds the business's charge, adds nothing, needs the owner's approval, or is not taken (the business is then a near-miss, condition_not_taken). A business is never sent a home it does not take (kind, bedrooms, size, bathrooms, floors). Words: task.floors task.dusting task.bathrooms task.kitchen_surfaces task.trash task.mirrors task.appliance_exteriors task.microwave_interior task.make_beds task.change_linen task.fridge_interior task.oven_interior task.cabinets_interior task.cabinet_fronts task.closets_interior task.baseboards task.doors_frames task.walls_spot task.light_fixtures task.vents task.windows_interior task.window_tracks task.blinds task.tile_grout task.upholstery task.pet_hair task.dishes task.laundry task.organizing task.balcony task.garage task.carpet_shampoo task.post_construction_dust brings.supplies brings.vacuum brings.mop brings.steam_cleaner brings.carpet_machine brings.ladder brings.high_reach brings.industrial_vacuum product.eco_friendly product.fragrance_free product.pet_safe product.uses_customer_products product.bleach_free product.hypoallergenic crew.solo crew.two_or_more crew.three_or_more pay.cash pay.card pay.bank_transfer pay.app pay.check invoice.receipt invoice.person invoice.company. Word list version 6. Each business line says availability_source (owner_stated, or calendar_feed when the business lets CommonTape read its own calendar: busy times are never offered) and calendar_checked_at.

Input Schema

NameRequiredDescriptionDefault
zipYesThe customer's 5-digit US ZIP
scopeNoThe rooms the job covers: leave_out (rooms not to clean) or clean_only (the only rooms to clean), never both, by space.* key. Under a by_rooms price a room left out comes off the price; other prices do not change. Echoed on every answer and shown to the owner.
inputsNoThe job's price inputs: hours, people, frequency, conditions, and bedrooms, bathrooms, square_feet when not stated in property. Each service uses only what its price needs.
must_notNoTasks to leave out, a way to pay the customer cannot use, or crew.solo.
propertyNoThe home, stated once with the words at /api/v1/taxonomy/house_cleaning (property). Unknown or unclear words are refused with the word meant or the question to ask. Bedrooms, bathrooms (when there is no half bathroom) and square feet feed each price that uses them; no need to repeat them in inputs. A by_rooms price and a fixed price's limits read property.spaces only (state every kind the price counts, 0 included; a living area is living + family + formal living rooms).
arrive_byNoOptional. The latest start: a date and time like 2026-10-09T10:00 (wall clock in the job ZIP's time zone, the business's zone) or with an offset (2026-10-09T14:00Z). Only windows that start by then are offered; none left is a near miss no_window_fits. Refused: a time that does not exist (clocks going forward), the past, more than 60 days ahead.
finish_byNoOptional. The latest finish, written like arrive_by: a window is offered only if it starts early enough to end by then (window start plus job_hours, else the window's end). After arrive_by when both are sent.
max_totalNoOptional. The most the customer will pay in all, in dollars (travel and extra charges included). A priced business above it is a near miss over_max_total with the gap in dollars; a window whose own day or hour charge would take the price over it is left out; a business with no price yet (needs_more, owner_must_quote) is listed with max_total not_checked in statuses.
must_haveNoWords the business must offer, e.g. task.fridge_interior, pay.card. Tasks at extra cost, or done only inside a package, are priced in.
service_keyNohouse_cleaning.standard | house_cleaning.deep | house_cleaning.move_in_out. Omit to consider all three.
customer_refNoOptional. Your own label for your customer, so two customers with the same job are not the same job. Never shown to the owner.
nice_to_haveNoWords that rank a business higher but never exclude it.
special_requestsNoUp to 5 plain-text requests not on the word list. Always needs the owner's approval.
id_to_security_hours_beforeNoOptional, with cond.id_to_security in inputs.conditions. How many hours before the job the building wants each cleaner's name and photo ID (1 to 168). A business that can send them at least this far ahead meets it; one that cannot is a near miss id_notice_too_short; one that has not said is not_said in statuses.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / arrive_by
      Added value: +{
      +  "description": "Optional. The latest start: a date and time like 2026-10-09T10:00 (wall clock in the job ZIP's time zone, the business's zone) or with an offset (2026-10-09T14:00Z). Only windows that start by then are offered; none left is a near miss no_window_fits. Refused: a time that does not exist (clocks going forward), the past, more than 60 days ahead.",
      +  "type": "string"
      +}
    • addedInput schema / properties / finish_by
      Added value: +{
      +  "description": "Optional. The latest finish, written like arrive_by: a window is offered only if it starts early enough to end by then (window start plus job_hours, else the window's end). After arrive_by when both are sent.",
      +  "type": "string"
      +}
    • addedInput schema / properties / id_to_security_hours_before
      Added value: +{
      +  "description": "Optional, with cond.id_to_security in inputs.conditions. How many hours before the job the building wants each cleaner's name and photo ID (1 to 168). A business that can send them at least this far ahead meets it; one that cannot is a near miss id_notice_too_short; one that has not said is not_said in statuses.",
      +  "maximum": 9007199254740991,
      +  "minimum": -9007199254740991,
      +  "type": "integer"
      +}
    • addedInput schema / properties / max_total
      Added value: +{
      +  "description": "Optional. The most the customer will pay in all, in dollars (travel and extra charges included). A priced business above it is a near miss over_max_total with the gap in dollars; a window whose own day or hour charge would take the price over it is left out; a business with no price yet (needs_more, owner_must_quote) is listed with max_total not_checked in statuses.",
      +  "type": "number"
      +}
  2. First observed

TDQS

A4/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and discharges it: trust semantics, staleness ranking and order_keys, booking_authority values and approval reasons, condition handling (charge/approve/not-taken/near-miss), availability_source and calendar_checked_at, and near-miss codes. This is unusually rich behavioral disclosure for a mutation-free read tool.

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

Conciseness2/5

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

It is a single dense block of ~900 words with the vocabulary lists jammed into running prose and the purpose buried after metadata discussion. Front-loading is poor and structure (no lists, no sections) makes it hard to parse, though much of the content is genuinely necessary.

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

Completeness4/5

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

For a 14-parameter, nested-schema tool with no output schema, the description covers result shape, statuses, ranking keys, and failure codes thoroughly. Minor gaps remain around the end-to-end flow beyond search→hold→book, but overall an agent has enough to call it correctly.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: the full word list for task.*, brings.*, product.*, crew.*, pay.* and invoice.* keys that the schema only alludes to, plus the behavior of conditions, special_requests and max_total. It goes beyond restating the schema.

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

Purpose4/5

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

The second paragraph gives a specific verb+resource: 'Describe the cleaning job once and get the businesses that can do it,' and enumerates the result buckets (matches, needs_more, owner_must_quote, near_misses). However, the opening sentences ('Start here. Every result carries trust...') describe metadata rather than the tool's purpose, so the actual purpose is delayed, and no sibling (quote, discover, status) is named for contrast.

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?

'Start here' is explicit entry-point guidance, and it says a match lets you 'go straight to hold.' It also flags that book may still ask for approval when it said auto. But it never contrasts itself with quote, discover, or status, so alternative selection is left implicit.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources