Skip to main content
Glama

Create search automation

spur_create_search_automation

Schedule a recurring property search. Every run uses 1 search credit, or 2 when it makes more than 3 ZHomes calls (several event types, tax/sale-history events, furnished-only or description-based filters). New matches can be saved to a list and enriched automatically (auto_enrich spends skip-trace credits on every run, so confirm with the user).

Examples:

  • "every Monday 8am Central, Dallas rentals under $2k" -> frequency="weekly", day_of_week=1, run_time="08:00", timezone="America/Chicago", location="Dallas, TX", max_amount=2000

  • "last Friday of each month" -> frequency="monthly", day_of_week=5, week_of_month=-1

  • "every morning, new pre-foreclosures and price drops in Houston, save to my Distress list" -> frequency="daily", run_time="07:00", location="Houston, TX", events=["preforeclosure","price_drop"], list_id=…

Accepts the same advanced and event filters as spur_search_properties (min_amount / max_amount instead of min_price / max_price). Run the search once with spur_search_properties first so the user can check the results before scheduling.

In automations each event fires once, on the run that first sees it, so the same property isn't saved twice; change events start reporting from the second run. "delisted" is only available here.

Events (pass in events; a listing matches when ANY selected event fired, and is tagged with each):

  • Listing lifecycle: new_listing, coming_soon, coming_soon_active, price_drop, price_increase, pending, sold, back_on_market, delisted (automations only), open_house, rental_listed, rent_change, move_in_moved_up

  • Distress & motivation: preforeclosure, foreclosure, auction, bank_owned, distress_escalated, fsbo, agent_to_fsbo, stale_listing, new_construction

  • Valuation & tax: tax_assessment_posted, assessed_value_jump, tax_paid_dropped (weak), sale_recorded, zestimate_moved, equity_gap, price_below_assessed Direct events (price_drop, pending, sold, preforeclosure, fsbo, new_listing, …) work on the first search. Change events (price_increase, back_on_market, distress_escalated, agent_to_fsbo, rent_change, zestimate_moved, …) compare against what Spur saw on an earlier search of the same area, so the first search only records a baseline. Motivated-seller research usually combines price_drop, back_on_market, stale_listing, agent_to_fsbo and the distress stages.

Input Schema

NameRequiredDescriptionDefault
nameYesAutomation name shown in Spur
eventsNoOnly listings where any of these events happened; see the tool description
enabledNofalse = save it paused
list_idNoSave new matches into this property list
max_ageNoAt most this many years since built
max_zipNoHighest ZIP code in a numeric ZIP range (with min_zip)
min_ageNoYears since built
min_zipNoLowest ZIP code in a numeric ZIP range (with max_zip); prefer zip_list for specific ZIPs
ai_queryNoQualitative intent; each run re-ranks listings by description against it
has_poolNotrue = only listings with a pool
has_viewNotrue = only listings with any view (use views on live search for a specific kind)
keywordsNoComma-separated listing keywords, e.g. "pool, granite"
locationYesCity/state or ZIP, e.g. "Dallas, TX"
max_bedsNoMaximum bedrooms
max_sqftNoMaximum living area in square feet
min_bedsNoMinimum bedrooms
min_sqftNoMinimum living area in square feet
run_timeYes24h local time "HH:MM"
timezoneNoIANA time zone, e.g. "America/Chicago"UTC
zip_listNoKeep only these ZIPs; set location to the city that contains them
auto_saveNoSave new matches to the user's properties
frequencyYesHow often the search runs
home_typeNoZillow home type code
max_bathsNoMaximum bathrooms
min_bathsNoMinimum bathrooms (half baths count as 0.5)
center_latNoRadius search centre (with center_lng and radius_miles)
center_lngNoRadius search centre longitude (with center_lat and radius_miles)
has_garageNotrue = only listings with a garage
max_amountNoMaximum price in USD (rent per month for forRent)
min_amountNoMinimum price in USD (rent per month for forRent)
min_equityNoEstimated equity in USD (Zestimate or price minus assessed value; rough)
auto_enrichNoSkip-trace new matches on every run (spends enrichment credits)
day_of_weekNo0=Sunday … 6=Saturday; for weekly, biweekly, monthly
days_postedNoOnly listings posted within this many days
only_vacantNoLikely vacant (heuristic: description keywords + long days on market)
listing_typeNoSeller / listing kind; for catching NEW entries into a distress stage prefer events
max_lot_sizeNoSquare feet
min_lot_sizeNoSquare feet (1 acre = 43,560)
radius_milesNoKeep only listings within this many miles of center_lat / center_lng
is_waterfrontNotrue = only waterfront listings
neighborhoodsNoNeighborhood / area names matched against address and description
only_absenteeNoAbsentee-owned (owner mails elsewhere)
week_of_monthNoMonthly only; -1 = last
listing_statusNoWhich listings to searchforRent
max_year_builtNoBuilt in or before this year
min_year_builtNoBuilt in or after this year
ownership_typeNobusiness = LLC / corp / trust owners (heuristic)
event_stale_daysNoDays on market that counts as stale (default 90)
is_price_reducedNotrue = only listings whose asking price has been cut
event_within_daysNoLookback window for events, in days (default 7)
max_days_on_marketNoListed at most this many days
min_days_on_marketNoListed at least this many days (higher suggests a motivated seller)
max_ownership_yearsNoOwner has held the property at most this long
min_ownership_yearsNoOwner has held the property at least this long
event_min_change_pctNoMinimum % move for price / rent / Zestimate / assessment events
only_pre_foreclosureNoDistressed / pre-foreclosure (heuristic, includes description keywords)
event_min_equity_gap_pctNoMinimum % Zestimate above last sale price for equity_gap (default 30)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only tell the agent this is a non-idempotent, non-destructive write. The description goes far beyond that: credit costs (1 credit, 2 with >3 ZHomes calls), that auto_enrich spends skip-trace credits every run and should be user-confirmed, and that in automations each event fires once with change events only reporting from the second run. That is exactly the behavioral context annotations cannot carry.

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

Conciseness4/5

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

Front-loaded with the core purpose and cost model, then examples, then the event taxonomy — a sensible structure for a 57-parameter tool. It is long, and the event category lists are lengthy, but nearly every sentence supplies information the schema cannot, so little is wasted.

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?

For a 57-parameter creation tool with no output schema, the description supplies what the agent needs: the credit model, the recommended preview-then-schedule sequence, event firing semantics across runs, and the notation that 'delisted' is automation-only. Nothing essential to calling it correctly is missing.

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

Parameters5/5

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

Schema coverage is already 100%, so the baseline is 3, but the description adds genuine meaning: it maps the schema's min_amount/max_amount vs the live-search min_price/max_price, groups the 29 events into lifecycle/distress/valuation categories, and explains the direct-vs-change-event distinction that no enum value conveys. The worked examples show frequency/day_of_week/week_of_month/timezone mapping concretely.

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?

Opens with a specific verb+resource ('Schedule a recurring property search') and immediately distinguishes itself from the live-search and run/list siblings by framing this as scheduling. An agent can tell it apart from spur_run_search_automation and spur_search_properties 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.

Usage Guidelines5/5

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

Explicitly prescribes the prerequisite workflow ('Run the search once with spur_search_properties first so the user can check the results before scheduling') and names the sibling it hands off to. It also states when to confirm with the user (auto_enrich) and steers away from listing_type toward events for catching new distress entries.

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