Build a project

Use Zillow Property Data in Claude with MCP

A worked research session with the PropertiesAPI MCP server: connect Claude, compare a shortlist of Zillow homes, handle an ambiguous address and check your remaining credits.

7 min read

Why connect Claude to property data at all

Claude can reason about a shortlist of homes, but without a data connection it can only work from what you paste into the chat. The Model Context Protocol is an open standard for connecting AI applications to external tools. PropertiesAPI runs a remote MCP server, so Claude can look up the homes you name and read the same JSON the REST API returns.

This article walks through one research session from start to finish. The setup steps themselves live in the MCP documentation, which stays the reference for client-specific instructions. Here the focus is what a useful session looks like, which tool Claude calls at each step, and where you still need to check the answer yourself.

Connect once, then confirm the tools are listed

In Claude Code, one command adds the server with your API key in an Authorization header. Claude Desktop and claude.ai use a custom connector with the same server URL and header. Claude Code saves the command without checking the key, so run /mcp afterwards and confirm that propertiesapi is connected and lists its tools.

The server exposes exactly three tools. Knowing them helps you phrase requests and spot an answer that could not have come from the data.

Claude Code
claude mcp add --transport http propertiesapi https://api.propertiesapi.com/mcp \
  --header "Authorization: Bearer YOUR_KEY"

# Then, inside Claude Code:
/mcp
ToolWhat it doesCost
get_zillow_propertyOne home, by exactly one of url, zpid or address.Same as a REST lookup; free from the cache.
get_zillow_propertiesSeveral homes in one call, up to 50 items.Each item billed like a single lookup.
get_usageYour plan, credits used and credits left.Free: it runs no lookup.

Read Claude's table like a reviewer

Check three things before you use the table. First, identity: compare each returned address and unit with the home you meant. Second, meaning: price is a listing price for a sale listing and a monthly rent for a rental, while zestimate and rentZestimate are Zillow's estimates, shown only when Zillow shows them. Third, time: meta.fetched_at says when each home was collected, and meta.cached says whether this answer came from an earlier collection.

Ask follow-up questions that stay inside the data. Price per square foot, the gap between asking price and Zestimate, and the latest price change all come from fields in the response or from data.calculated, which holds simple arithmetic on those same fields. Questions such as who owns the home, what nearby homes sold for, or which homes in a ZIP code are for sale cannot be answered by these tools, because none of them searches a market or returns owner records.

If Claude offers a figure you cannot trace to a field, ask it which field it used. A good habit is to request the raw values next to any derived number.

Handle an address that matches a different home

Later in the session the user adds a home by address. Address matching can land on a neighboring house or a different unit. When that happens the tool returns address_ambiguous instead of guessing, nothing is billed, and the error carries the closest match as a Zillow link.

The right behavior is for Claude to show you that link and ask whether it is the home you meant, then look it up by URL. The tool descriptions tell Claude to do this, but you are still the one who decides. If the candidate is wrong, add the unit, city, state or ZIP code to the address and try again.

Session, part two (illustrative)
You: Add 2640 Steiner St, San Francisco, CA 94115 to the comparison.

Claude calls get_zillow_property with { "address": "2640 Steiner St, San Francisco, CA 94115" }.

If the tool error is address_ambiguous, error.details.candidate.detailUrl is the
closest Zillow match. Claude should show you that link and ask before calling
get_zillow_property again with { "url": "<that detailUrl>" }.

You: How many credits do I have left?

Claude calls get_usage (no lookup, no credit).

Prompts that keep the answers grounded

The quality of a property research session depends more on the request than on the model. Requests that name specific homes, specific fields and a rule for missing data produce answers you can check. Open-ended requests invite Claude to fill gaps with general knowledge, which may be out of date or simply wrong for the home in question.

These patterns have worked well for this kind of session. Each one ties the answer to fields the tools actually return.

  • Name the homes by link or zpid, and ask Claude to confirm the returned address for each before comparing them.
  • List the fields you want, such as price, homeStatus, zestimate, rentZestimate, livingArea and daysOnZillow, instead of asking for everything.
  • Ask for missing values to be written as missing, and for the reason when the response gives one.
  • Ask for meta.fetched_at and meta.cached next to each row so you know how recent each observation is.
  • Ask Claude to keep rentals and sale listings in separate tables, because price means a monthly rent for one and a listing price for the other.
  • When you want a derived figure, ask Claude to show the inputs and the formula next to the result.

Credits and the cache during a conversation

The MCP tools run the same lookups as the API, so billing is the same. Zillow links and addresses cost the same: 1 credit per successful lookup. Repeat lookups of the same home within 24 hours come from our cache and are free. That makes it cheap for Claude to look a home up again rather than rely on an earlier turn. Failed lookups cost nothing, and get_usage is free, so asking for your remaining credits before a large batch is a sensible step.

A live lookup takes typically 8 seconds, up to about 20, and a batch can take longer. If a long list is slow in chat, split it into smaller batches or move the job into a script that writes results to a file you can review.

Turn a good session into a repeatable workflow

A chat is a good place to explore a shortlist and decide which fields matter. Once you know, write the steps down: which links you check, which fields you compare, how you treat missing values, and how old a collection can be before you look it up again. That makes the next session faster and the results easier to audit.

If the same comparison runs every week, a small program is easier to review than a chat transcript. The dashboard and worksheet guides on this blog use the same response fields, so you can move from a Claude session to a saved snapshot without changing your definitions.

Validation scope: the tool names, arguments, error codes and billing rules in this article were checked against the MCP server's published tool definitions and documentation. The session transcript is illustrative and uses placeholders rather than real homes.

Sources and documentation

Product details checked against the linked documentation on October 22, 2026. Code and sample inputs are illustrative unless stated otherwise.

Written by PropertiesAPI, an independent property data service. We are not affiliated with Zillow. Source data may be incomplete or change over time.