Building a Property Research Agent with Claude and Houski MCP: A Builder's Walkthrough
Summary: In March 2026, Anthropic shipped custom Model Context Protocol (MCP) connectors to Claude.ai for Pro, Max, Team, and Enterprise users (Free plans get one custom connector). The Houski MCP server has been live the whole time. This post is the practical, builder-to-builder guide to wiring it up and constructing three real workflows: a Toronto comp finder, a small-landlord due-diligence agent, and an investor market scout. You will get copy-pastable system prompts, sample tool-call traces, cost-control patterns, and notes on extending the same approach to Cursor, Windsurf, and custom GPTs.
The March 2026 Moment
For more than a year, MCP felt like a thing you read about and never used. The protocol was open, the spec was clean, the Claude Desktop demos were cool, but the mainstream Claude.ai web app did not speak it. If you wanted real tool use against your own data, you were either writing direct Anthropic software development kit (SDK) code or running Claude Desktop with a config file most of your team was never going to touch.
That changed in March 2026. Anthropic flipped on custom MCP connectors for Pro, Max, Team, and Enterprise plans inside claude.ai itself (Free plans got a single custom connector slot too). The Houski MCP endpoint at https://www.houski.ca/mcp has been live since the protocol shipped, so we did not have to do anything new. What changed is that any Claude.ai user can now connect to it in about ninety seconds.
So the question is no longer "what is MCP". The question is "what is the smallest useful agent I can build on top of it, and how do I keep it from spending my whole budget in one prompt".
That is what this post is about.
What you can build, in one paragraph
A Claude.ai conversation with the Houski MCP connector enabled has access to twelve tools across the Houski endpoint families. Four of them are metadata tools (field_list, field_detail, search_api_documentation, auth_endpoint) that do not bill per call. The rest are billable. Some are cheap (properties_endpoint, aggregate_endpoint, search_endpoint), one is not (avm_endpoint, five dollars per call). With these, Claude can plan a research task, look up the schema, fetch the data, summarize the result, and surface anything that needs your attention. You stay in the loop on cost.
Step 1 through 5: Connect Houski MCP to Claude.ai
This takes about ninety seconds. You only do it once per workspace.
- Go to claude.ai and sign in. Pro, Max, Team, and Enterprise plans support multiple custom connectors, and Free plans support one.
- Open Settings, then Connectors.
- Click Add custom connector. (If you do not see the option, you may need to flip on developer mode under Settings, Profile.)
- Paste https://www.houski.ca/mcp as the URL. Name it "Houski". Save.
- The first time you call a billable tool, Claude will surface an auth_endpoint flow. Click through it, paste your Houski API key (grab one at /api-documentation/quick-start), done.
You now have a Claude session that knows about Canadian real estate. Open a new chat, ask it "what tools do you have from Houski", and it will list them.
If you are deploying this to a Team or Enterprise workspace, your admin can add the connector at the workspace level so every seat inherits it. That is the right move for an agency or analyst team, otherwise you end up with eight people pasting the URL into eight settings panels.
The shape of a good property research prompt
Default Claude is generalist. To get useful, repeatable work out of it against the Houski MCP, you need a system prompt that does four things:
- Defines the job. Real estate analyst, focused on Canadian properties, working from the Houski API.
- Sets cost rules. Always use field_list first, always pass select, never call avm_endpoint without explicit user confirmation, log cost_cents from every response.
- Sets safety rules. Never act on a guess. If a city is ambiguous, ask. If the user says "the Toronto property", and you have not been told an address, ask.
- Sets output rules. Tables for comps, bullet lists for risks, dollar amounts formatted with thousand separators.
Here is a full system prompt to use as the base for all three workflows below. Drop it into a Claude Project, attach the Houski connector, and you have a reusable analyst.
You are a Canadian real estate research analyst with access to the Houski MCP server. Your job is to answer property questions accurately and cheaply. DATA DISCIPLINE - Before any properties_endpoint or aggregate_endpoint call, use field_list to confirm the field names you need. The schema is large (200+ fields). Do not guess column names. - Always pass `select` with the smallest set of fields that answers the question. Wide queries waste cost and pollute the answer. - Prefer aggregate_endpoint over properties_endpoint when the user asks for a count, average, median, or breakdown. Aggregates are much cheaper than pulling raw rows. - Log the `cost_cents` value from every response in a running tally at the bottom of your reply, formatted as: "Spent so far: $X.XX". SAFETY - Never call avm_endpoint without explicit user confirmation. The AVM costs five dollars per call. Ask first, every time, even if the user said "yes" earlier in the conversation about a different property. - If a city, address, or property identifier is ambiguous, ask before spending. A clarifying question does not cost a tool call. - Treat all score_* fields as higher-is-better. They run 0 to 10. score_flood = 9 means low flood risk. Do not invert. OUTPUT - Comparable listings: Markdown table with address, list price, Houski estimate_sale_price, beds, baths, interior_sq_m, and a calculated price-per-square-metre column based on list price. - Risk summary: bullet list grouped by category (climate, financial, structural, neighbourhood). - Currency: $1,250,000 format, never 1250000 or 1.25M. - Never invent data. If a field is null in the response, say so. - Never claim Houski has recorded sold prices or closing history. Recorded sale prices in Canada are locked behind the Multiple Listing Service (MLS) system and provincial land-titles registries, so they are not in any general-access API. Houski has listings, listing-event history, and model-based estimates (estimate_sale_price). Recorded closings come from the user's own MLS access or a paid land-titles pull. WHEN UNSURE - search_api_documentation, field_list, and field_detail do not bill per call. Use them when you do not know which endpoint or field you need.
That prompt is the foundation. Each of the three workflows below adds a small task-specific layer on top.
Workflow 1: A Toronto comp-finder agent
The job: a user pastes an address, the agent returns a table of comparable recent listings within a defined radius, with both the list price and Houski's model-based estimate_sale_price for each comp. Worth being explicit up front. Recorded sale prices in Canada are locked behind the MLS system and provincial land-titles registries, so no general-access API in this country - including Houski - has them. The "comp" the agent returns is a comparable property that was recently listed, paired with our model's estimated sale price. Users who need recorded closings bring those from their own MLS access or a land-titles pull.
The task layer
Add this on top of the base system prompt, in a Claude Project named "Toronto Comp Finder":
TASK: Given an address in Toronto, return ten comparable recent listings from the last 12 months within 1 km, matching property type and within +/- 25% of bedroom count and interior_sq_m. For each comp include both the list_price and Houski's estimate_sale_price. PROCESS: 1. Resolve the input address to a property_id with search_endpoint. 2. Fetch the subject property with properties_endpoint, selecting only: address, latitude, longitude, property_type, bedroom, bathroom_full, interior_sq_m, construction_year. 3. Use properties_endpoint with a geographic filter to find ten comparable recent listings matching the criteria above. Filter on for_sale_list_date to bound the time window. 4. Return the table. Append a one-paragraph commentary on the spread between list_price and estimate_sale_price, and any outliers.
A real interaction
User: "Find comps for 123 Queen Street West, Toronto."
Claude's plan, abbreviated, with the actual MCP calls inline:
// Step 1: Resolve address to property_id
{
"tool": "search_endpoint",
"input": {
"query": "123 Queen Street West, Toronto, ON",
"max_results": 1
}
}
// Step 2: Fetch subject
{
"tool": "properties_endpoint",
"input": {
"property_id_eq": "<subject_id>",
"select": "address,latitude,longitude,property_type,bedroom,bathroom_full,interior_sq_m,construction_year"
}
}
// Step 3: Comparable listing search
{
"tool": "properties_endpoint",
"input": {
"country_abbreviation": "CA",
"province_abbreviation": "ON",
"city": "Toronto",
"property_type_eq": "Apartment",
"for_sale_list_date_gte": "2025-05-14",
"bedroom_gte": 1,
"bedroom_lte": 3,
"bbox_sw_lat": 43.6401,
"bbox_sw_lng": -79.4011,
"bbox_ne_lat": 43.6581,
"bbox_ne_lng": -79.3787,
"select": "address,list_price,estimate_sale_price,for_sale_list_date,bedroom,bathroom_full,interior_sq_m",
"for_sale_list_date_sort": "desc",
"results_per_page": 10
}
}
Claude then formats the result as a Markdown table, calculates price per square metre in its own head (cheaper than asking the API to compute it), notes any obvious outliers, and prints the running cost tally.
The whole interaction usually lands between four and seven cents in API spend. You can run dozens per day before it adds up to a coffee.
Why this works
Three things make this workflow reliable:
- The resolve-then-fetch-then-compare pattern keeps each call narrow. We never pull two hundred fields when we only need eight.
- The bounding-box filter does the geographic heavy lifting server-side. We never have to pull a wide query and filter client-side.
- The agent has a fixed output shape, so the user gets the same kind of answer every time, and so does any downstream parser if you wire this into an internal tool.
Workflow 2: A multi-property due-diligence agent
The job: a small landlord pastes a list of five to ten addresses they are considering buying. The agent produces a per-property risk and financial summary, then a portfolio-level comparison.
This one is more interesting because the agent is making many calls per address and has to be disciplined or it will burn through your budget.
The task layer
TASK: For a list of property addresses, produce a one-page summary per property covering: - Basic facts (address, type, construction_year, bedroom, bathroom_full, interior_sq_m) - Climate risk (score_flood, score_fire, score_earthquake) - Financial signals (assessment_value, list_price if currently or recently listed, estimate_sale_price, property_taxes, estimate_rent_monthly if available) - Neighbourhood signals (population trend, score_walkability if present) After the per-property pages, produce a single comparison table ranking the properties by a simple weighted score that you compute: 40% financial signal, 30% climate safety, 30% neighbourhood quality. Show your weighting math at the bottom. COST RULES (additional to base): - Batch all property fetches into a single properties_endpoint call using a property_id_in filter. Do NOT call once per address. - Use aggregate_endpoint to get neighbourhood-level population trend rather than pulling raw rows. - Do NOT call avm_endpoint. The user will request that separately on properties they want to dig deeper into.
The batching pattern that matters
The naive version of this agent calls search_endpoint once per address, then properties_endpoint once per resulting property ID. For ten properties, that is twenty calls.
The disciplined version resolves addresses serially (because the inputs are different addresses, search cannot be batched), then makes one properties_endpoint call:
{
"tool": "properties_endpoint",
"input": {
"property_id_in": "id1,id2,id3,id4,id5,id6,id7,id8,id9,id10",
"select": "address,property_type,construction_year,bedroom,bathroom_full,interior_sq_m,assessment_value,list_price,estimate_sale_price,score_flood,score_fire,score_earthquake,community"
}
}
One call returns ten rows. Now the agent has all ten properties in context and can summarize them without further fetching. The per-property writeup is reasoning, not API calls.
For neighbourhood population trend, the agent groups the ten properties by community, then makes one aggregate_endpoint call per unique community. If all ten are in the same community, that is a single aggregate call. If they span four communities, four calls.
A naive version of this workflow can easily hit fifty or sixty cents per ten-property report. The disciplined version lands around twelve to eighteen cents. Same answer, four times cheaper.
Sample output, abbreviated
The agent returns something like this:
## 123 Maple Ave, Calgary, AB - Type: Detached, built 1998 - 4 bed, 3 bath, 199 sq m - Assessed: $685,000 | Estimated sale price: $702,000 | Last list: $689,000 (2024-09-12) - Climate: Flood safety 9 (low risk), Fire safety 7, Earthquake safety 10 - Community: Hidden Valley, population trend +1.2% year over year ## 47 Birch Cres, Calgary, AB - Type: Townhouse, built 2014 ... ## Comparison | Address | Score | Financial | Climate | Neighbourhood | |----------------------|-------|-----------|---------|---------------| | 47 Birch Cres | 0.82 | 0.78 | 0.88 | 0.81 | | 123 Maple Ave | 0.79 | 0.74 | 0.85 | 0.79 | ... Weighting: 0.4 * financial + 0.3 * climate + 0.3 * neighbourhood Spent so far: $0.16
The landlord can then say "give me an AVM on Birch Cres", at which point Claude asks for explicit confirmation, calls avm_endpoint, and adds five dollars to the tally. That escalation pattern is the whole point of the safety rule.
Workflow 3: An investor market scout
The job: an investor wants a weekly rollup of cap rate, vacancy proxies, and population trend across the communities they care about. Same agent runs every Monday morning, same shape of output, just refreshed numbers.
The task layer
TASK: Produce a weekly market scout report for the following communities: <user fills in a list of communities>. For each community, return: - Median list_price across active and recently active listings - Median estimate_sale_price (Houski's model-based estimate) - Estimated cap rate (median annual rent / median estimate_sale_price) - Active listing count - Population trend (last 3 years) - Any score_* aggregates that look notable USE aggregate_endpoint for everything except listing counts. Do NOT pull raw property rows. The whole report should cost under 30 cents regardless of how many communities are in the list. OUTPUT a ranked table from highest to lowest estimated cap rate, plus a one-paragraph commentary calling out the top three opportunities and any community where the population trend has reversed direction.
Why aggregates matter here
If you ask the naive version "what is the median list price in Hidden Valley", it will pull every active listing and compute the median itself. That is a properties_endpoint call returning hundreds of rows, with cost scaling on row count.
The disciplined version uses aggregate_endpoint:
{
"tool": "aggregate_endpoint",
"input": {
"community": "Hidden Valley",
"city": "Calgary",
"for_sale_list_date_gte": "2026-02-14",
"aggregation": "median",
"field": "list_price"
}
}
One call, one row back, cost is a fraction of pulling raw data. For a ten-community weekly report, the whole agent can run for under twenty cents and finish in well under a minute.
This is the workflow where the cost-control discipline pays off most. Run it weekly across the year for a single investor and you are spending maybe ten dollars in API costs to get fifty-two reports.
Cost-control patterns: the rules I burn into every system prompt
After building a few of these I converged on six rules. They are baked into the base system prompt above, but they deserve a section because they apply to every Houski MCP agent you build.
- field_list first, always. It does not bill per call. The schema is two hundred fields wide. Guessing field names wastes a billable call when the field does not exist or is misnamed.
- select everything. Never call properties_endpoint without a select parameter. The default returns a wide row, which costs more and floods Claude's context.
- Aggregate over enumerate. If the user wants a count, average, median, or breakdown, use aggregate_endpoint. Do not pull raw rows and have Claude do math.
- Batch with in filters. Multiple property IDs in one call beats one call per ID, every time.
- Confirm before paid AVM. Five dollars is a lot of money to spend on accident. The safety rule must be in the system prompt, not just the user's hope.
- Log cost_cents. Every response carries it. Surface it. The user should always know what the conversation has cost.
If you skip any of these, the agent still works, just expensively. If you skip all of them, you can rack up fifty dollars in a single research session. Discipline up front saves real money.
Safety patterns: how to keep an agent from doing something dumb
Cost is one form of safety. There are others.
- Address ambiguity. "Find me data on the Maple Ave property" is not a request the agent should fulfill silently. There are seven hundred Maple Avenues in Canada. Force the agent to ask.
- Implicit AVM escalation. Users sometimes phrase a question like "give me a really detailed valuation". That is not consent to spend five dollars. Consent must be explicit and per-call.
- Stale conversation context. If the user said "yes, run AVM on Birch Cres" twenty minutes ago, that does not authorize a new AVM on a different property in the same chat. Re-ask, every time.
- Hallucinated fields. Claude is excellent at confidently inventing field names that sound plausible. Forcing field_list before every fetch defends against this. If a field does not exist, the agent learns that from the schema instead of paying for a failed query.
Treat these the same way you treat input validation in production code. Cheap up front, expensive to bolt on later.
Composability: Claude Projects with Houski plus your own data
Where this gets really interesting is when you combine Houski MCP with another connector inside the same Claude Project. A few patterns worth considering:
- Houski + Google Drive. A real estate lawyer keeps purchase contracts in Drive. The agent reads a contract, extracts the property address, queries Houski for the property record, flags any discrepancy between the assessed value in Houski and the sale price in the contract.
- Houski + Google Sheets. A small landlord maintains a Sheet of properties they own. Weekly cron prompt asks the agent to refresh climate scores and assessed values for every row, and write back to a "last updated" column.
- Houski + GitHub. A property tech startup has its own internal models. Agent fetches a property from Houski, runs the team's internal scoring code in a Code Interpreter sandbox, files a GitHub issue if the score crosses a threshold.
The composition pattern is the same in every case: Houski supplies the canonical Canadian property facts, the other connector supplies the user's private context, the agent does the join in natural language. None of these need a backend. They are all Claude Project configurations.
Limitations and when to fall back to direct API
Be honest with yourself about what MCP-based agents are and are not good for.
Good for:
- Interactive research where a human is in the loop on every prompt.
- One-off due-diligence tasks where each report is bespoke.
- Internal team tools where ten or twenty queries a day is the volume.
- Anything where natural language input is more natural than a form.
Not good for:
- High-volume automated pipelines. If you are doing ten thousand property lookups a day, write a Rust or Python script that calls the Houski API directly. The token cost of running everything through Claude will dwarf the data cost.
- Anything latency-sensitive. Tool use adds round trips. A direct API call is hundreds of milliseconds. A Claude tool-use cycle is several seconds.
- Strict-format outputs feeding another machine. If you need a CSV with exactly these columns in exactly this order, do not ask a large language model (LLM) to produce it. Pull the data directly.
- Anything where context window matters more than reasoning. Claude's context is large but not infinite. If your job needs to look at five thousand properties at once, MCP is the wrong shape.
A useful mental model: MCP is for the analyst sitting at the keyboard. Direct API is for the cron job. They are complementary, not competitive.
Building your own MCP-style integration: notes for other AI clients
The Houski MCP server is a standard streamable Hypertext Transfer Protocol (HTTP) transport at a single address. Any client that speaks MCP can use it, on any protocol revision from the original 2024-11-05 through the current 2026-07-28. Newer clients are served without sessions, so there is no connection state to keep alive, and older clients still get the handshake they expect. A few specifics for common clients:
Cursor. Add to your .cursor/mcp.json (or the global equivalent):
{
"mcpServers": {
"houski": {
"url": "https://www.houski.ca/mcp"
}
}
}
Cursor will surface the Houski tools to whichever model you have selected. Useful when you are writing code that integrates with property data and you want the schema queryable from your editor.
Windsurf. Same idea, similar config file. The Cascade agent will pick up the connector and use it.
Custom GPTs (OpenAI). OpenAI does not natively speak MCP, so Houski cannot be added as a Custom GPT connector directly. The workaround is to write your own thin OpenAPI shim that fronts a few Houski endpoints and import that as a Custom GPT action. Less elegant than native MCP, but it works.
Your own Anthropic SDK app. If you are building a backend agent that uses the Anthropic API directly, you can pass Houski MCP as a remote MCP connector in the request. This is the path for production systems where you want full control over the conversation loop, prompt caching, and so on.
The point is: the Houski MCP server is one piece of infrastructure that backs all of these. You write your prompt and your workflow once, and you can carry it across every client that speaks the protocol.
A copy-pastable Claude Project system prompt
Here is a consolidated system prompt to use as the starting template for any new Houski-backed Claude Project. Copy this into the system prompt field of a new Project, attach the Houski connector, and you are running.
You are a Canadian real estate research analyst with access to the Houski MCP server (https://www.houski.ca/mcp). The user is a property professional who values accuracy and cost-discipline. CAPABILITIES - 19+ million Canadian properties across all provinces and territories - 200+ fields per property: assessment, listings (current and historical via expand_listing_event), structural, climate risk scores, neighbourhood demographics, model-based valuations (estimate_sale_price, estimate_rent_monthly) - No recorded sold-price feed. Recorded sale prices in Canada are locked behind MLS and provincial land-titles registries and are not available to any general-access API. Estimates and listings only. - Tools: properties_endpoint, search_endpoint, aggregate_endpoint, geocoding_endpoint, location_endpoint, predict_endpoint, map_endpoint, avm_endpoint, plus metadata tools (field_list, field_detail, search_api_documentation, auth_endpoint) that do not bill per call DATA DISCIPLINE - field_list before every properties_endpoint or aggregate_endpoint call. The schema is wide. Do not guess field names. - Always pass `select` with the smallest set of fields that answers the question. - Prefer aggregate_endpoint for counts, averages, medians, breakdowns. Do not pull raw rows to compute a single number. - Batch property lookups with `in` filters. One call for ten properties, not ten calls for one property each. COST AND SAFETY - Log cost_cents from every response. Surface the running tally at the bottom of every reply. - avm_endpoint costs five dollars per call. Never call it without explicit user confirmation, even if the user authorized an earlier AVM on a different property. - If a city, address, or property is ambiguous, ask before spending. INTERPRETATION - All score_* fields are higher-is-better and run 0 to 10. score_flood = 9 is low flood risk, not high. - Currency in $1,250,000 format. - Dates as YYYY-MM-DD. - Never invent data. If a field is null, say so explicitly. OUTPUT - Comparable listings: Markdown table with list_price and estimate_sale_price. - Risk summaries: bullet list grouped by category. - Multi-property reports: per-property section followed by a ranked comparison table. - Always end with: "Spent so far: $X.XX" ASK FIRST - Before any AVM call. - Before any query that might return more than 100 rows. - When the user's question is ambiguous about location, time window, or property type.
Drop in a task layer (the comp finder, due-diligence, or market scout examples above) and you have a usable agent in five minutes.
A full example: the comp-finder transcript
To make this concrete, here is what a session with the Toronto comp-finder agent looks like end-to-end. Prompts, tool calls, and the shape of output. The address has been anonymized.
User: Find me comps for 88 Example Street, Toronto.
Claude (internal reasoning, paraphrased): I need to resolve this address to a property_id, fetch the subject property facts, then run a comparable search within one kilometre. Let me start by checking the schema to make sure I have the right field names for the comparable filter.
// Tool call 1: metadata check
{
"tool": "field_list",
"input": {
"search": "list price estimate sale"
}
}
// Returns: list_price, estimate_sale_price, for_sale_list_date,
// expand_listing_date, expand_listing_event, list_price_vs_estimate, ...
// Tool call 2: resolve address
{
"tool": "search_endpoint",
"input": {
"query": "88 Example Street, Toronto, ON",
"max_results": 1
}
}
// Returns: { property_id: "abc123", address: "88 Example St, Toronto ON", ... }
// cost_cents: 1
// Tool call 3: subject fetch
{
"tool": "properties_endpoint",
"input": {
"property_id_eq": "abc123",
"select": "address,latitude,longitude,property_type,bedroom,bathroom_full,interior_sq_m,construction_year"
}
}
// Returns: 1 row with the subject.
// cost_cents: 1
// Tool call 4: comparable listing search
{
"tool": "properties_endpoint",
"input": {
"property_type_eq": "Apartment",
"for_sale_list_date_gte": "2025-05-14",
"bedroom_gte": 1,
"bedroom_lte": 3,
"interior_sq_m_gte": 56,
"interior_sq_m_lte": 93,
"bbox_sw_lat": 43.6442,
"bbox_sw_lng": -79.3944,
"bbox_ne_lat": 43.6622,
"bbox_ne_lng": -79.3720,
"select": "address,list_price,estimate_sale_price,for_sale_list_date,bedroom,bathroom_full,interior_sq_m",
"for_sale_list_date_sort": "desc",
"results_per_page": 10
}
}
// Returns: 10 rows.
// cost_cents: 4
Claude's reply to the user:
Here are the ten most recent comparable apartment listings within 1 km of 88 Example Street, listed in the last 12 months, matching bedroom count and within +/- 25% of interior_sq_m. List_price and Houski's model-based estimate_sale_price shown side by side. | Address | List Price | Est. Sale | Listed | Bd | Ba | Sq m | $/sq m (list) | |---------------|-----------:|----------:|------------|---:|---:|-----:|--------------:| | 12 Sample Ave | $865,000 | $851,000 | 2026-04-22 | 2 | 2 | 79 | $10,949 | | 47 Other St | $792,500 | $810,000 | 2026-03-18 | 2 | 1 | 72 | $11,007 | | 200 Demo Blvd | $920,000 | $895,000 | 2026-02-09 | 2 | 2 | 85 | $10,824 | | ... | ... | ... | ... |...|...| ...| ... | Median list_price: $852,750. Median estimate_sale_price: $851,500. Median price per square metre on list: $10,930. Two outliers worth flagging: 47 Other St was listed at the bottom of the range and removed within ten days (Houski estimate_sale_price sits above the list, suggesting a quick sale at or near ask), and 200 Demo Blvd is listed above the median per square metre, which appears to be driven by a recent renovation reflected in its last permit record. Spent so far: $0.06
That is the whole interaction. Six cents. The user gets a defensible comp set in under thirty seconds, with the agent's reasoning visible the whole way. If they want to dig into one of those comps, they ask, and the agent fetches the deeper record, again with select discipline, again logging the cost.
This is the pattern. Plan, schema-check, geocode, fetch, present, log cost. Repeatable across every workflow you build.
Directions worth exploring next
A few patterns to consider:
- Permit-watch agent. Pulls building permits filed this week in a user's city, summarizes anything notable. Houski has permit data for four Canadian cities (Calgary, Edmonton, Toronto, and Vancouver) already.
- Tax-appeal agent. Compares the user's assessed value to the median assessed value of similar nearby properties, flags candidates for a property tax appeal.
- Insurance underwriting copilot. Pulls climate scores, structural data, and neighbourhood signals for a list of properties and produces an underwriting summary. Pairs nicely with the multi-property due-diligence pattern.
- Listing-aware buyer agent. Combines Houski property facts with a real estate brokerage's private listing feed (via a separate MCP connector) to surface only listings that match a buyer's criteria.
Each of these is essentially the same architecture as the three workflows above: a focused task layer on top of the cost-disciplined base prompt.
Where to start
If you have made it this far, you have everything you need to ship an agent today. The setup is fast, the patterns are simple, and the cost-control rules are the same regardless of what you are building.
Get an API key and the connector URL at /api-documentation/quick-start. The MCP endpoint is https://www.houski.ca/mcp. The metadata tools (field_list, field_detail, search_api_documentation, auth_endpoint) do not bill per call, so once you are subscribed you can explore the schema as much as you want without driving up your usage. Connect it to a Claude Project, paste in the system prompt above, add a task layer, and you have a working analyst.
If you build something useful, we would love to hear about it.
Alex Wilkinson CEO, Houski