zillow-leads-property-data
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| APIFY_TOKEN | Yes | Apify API token from console.apify.com/settings/integrations. The token's account pays the actor's pay-per-event charges: about $0.03 for a 25-row instant catalog sample, about $1.20 per 1,000 fully enriched rows. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| germane_binoculars--zillow-leads-property-dataA | Calls the Actor "germane_binoculars/zillow-leads-property-data" and retrieves its output results: Zillow listings enriched with agent/broker contact info, price/tax history, foreclosure flags, and schools. Catalog mode is an instant paid sample that usually returns rows in a single call. Every other mode dispatches a live-collection order measured in minutes to hours; such calls return a runId plus status immediately — poll via get-actor-run, then fetch rows with get-dataset-items. If a previous call was lost to a client timeout, DO NOT re-submit (you would pay twice): recover the existing runId with get-actor-run-list. |
| get-actor-runA | Get detailed information about a specific Actor run: status, storages (datasets/key-value stores alias map), stats, summary, nextStep. |
| get-dataset-itemsA | Get items (rows) from a dataset — the output/results produced by an Actor run. When the actor tool returns RUNNING, this fetches rows once terminal. |
| get-key-value-store-recordA | Get a single record from a run's key-value store: ORDER_SUMMARY (what actually applied), DEDUP_UPDATE (re-upload on your next order), STATUS (zero-row explanation). |
| abort-actor-runA | Abort an Actor run that is currently starting or running. Results include the updated run details. |
| get-actor-run-listA | List Actor runs for the authenticated user, newest first with desc=true — the recovery entry point when a previous actor-tool call was lost to a client timeout. Account-wide (there is no per-actor filter): match entries on their actId if the account runs other actors too. Each entry's id field is the runId the companion tools take, and entries also carry defaultDatasetId and defaultKeyValueStoreId. |
| get-actor-run-logA | Retrieve recent log lines for a specific Actor run — live collection progress, or the tail of a FAILED run. |
| get-dataset-listA | List datasets on the account — locates a run's output dataset when its ID was lost. Actor runs produce unnamed datasets, so set unnamed=true. |
| get-key-value-store-listA | List key-value stores on the account — locates a run's store (ORDER_SUMMARY / DEDUP_UPDATE / STATUS records) when its ID was lost. Set unnamed=true to include run-produced stores. |
| get-key-value-store-keysA | List the keys in a key-value store with pagination — for this actor's runs, look for ORDER_SUMMARY, DEDUP_UPDATE and STATUS. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 10 tools
Each tool targets a distinct resource or action: actor invocation, run management, dataset reads, and key-value store reads are well separated. A few pairs like get-actor-run vs get-actor-run-list could be confused by name alone, but the descriptions clarify their roles.
Most tools consistently follow a get-<resource>-<detail> pattern, with abort-actor-run as a clear exception. The main inconsistency is the actor invocation tool, which uses the actor identifier instead of a descriptive action verb, making the set slightly uneven.
Ten tools is well-scoped for this server: one to start/collect data, a few to monitor runs, and several to retrieve or recover outputs and storage. Each tool has a clear role without redundancy or bloat.
The toolset covers the full lifecycle of the Zillow leads collection workflow: launching, launching/collecting, polling, aborting, reading logs, fetching dataset rows, and recovering lost run/store/dataset IDs. The recovery and monitoring utilities prevent common dead ends and paid re-execution mistakes.