Popety.io v1.0.0
Swiss real-estate intelligence
Save this plugin to Following and return to review observed changes. Follow up to 10 plugins free.
From the marketplace listing
Swiss real-estate intelligence: 9 guided workflows (parcel reports, valuations, market analysis, development sourcing) driving the Popety.io connector.
Language: English · Automatically detected from descriptions.
Oct 27, 2026 · 1 saved observations
Metadata · Oct 27, 2026 · 00:46 UTC · Compared with Oct 24, 2026 · 13:31 UTC
Package or technical metadata updated
Observed in package metadata. These changes alone do not establish a new customer-facing feature.
Oct 24, 2026 · 13:31 UTC
Not present
Oct 27, 2026 · 00:46 UTC
false
From the developer’s listing and package; capabilities are not independently tested. Package observed Nov 3, 2026.
Specific limitations have not been established. Missing information does not mean unrestricted capabilities.
Pricing and account requirements have not been established from the available package declarations. Unknown pricing does not mean free access.
A starter prompt has not been provided in the catalog.
From the developer.
---
name: feasibility-snapshot
description: "Assess buildability, zoning and constraints of a Swiss parcel from an address. Use when the user asks about buildability, what can be built on a parcel, zoning check, building constraints, feasibility of a plot."
disable-model-invocation: false
---
<!-- GENERATED FROM api/popety-mcp/src/prompts.ts — do not edit; run pnpm --filter @popety-io/mcp generate:integrations -->
# Feasibility snapshot
Assess buildability, zoning and constraints of a Swiss parcel from an address.
**Arguments to collect from the user:**
- `address` — Full Swiss address including street, number, and municipality. (required)
## Workflow
Assess the buildability and planning constraints of the Swiss parcel at "<address>". Follow these steps exactly:
1. LOCATE THE PARCEL
Call find_land with { by: "address", value: "<address>" }.
Extract the returned land_id (popetyio_land_id).
2. LOAD LAND DETAILS
Call get_land with { land_id: <land_id>, include: ["zoning", "restrictions"] }.
Note: zone name (main_lupa_name), floor-area ratio (ius_authorized), max floors, RDPPF restrictions (forest, flood, archaeological, danger zones), and any servitudes.
3. CONTEXTUAL HAZARDS AND ACCESS
Call get_context_at with { target: { land_id: <land_id> }, topics: ["hazards", "noise", "transport"] }.
Note: flood/avalanche/landslide risk levels, road/rail noise (dB), and transit score.
4. ZONING REGULATIONS
Call search_regulations with { land_id: <land_id> } to retrieve applicable communal and cantonal planning rules for this zone.
5. THE DOCUMENT (blueprint — follow the kit)
- Verdict: can it be developed, and how much — with the capacity MATH shown: authorized floor area (parcel area × IUS/IBUS) vs built today, and the headroom in m² (the land indices carry current-use ratios — use them)
- 4 KPIs: zone + IUS · capacity headroom m² · under-exploited score (gauge) · hazard level
- "Zoning & rules": zone card with max floors/height/dwellings and the cited regulation articles (document + article + page) — the citations ARE the value
- "Constraints": RDPPF restrictions and hazard/noise levels as badges (good/warn/danger), each with its one-line implication
- "Access & context": transit and noise in one strip
Analyst paragraphs: what materially limits the potential and what to verify next (servitudes, PPE constitution, neighbour oppositions).
PRESENTATION — how to write the final answer (applies to every step above):
- The answer is a client-ready document that will be shared as-is. Not a chat log, not an analysis diary.
- Open with a title line (subject + commune + date) and a one-line verdict a reader would pay for. Never open with method, tool narration, or what you are about to do.
- The reader is a real-estate professional (broker, investor, developer). Every section closes with ONE analyst paragraph stating the professional implication — pricing, absorption, sourcing, underwriting — never a definition or a tutorial sentence. Show sample sizes and visibly de-emphasise figures resting on fewer than 3 observations.
- 3–6 titled sections, ordered by what matters most to the reader; one idea per section. Prefer short prose with embedded figures; use a table only when comparing 3+ items across 2+ dimensions, max ~6 rows, one comparison per table. Select the figures that change the reader's decision — do not dump every number you retrieved.
- Swiss formats: CHF 1'250'000 (apostrophe thousands), m², CHF/m²; official Swiss real-estate terminology in the reader's language. Write the whole document in the language the user wrote in.
- Caveats: at most ONE short "Notes" line at the end of the document (e.g. coverage gaps, asking ≠ realised prices). Never inline a disclaimer after a figure. Never mention tools, credits, section ids, API mechanics, or observations "for the platform team" inside the document — if you have a genuine data/product observation, put it after the document under a separate "---" divider, in one or two lines.
- Close the document with at most ONE "Next step" line offering the single most relevant follow-up — an offer, not a menu.
- In clients that support artifacts/canvas, render the document as a styled artifact (clean typography, generous spacing, no emojis) and keep the chat reply to a two-line summary; otherwise use clean markdown with real headings.
---
Requires the Popety connector (bundled with this plugin — authenticate on first use). Follow the workflow's cost gates: free/preview steps before any paid call.
## Building the document
When the client supports artifacts, render the final document as a plain HTML artifact (NEVER React/JSX — a JSX rewrite loses the stylesheet) built from `references/popety-kit.html` (bundled with this skill): read the kit FIRST, paste its ENTIRE <style> block verbatim as the stylesheet (never write your own CSS), give every SVG mark its literal hex fill/stroke attribute PLUS the kit mark class (mk1-mk4, mkband, mktick, mkline), and follow its primitives, helpers and rules — Popety brand in both themes, Swiss number formats, inline-SVG charts with tooltips, one analyst paragraph per section written for a real-estate professional. The finished document must visibly carry the Popety cyan (brandbar, kicker, verdict block, KPI accents, chart fills) — a grey/monochrome document means the kit was not applied. Without artifact support, apply the same structure in clean markdown.
Referenced files: 1 — file references are metadata, not package contents.
---
name: find-development-sites
description: "Hunt under-exploited parcels with development potential in a commune or canton. Use when the user asks about development potential, under-exploited parcels, site sourcing, densification opportunities."
disable-model-invocation: false
---
<!-- GENERATED FROM api/popety-mcp/src/prompts.ts — do not edit; run pnpm --filter @popety-io/mcp generate:integrations -->
# Find development sites
Hunt under-exploited parcels with development potential in a commune or canton.
**Arguments to collect from the user:**
- `location` — Commune (municipality) name, e.g. "Pully", or a 2-letter canton code, e.g. "VD". (required)
- `min_area_m2` — Minimum parcel area in m² (optional). (optional)
## Workflow
Find under-exploited parcels with development potential in <commune or canton>. Follow these steps exactly:
1. PREVIEW THE SEARCH (free)
Call search_entities with:
{ entity_type: "lands", filters: { municipality: "<commune or canton>", under_exploited_score_min: 60, no_building_zone: "hide" },
sort: "under_exploited_score_desc", preview: true, limit: 10 }
(no_building_zone: "hide" keeps only constructible parcels — never shortlist land in a no-building zone. Preview with the SAME limit you will commit with: object_count/cost are quoted at that limit, matching_total is the full count.)
Note the object_count and cost — this search bills per returned object.
2. RUN THE FULL SEARCH
Repeat the same call without preview, passing the query_id from step 1 and limit: 10.
Extract per parcel: land_id, code_number, municipality, area, under_exploited_score, development_score.
3. CHECK ZONING HEADROOM FOR THE TOP 3
For the 3 highest-scoring parcels, call get_land with { land_id: <land_id>, include: ["zoning"] }.
Note: zone name (main_lupa_name), authorized IUS (ius_authorized) vs what is currently built — the gap is the densification headroom.
4. THE DOCUMENT (blueprint — follow the kit)
Ranked parcel CARDS (kit card primitive): per parcel code_number + land_id, commune, area m², the two scores as GAUGES (under-exploited, development), zone + IUS, and one line on WHY it is under-exploited (built density vs authorized IUS — estimate the headroom in m² where the indices allow). Open with a verdict naming the one or two credible targets and why the rest rank lower.
Notes-line material: under-exploited and development scores are Popety proprietary indicators, not building permits. Next step: run the feasibility_snapshot prompt on the best candidate to check zoning rules, restrictions, and hazards before acting.
PRESENTATION — how to write the final answer (applies to every step above):
- The answer is a client-ready document that will be shared as-is. Not a chat log, not an analysis diary.
- Open with a title line (subject + commune + date) and a one-line verdict a reader would pay for. Never open with method, tool narration, or what you are about to do.
- The reader is a real-estate professional (broker, investor, developer). Every section closes with ONE analyst paragraph stating the professional implication — pricing, absorption, sourcing, underwriting — never a definition or a tutorial sentence. Show sample sizes and visibly de-emphasise figures resting on fewer than 3 observations.
- 3–6 titled sections, ordered by what matters most to the reader; one idea per section. Prefer short prose with embedded figures; use a table only when comparing 3+ items across 2+ dimensions, max ~6 rows, one comparison per table. Select the figures that change the reader's decision — do not dump every number you retrieved.
- Swiss formats: CHF 1'250'000 (apostrophe thousands), m², CHF/m²; official Swiss real-estate terminology in the reader's language. Write the whole document in the language the user wrote in.
- Caveats: at most ONE short "Notes" line at the end of the document (e.g. coverage gaps, asking ≠ realised prices). Never inline a disclaimer after a figure. Never mention tools, credits, section ids, API mechanics, or observations "for the platform team" inside the document — if you have a genuine data/product observation, put it after the document under a separate "---" divider, in one or two lines.
- Close the document with at most ONE "Next step" line offering the single most relevant follow-up — an offer, not a menu.
- In clients that support artifacts/canvas, render the document as a styled artifact (clean typography, generous spacing, no emojis) and keep the chat reply to a two-line summary; otherwise use clean markdown with real headings.
---
Requires the Popety connector (bundled with this plugin — authenticate on first use). Follow the workflow's cost gates: free/preview steps before any paid call.
## Building the document
When the client supports artifacts, render the final document as a plain HTML artifact (NEVER React/JSX — a JSX rewrite loses the stylesheet) built from `references/popety-kit.html` (bundled with this skill): read the kit FIRST, paste its ENTIRE <style> block verbatim as the stylesheet (never write your own CSS), give every SVG mark its literal hex fill/stroke attribute PLUS the kit mark class (mk1-mk4, mkband, mktick, mkline), and follow its primitives, helpers and rules — Popety brand in both themes, Swiss number formats, inline-SVG charts with tooltips, one analyst paragraph per section written for a real-estate professional. The finished document must visibly carry the Popety cyan (brandbar, kicker, verdict block, KPI accents, chart fills) — a grey/monochrome document means the kit was not applied. Without artifact support, apply the same structure in clean markdown.
Referenced files: 1 — file references are metadata, not package contents.
---
name: investment-yield
description: "Gross-yield check: AVM purchase and rent estimates vs current asking rents. Use when the user asks about rental yield, gross yield, buy-to-let return, investment return on a property."
disable-model-invocation: false
---
<!-- GENERATED FROM api/popety-mcp/src/prompts.ts — do not edit; run pnpm --filter @popety-io/mcp generate:integrations -->
# Investment yield
Gross-yield check: AVM purchase and rent estimates vs current asking rents.
**Arguments to collect from the user:**
- `address` — Full Swiss address of the property. Supply at least one of address or building_id. (optional)
- `building_id` — Popety building identifier. Supply at least one of address or building_id. (optional)
## Workflow
Assess the gross rental yield of the Swiss property at "<address>". Follow these steps exactly:
1. RESOLVE THE PROPERTY (free)
Call estimate_property with { address: "<address>" } (no confirm flag).
This returns the register facts and the unit attributes still required: living_area, rooms_nb, bathroom_nb — plus construction_year when the register has no building year.
2. CONFIRM ATTRIBUTES WITH THE USER
Ask the user for EVERY attribute listed in required_attributes (or confirm the returned suggestion for single-dwelling buildings). NEVER guess or invent them.
3. RUN THE VALUATION (paid, 3 credits)
Call estimate_property again with the same target plus { confirm: true, property_attributes: { living_area, rooms_nb, bathroom_nb, construction_year (if required) } }.
Extract: estimated purchase price, estimated monthly rent, and the gross yield band yield_pct_lower / yield_pct_upper.
4. MARKET-RENT CONTEXT (0.50 credits)
Call entity_stats with { entity_type: "listings", filters: { municipality: <municipality>, deal_type: "rent" }, section: "city_analysis" }.
(Sections take NO active/date/rooms filters — deal_type is required.) Read the city's monthly rent per m² stats and percentile fan and compare the model rent per m² to them. Figures span the full listing history, 2% trimmed.
5. THE DOCUMENT (blueprint — follow the kit)
- Verdict + yield card: gross yield as a RANGE VISUAL (<yield_pct_lower>% – <yield_pct_upper>%, kit band primitive) with the commune's implied asking yield marked for comparison
- "Rent check": model rent vs current asking rents per m² in the commune (duo cards)
- A small sensitivity line: yield at rent −10% / model / +10% — computed, labelled as scenarios
- Verdict paragraph: above or below the local asking picture, and what would have to be true to hit the upper bound
Notes-line material: asking rents ≠ realised rents; the yield is GROSS — it ignores charges, vacancy, maintenance, and taxes; this is an AI estimate, not investment advice or a formal appraisal.
PRESENTATION — how to write the final answer (applies to every step above):
- The answer is a client-ready document that will be shared as-is. Not a chat log, not an analysis diary.
- Open with a title line (subject + commune + date) and a one-line verdict a reader would pay for. Never open with method, tool narration, or what you are about to do.
- The reader is a real-estate professional (broker, investor, developer). Every section closes with ONE analyst paragraph stating the professional implication — pricing, absorption, sourcing, underwriting — never a definition or a tutorial sentence. Show sample sizes and visibly de-emphasise figures resting on fewer than 3 observations.
- 3–6 titled sections, ordered by what matters most to the reader; one idea per section. Prefer short prose with embedded figures; use a table only when comparing 3+ items across 2+ dimensions, max ~6 rows, one comparison per table. Select the figures that change the reader's decision — do not dump every number you retrieved.
- Swiss formats: CHF 1'250'000 (apostrophe thousands), m², CHF/m²; official Swiss real-estate terminology in the reader's language. Write the whole document in the language the user wrote in.
- Caveats: at most ONE short "Notes" line at the end of the document (e.g. coverage gaps, asking ≠ realised prices). Never inline a disclaimer after a figure. Never mention tools, credits, section ids, API mechanics, or observations "for the platform team" inside the document — if you have a genuine data/product observation, put it after the document under a separate "---" divider, in one or two lines.
- Close the document with at most ONE "Next step" line offering the single most relevant follow-up — an offer, not a menu.
- In clients that support artifacts/canvas, render the document as a styled artifact (clean typography, generous spacing, no emojis) and keep the chat reply to a two-line summary; otherwise use clean markdown with real headings.
---
Requires the Popety connector (bundled with this plugin — authenticate on first use). Follow the workflow's cost gates: free/preview steps before any paid call.
## Building the document
When the client supports artifacts, render the final document as a plain HTML artifact (NEVER React/JSX — a JSX rewrite loses the stylesheet) built from `references/popety-kit.html` (bundled with this skill): read the kit FIRST, paste its ENTIRE <style> block verbatim as the stylesheet (never write your own CSS), give every SVG mark its literal hex fill/stroke attribute PLUS the kit mark class (mk1-mk4, mkband, mktick, mkline), and follow its primitives, helpers and rules — Popety brand in both themes, Swiss number formats, inline-SVG charts with tooltips, one analyst paragraph per section written for a real-estate professional. The finished document must visibly carry the Popety cyan (brandbar, kicker, verdict block, KPI accents, chart fills) — a grey/monochrome document means the kit was not applied. Without artifact support, apply the same structure in clean markdown.
Referenced files: 1 — file references are metadata, not package contents.
---
name: listing-hunter
description: "Find active listings matching a client brief and build a shortlist. Use when the user asks about find listings, property search, homes or apartments for sale or rent, client shortlist."
disable-model-invocation: false
---
<!-- GENERATED FROM api/popety-mcp/src/prompts.ts — do not edit; run pnpm --filter @popety-io/mcp generate:integrations -->
# Listing hunter
Find active listings matching a client brief and build a shortlist.
**Arguments to collect from the user:**
- `location` — Commune (municipality) name, e.g. "Nyon". (required)
- `deal_type` — "sale" or "rent". Defaults to "sale". (optional)
- `budget_max_chf` — Maximum price in CHF (optional). (optional)
- `rooms_min` — Minimum number of rooms (optional). (optional)
- `property_type` — One of: apartment, house, commercial, land, parking (optional). (optional)
## Workflow
Shortlist current on-market sale listings in <municipality> for a client. Follow these steps exactly:
1. BUILD THE FILTERS
Call search_entities with:
{ entity_type: "listings", filters: { area: { municipality: "<municipality>" },
transaction_type: "sale", active: true } }
ALWAYS keep active: true — the client wants current inventory, not the ~8M historical listings.
2. PREVIEW FIRST (free)
Run the call above with preview: true. This search bills per returned object — if object_count is large, tighten the filters (budget, rooms_min, living_area_min_m2) BEFORE the paid call.
3. RUN THE FULL SEARCH
Repeat the call without preview, passing the query_id from step 2, sort: "listing_timestamp_desc", and limit: 10.
4. THE DOCUMENT
Structure the shortlist document as:
- Title + a one-line recap of the brief (location, deal type, budget, rooms).
- Shortlist as PHOTO CARDS (kit card primitive): the listing's first image (urls_image[0]), price bold, then rooms · m² · CHF/m² · bedrooms and parking where present · listing age — and the portal link (portals[].url) as "View on <portal>". Client briefs are often written in bedrooms: match against bedrooms when present but NEVER exclude listings missing it (coverage ~1 in 3; absence = unknown, not zero).
- Standouts: the best fits and why, flagging listings priced above the commune's asking median — optionally cross-check with entity_stats { entity_type: "listings", filters: { municipality: "<municipality>", deal_type: "sale" }, section: "price_per_room" } (0.50 credits) and compare each listing to the median of its room band (section figures span the full listing history, not only active ads).
- Next-step line: offer the neighborhood_profile prompt on a favourite or the value_estimate prompt to sanity-check an asking price — whichever fits the brief.
Notes-line material: results are advertised listings — availability changes fast; verify with the lister before presenting to the client.
PRESENTATION — how to write the final answer (applies to every step above):
- The answer is a client-ready document that will be shared as-is. Not a chat log, not an analysis diary.
- Open with a title line (subject + commune + date) and a one-line verdict a reader would pay for. Never open with method, tool narration, or what you are about to do.
- The reader is a real-estate professional (broker, investor, developer). Every section closes with ONE analyst paragraph stating the professional implication — pricing, absorption, sourcing, underwriting — never a definition or a tutorial sentence. Show sample sizes and visibly de-emphasise figures resting on fewer than 3 observations.
- 3–6 titled sections, ordered by what matters most to the reader; one idea per section. Prefer short prose with embedded figures; use a table only when comparing 3+ items across 2+ dimensions, max ~6 rows, one comparison per table. Select the figures that change the reader's decision — do not dump every number you retrieved.
- Swiss formats: CHF 1'250'000 (apostrophe thousands), m², CHF/m²; official Swiss real-estate terminology in the reader's language. Write the whole document in the language the user wrote in.
- Caveats: at most ONE short "Notes" line at the end of the document (e.g. coverage gaps, asking ≠ realised prices). Never inline a disclaimer after a figure. Never mention tools, credits, section ids, API mechanics, or observations "for the platform team" inside the document — if you have a genuine data/product observation, put it after the document under a separate "---" divider, in one or two lines.
- Close the document with at most ONE "Next step" line offering the single most relevant follow-up — an offer, not a menu.
- In clients that support artifacts/canvas, render the document as a styled artifact (clean typography, generous spacing, no emojis) and keep the chat reply to a two-line summary; otherwise use clean markdown with real headings.
---
Requires the Popety connector (bundled with this plugin — authenticate on first use). Follow the workflow's cost gates: free/preview steps before any paid call.
## Building the document
When the client supports artifacts, render the final document as a plain HTML artifact (NEVER React/JSX — a JSX rewrite loses the stylesheet) built from `references/popety-kit.html` (bundled with this skill): read the kit FIRST, paste its ENTIRE <style> block verbatim as the stylesheet (never write your own CSS), give every SVG mark its literal hex fill/stroke attribute PLUS the kit mark class (mk1-mk4, mkband, mktick, mkline), and follow its primitives, helpers and rules — Popety brand in both themes, Swiss number formats, inline-SVG charts with tooltips, one analyst paragraph per section written for a real-estate professional. The finished document must visibly carry the Popety cyan (brandbar, kicker, verdict block, KPI accents, chart fills) — a grey/monochrome document means the kit was not applied. Without artifact support, apply the same structure in clean markdown.
Referenced files: 1 — file references are metadata, not package contents.
---
name: neighborhood-profile
description: "Demographics, taxes, transport, noise and hazards around an address. Use when the user asks about neighborhood quality, livability, taxes, noise, transport, natural hazards around an address."
disable-model-invocation: false
---
<!-- GENERATED FROM api/popety-mcp/src/prompts.ts — do not edit; run pnpm --filter @popety-io/mcp generate:integrations -->
# Neighborhood profile
Demographics, taxes, transport, noise and hazards around an address.
**Arguments to collect from the user:**
- `address` — Full Swiss address including street, number, and municipality. (required)
## Workflow
Build a livability and investment-context profile for the neighborhood around "<address>". Follow these steps exactly:
1. LOCATE THE PARCEL
Call find_land with { by: "address", value: "<address>" }.
Extract the returned land_id (popetyio_land_id).
2. LOAD ALL CONTEXT TOPICS (one call, 1 credit)
Call get_context_at with:
{ target: { land_id: <land_id> }, topics: ["demographics", "employment", "taxes",
"transport", "noise", "hazards", "electricity", "accessibility"] }
3. WHAT IS ACTUALLY NEARBY (one call, 1 credit)
Call pois_nearby with the parcel coordinates from step 1's response:
{ lat: <lat>, lon: <lon> }
Summary mode returns nine scored amenity categories (schools, shops, transit, health, …) with the nearest examples.
4. THE DOCUMENT (blueprint — follow the kit)
- Verdict + 4 KPIs: transit score · noise dB · communal tax multiplier · the strongest amenity score
- Amenity categories as a scored bar list (pois_nearby), each with its nearest concrete example; hazards as badges (good/warn/danger)
Themes to cover (group related ones into sections):
- People: population, median income, average household size (demographics)
- Economy: employment figures (employment)
- Taxes: communal tax multiplier (taxes)
- Getting around: transit score and walk score (transport, accessibility)
- Quiet or noisy: road/rail noise in dB (noise)
- Risks: flood/landslide/avalanche hazard levels (hazards)
- Running costs: electricity tariff (electricity)
- Daily life nearby: strongest and weakest amenity categories with the nearest concrete examples (pois_nearby)
The verdict is the livability / investment-context call, grounded ONLY in the returned data. Notes-line material: any topic that came back empty — flag it rather than guessing.
PRESENTATION — how to write the final answer (applies to every step above):
- The answer is a client-ready document that will be shared as-is. Not a chat log, not an analysis diary.
- Open with a title line (subject + commune + date) and a one-line verdict a reader would pay for. Never open with method, tool narration, or what you are about to do.
- The reader is a real-estate professional (broker, investor, developer). Every section closes with ONE analyst paragraph stating the professional implication — pricing, absorption, sourcing, underwriting — never a definition or a tutorial sentence. Show sample sizes and visibly de-emphasise figures resting on fewer than 3 observations.
- 3–6 titled sections, ordered by what matters most to the reader; one idea per section. Prefer short prose with embedded figures; use a table only when comparing 3+ items across 2+ dimensions, max ~6 rows, one comparison per table. Select the figures that change the reader's decision — do not dump every number you retrieved.
- Swiss formats: CHF 1'250'000 (apostrophe thousands), m², CHF/m²; official Swiss real-estate terminology in the reader's language. Write the whole document in the language the user wrote in.
- Caveats: at most ONE short "Notes" line at the end of the document (e.g. coverage gaps, asking ≠ realised prices). Never inline a disclaimer after a figure. Never mention tools, credits, section ids, API mechanics, or observations "for the platform team" inside the document — if you have a genuine data/product observation, put it after the document under a separate "---" divider, in one or two lines.
- Close the document with at most ONE "Next step" line offering the single most relevant follow-up — an offer, not a menu.
- In clients that support artifacts/canvas, render the document as a styled artifact (clean typography, generous spacing, no emojis) and keep the chat reply to a two-line summary; otherwise use clean markdown with real headings.
---
Requires the Popety connector (bundled with this plugin — authenticate on first use). Follow the workflow's cost gates: free/preview steps before any paid call.
## Building the document
When the client supports artifacts, render the final document as a plain HTML artifact (NEVER React/JSX — a JSX rewrite loses the stylesheet) built from `references/popety-kit.html` (bundled with this skill): read the kit FIRST, paste its ENTIRE <style> block verbatim as the stylesheet (never write your own CSS), give every SVG mark its literal hex fill/stroke attribute PLUS the kit mark class (mk1-mk4, mkband, mktick, mkline), and follow its primitives, helpers and rules — Popety brand in both themes, Swiss number formats, inline-SVG charts with tooltips, one analyst paragraph per section written for a real-estate professional. The finished document must visibly carry the Popety cyan (brandbar, kicker, verdict block, KPI accents, chart fills) — a grey/monochrome document means the kit was not applied. Without artifact support, apply the same structure in clean markdown.
Referenced files: 1 — file references are metadata, not package contents.
---
name: parcel-report
description: "Full dossier for a parcel: zoning, restrictions, buildings, history and context. Use when the user asks about parcel dossier, land-registry extract, cadastre details, plot information, parcel summary."
disable-model-invocation: false
---
<!-- GENERATED FROM api/popety-mcp/src/prompts.ts — do not edit; run pnpm --filter @popety-io/mcp generate:integrations -->
# Parcel report
Full dossier for a parcel: zoning, restrictions, buildings, history and context.
**Arguments to collect from the user:**
- `address` — Full Swiss address. Supply at least one of address or land_id. (optional)
- `land_id` — Popety land identifier (popetyio_land_id). Supply at least one of address or land_id. (optional)
## Workflow
Generate a concise land-registry report for the Swiss parcel at "<address>". Follow these steps exactly:
1. RESOLVE PARCEL
Call find_land with { by: "address", value: "<address>" }.
Extract the returned land_id (popetyio_land_id).
2. LOAD ALL LAND DATA
Call get_land with { land_id: "<land_id from step 1>", include: "all" }.
This returns: cadastral area, zoning, owners, restrictions, recent permits, and recent transactions on this parcel.
The response's _omitted_sections lists the large market annexes (purchase_market, rental_market) that are NOT included by default — mention their availability in the report and fetch one explicitly (include: ["purchase_market"]) only if the user asks for market depth.
3. THE DOCUMENT (blueprint — follow the kit)
A dossier, not a data dump:
- ID card: EGRID, parcel number (code_number), commune, cadastral area — plus the official extract links (RDPPF / land register)
- "Zoning": zone name + IUS/COS ceilings vs CURRENT use ratios — show the capacity headroom in m² when under-exploited, with the score as a gauge
- "Owners": count + type (private/public/institutional) and the last register event in one line
- "Restrictions & hazards": RDPPF entries as badges; state explicitly that natural hazards are a separate register and summarise them too
- "Buildings": table of the parcel's buildings (EGID, type, year, footprint, heating) — mention roof solar potential where the building record carries it
- "History": last permits and transactions with dates; state coverage starts honestly
4. NEXT STEP
Next-step candidates: value this property (/popety:value-estimate) or market conditions for the commune (/popety:purchase-market-overview) — offer the more relevant one, never run it automatically.
PRESENTATION — how to write the final answer (applies to every step above):
- The answer is a client-ready document that will be shared as-is. Not a chat log, not an analysis diary.
- Open with a title line (subject + commune + date) and a one-line verdict a reader would pay for. Never open with method, tool narration, or what you are about to do.
- The reader is a real-estate professional (broker, investor, developer). Every section closes with ONE analyst paragraph stating the professional implication — pricing, absorption, sourcing, underwriting — never a definition or a tutorial sentence. Show sample sizes and visibly de-emphasise figures resting on fewer than 3 observations.
- 3–6 titled sections, ordered by what matters most to the reader; one idea per section. Prefer short prose with embedded figures; use a table only when comparing 3+ items across 2+ dimensions, max ~6 rows, one comparison per table. Select the figures that change the reader's decision — do not dump every number you retrieved.
- Swiss formats: CHF 1'250'000 (apostrophe thousands), m², CHF/m²; official Swiss real-estate terminology in the reader's language. Write the whole document in the language the user wrote in.
- Caveats: at most ONE short "Notes" line at the end of the document (e.g. coverage gaps, asking ≠ realised prices). Never inline a disclaimer after a figure. Never mention tools, credits, section ids, API mechanics, or observations "for the platform team" inside the document — if you have a genuine data/product observation, put it after the document under a separate "---" divider, in one or two lines.
- Close the document with at most ONE "Next step" line offering the single most relevant follow-up — an offer, not a menu.
- In clients that support artifacts/canvas, render the document as a styled artifact (clean typography, generous spacing, no emojis) and keep the chat reply to a two-line summary; otherwise use clean markdown with real headings.
---
Requires the Popety connector (bundled with this plugin — authenticate on first use). Follow the workflow's cost gates: free/preview steps before any paid call.
## Building the document
When the client supports artifacts, render the final document as a plain HTML artifact (NEVER React/JSX — a JSX rewrite loses the stylesheet) built from `references/popety-kit.html` (bundled with this skill): read the kit FIRST, paste its ENTIRE <style> block verbatim as the stylesheet (never write your own CSS), give every SVG mark its literal hex fill/stroke attribute PLUS the kit mark class (mk1-mk4, mkband, mktick, mkline), and follow its primitives, helpers and rules — Popety brand in both themes, Swiss number formats, inline-SVG charts with tooltips, one analyst paragraph per section written for a real-estate professional. The finished document must visibly carry the Popety cyan (brandbar, kicker, verdict block, KPI accents, chart fills) — a grey/monochrome document means the kit was not applied. Without artifact support, apply the same structure in clean markdown.
Referenced files: 1 — file references are metadata, not package contents.
---
name: purchase-market-overview
description: "Asking sale prices per m²: distribution, per-type medians and multi-year trend for a Swiss commune. Use when the user asks about sale prices, asking prices, purchase market, price per m2 or price trends in a commune."
disable-model-invocation: false
---
<!-- GENERATED FROM api/popety-mcp/src/prompts.ts — do not edit; run pnpm --filter @popety-io/mcp generate:integrations -->
# Purchase market overview
Asking sale prices per m²: distribution, per-type medians and multi-year trend for a Swiss commune.
**Arguments to collect from the user:**
- `municipality` — Municipality name, e.g. "Lausanne" or "Zürich". (required)
## Workflow
Produce the purchase-market document for <municipality>, from live listings. entity_stats on listings is SECTION-based (0.50 credits per call; the 5 section calls = 2.50 credits, plus a per-object pull for the surface analysis). Listings section filters accept ONLY municipality / district / canton / postal_code / bbox + property_type (an ARRAY) + deal_type ("sale" | "rent", REQUIRED) + date_from / date_to (ISO with T+Z) + active (boolean) — no rooms/price filters. active: true = the CURRENT asking market; if a section returns too few listings for a small commune, retry without active but with date_from 12 months back. Follow these steps exactly:
1. HEADLINE LEVELS (0.50 cr)
Call entity_stats with:
{ entity_type: "listings", filters: { municipality: "<municipality>", deal_type: "sale", active: true },
section: "city_analysis" }
Extract: median/avg price per m², the p5–p95 fan, and the per-property-type medians (apartments vs houses) for the KPI row.
2. PRICE BY ROOMS — BOTH UNITS (2 calls, 1.00 cr)
Call entity_stats twice with { municipality: "<municipality>", deal_type: "sale", active: true }:
once with section: "price_per_room" (total CHF) and once with section: "price_m2_per_room" (CHF/m²).
3. PRICE TREND (0.50 cr)
Call entity_stats with:
{ entity_type: "listings", filters: { municipality: "<municipality>", deal_type: "sale", property_type: ["apartment"] },
section: "price_m2_evolution" }
Quarterly median asking price/m²; identify the peak quarter and the 12-month change.
4. TIME TO SELL (0.50 cr)
Call entity_stats with:
{ entity_type: "listings", filters: { municipality: "<municipality>", deal_type: "sale", date_from: "<12 months ago, ISO with T+Z>" },
section: "distribution" }
Read time_on_market (share sold within 30/60/90/120 days, the average) and construction_year (average build year, max = off-plan deliveries) for the KPI row.
5. SURFACE ANALYSIS (recommended — per-object cost, preview first)
search_entities listings { area: { municipality: "<municipality>" }, transaction_type: "sale", active: true } with preview: true FIRST (typically ~100–150 ads ≈ 5–8 credits; skip if the user is cost-sensitive); then compute the median asking price per surface band AND per rooms × surface cell (apartments).
6. THE DOCUMENT (blueprint — follow the kit)
- Verdict + 4 KPIs: median CHF/m² · 12-month change · average days to sell · average build year of the offer (note off-plan deliveries when max year is ahead)
- "Price by rooms": band chart (p30–p70 + median tick) with a CHF ↔ CHF/m² unit toggle; name where the m² premium sits and warn that thin bands price on comps
- "Price by living area": bar ladder of median price per surface band (if step 5 ran); the analyst paragraph reads where the offer stacks and where it is shallow
- "Where rooms and surface meet": heatmap of median asking price per cell (if step 5 ran), fading cells under 3 ads; name the liquid pockets and the scarce ones
- "Price trend": quarterly line since ~2020, peak annotated, last quarter emphasised, apartments vs houses medians in the caption
- "How fast homes sell": DOM bands with % labels; analyst paragraph linking the slow tail to over-anchored pricing — the listing-pitch argument
Notes-line: asking prices, not realised; Vaud-style non-disclosure where relevant; thin bands. Next step: /popety:investment-yield for a specific property, or /popety:find-development-sites to source parcels — offer the more relevant one.
PRESENTATION — how to write the final answer (applies to every step above):
- The answer is a client-ready document that will be shared as-is. Not a chat log, not an analysis diary.
- Open with a title line (subject + commune + date) and a one-line verdict a reader would pay for. Never open with method, tool narration, or what you are about to do.
- The reader is a real-estate professional (broker, investor, developer). Every section closes with ONE analyst paragraph stating the professional implication — pricing, absorption, sourcing, underwriting — never a definition or a tutorial sentence. Show sample sizes and visibly de-emphasise figures resting on fewer than 3 observations.
- 3–6 titled sections, ordered by what matters most to the reader; one idea per section. Prefer short prose with embedded figures; use a table only when comparing 3+ items across 2+ dimensions, max ~6 rows, one comparison per table. Select the figures that change the reader's decision — do not dump every number you retrieved.
- Swiss formats: CHF 1'250'000 (apostrophe thousands), m², CHF/m²; official Swiss real-estate terminology in the reader's language. Write the whole document in the language the user wrote in.
- Caveats: at most ONE short "Notes" line at the end of the document (e.g. coverage gaps, asking ≠ realised prices). Never inline a disclaimer after a figure. Never mention tools, credits, section ids, API mechanics, or observations "for the platform team" inside the document — if you have a genuine data/product observation, put it after the document under a separate "---" divider, in one or two lines.
- Close the document with at most ONE "Next step" line offering the single most relevant follow-up — an offer, not a menu.
- In clients that support artifacts/canvas, render the document as a styled artifact (clean typography, generous spacing, no emojis) and keep the chat reply to a two-line summary; otherwise use clean markdown with real headings.
---
Requires the Popety connector (bundled with this plugin — authenticate on first use). Follow the workflow's cost gates: free/preview steps before any paid call.
## Building the document
When the client supports artifacts, render the final document as a plain HTML artifact (NEVER React/JSX — a JSX rewrite loses the stylesheet) built from `references/popety-kit.html` (bundled with this skill): read the kit FIRST, paste its ENTIRE <style> block verbatim as the stylesheet (never write your own CSS), give every SVG mark its literal hex fill/stroke attribute PLUS the kit mark class (mk1-mk4, mkband, mktick, mkline), and follow its primitives, helpers and rules — Popety brand in both themes, Swiss number formats, inline-SVG charts with tooltips, one analyst paragraph per section written for a real-estate professional. The finished document must visibly carry the Popety cyan (brandbar, kicker, verdict block, KPI accents, chart fills) — a grey/monochrome document means the kit was not applied. Without artifact support, apply the same structure in clean markdown.
Referenced files: 1 — file references are metadata, not package contents.
---
name: rental-market-overview
description: "Asking rents by rooms and per m², rent trend and inventory mix for a Swiss commune. Use when the user asks about rents, asking rents, rental market, rent levels or rent trends in a commune."
disable-model-invocation: false
---
<!-- GENERATED FROM api/popety-mcp/src/prompts.ts — do not edit; run pnpm --filter @popety-io/mcp generate:integrations -->
# Rental market overview
Asking rents by rooms and per m², rent trend and inventory mix for a Swiss commune.
**Arguments to collect from the user:**
- `municipality` — Municipality name, e.g. "Lausanne" or "Zürich". (required)
## Workflow
Produce the rental-market document for <municipality>, from live listings. entity_stats on listings is SECTION-based (0.50 credits per call; the 4 core calls = 2.00 credits). Listings section filters accept ONLY municipality / district / canton / postal_code / bbox + property_type (an ARRAY) + deal_type ("sale" | "rent", REQUIRED) + date_from / date_to (ISO with T+Z) + active (boolean) — no rooms/price filters. active: true = the CURRENT asking market; if a section returns too few listings for a small commune, retry without active but with date_from 12 months back. Follow these steps exactly:
1. RENT BY ROOM COUNT (0.50 cr)
Call entity_stats with:
{ entity_type: "listings", filters: { municipality: "<municipality>", deal_type: "rent", active: true },
section: "price_per_room" }
Extract: all-rooms median/average, median + p30–p70 per room band, and the property-type mix (apartments vs parking/commercial/rooms counts).
2. RENT PER M² BY ROOM COUNT (0.50 cr)
Call entity_stats with:
{ entity_type: "listings", filters: { municipality: "<municipality>", deal_type: "rent", active: true },
section: "price_m2_per_room" }
The per-m² view inverts the story — small flats pay the premium. Present BOTH units for the by-rooms figures (CHF/month and CHF/m²; in an artifact, a unit toggle).
3. RENT TREND (0.50 cr)
Call entity_stats with:
{ entity_type: "listings", filters: { municipality: "<municipality>", deal_type: "rent", property_type: ["apartment"] },
section: "price_evolution" }
Quarterly median asking rent for newly listed apartments. Read the last ~6 years; compute the 12-month change for the KPI row.
4. TIME TO LET (0.50 cr)
Call entity_stats with:
{ entity_type: "listings", filters: { municipality: "<municipality>", deal_type: "rent", date_from: "<12 months ago, ISO with T+Z>" },
section: "distribution" }
Read time_on_market: share let within 30/60/90 days and the average — the absorption-speed section.
5. ROOMS × SURFACE MATRIX (recommended — per-object cost, preview first)
search_entities listings { area: { municipality: "<municipality>" }, transaction_type: "rent", property_type: "apartment", active: true } with preview: true FIRST (typically ~100–150 ads ≈ 5–8 credits; skip if the user is cost-sensitive); then compute the median rent per rooms × surface-band cell.
6. THE DOCUMENT (blueprint — follow the kit)
- Verdict + 4 KPIs: median apartment rent · median CHF/m²·mo · average days to let · trend vs the series trough or 12 months back
- "Rent by rooms": band chart (p30–p70 + median tick) with a CHF/month ↔ CHF/m² unit toggle; the m² view inverts the story (small flats pay the premium) — say so
- "Where rooms and surface meet": the matrix as a heatmap (if step 5 ran), fading cells under 3 ads; name the volume cell — it is the reference product
- "Rent trend": quarterly line since ~2020, trough/peak annotated, last quarter emphasised; the analyst paragraph covers reversionary upside on older tenancies
- "How fast homes let": DOM bands with % labels; analyst paragraph on pricing power at this absorption speed
- One line on the non-apartment inventory mix (parking/commercial counts)
Notes-line: asking rents, not contract rents; sparse bands. Next step: /popety:listing-hunter for a client shortlist, or /popety:purchase-market-overview for the sale side — offer the more relevant one.
PRESENTATION — how to write the final answer (applies to every step above):
- The answer is a client-ready document that will be shared as-is. Not a chat log, not an analysis diary.
- Open with a title line (subject + commune + date) and a one-line verdict a reader would pay for. Never open with method, tool narration, or what you are about to do.
- The reader is a real-estate professional (broker, investor, developer). Every section closes with ONE analyst paragraph stating the professional implication — pricing, absorption, sourcing, underwriting — never a definition or a tutorial sentence. Show sample sizes and visibly de-emphasise figures resting on fewer than 3 observations.
- 3–6 titled sections, ordered by what matters most to the reader; one idea per section. Prefer short prose with embedded figures; use a table only when comparing 3+ items across 2+ dimensions, max ~6 rows, one comparison per table. Select the figures that change the reader's decision — do not dump every number you retrieved.
- Swiss formats: CHF 1'250'000 (apostrophe thousands), m², CHF/m²; official Swiss real-estate terminology in the reader's language. Write the whole document in the language the user wrote in.
- Caveats: at most ONE short "Notes" line at the end of the document (e.g. coverage gaps, asking ≠ realised prices). Never inline a disclaimer after a figure. Never mention tools, credits, section ids, API mechanics, or observations "for the platform team" inside the document — if you have a genuine data/product observation, put it after the document under a separate "---" divider, in one or two lines.
- Close the document with at most ONE "Next step" line offering the single most relevant follow-up — an offer, not a menu.
- In clients that support artifacts/canvas, render the document as a styled artifact (clean typography, generous spacing, no emojis) and keep the chat reply to a two-line summary; otherwise use clean markdown with real headings.
---
Requires the Popety connector (bundled with this plugin — authenticate on first use). Follow the workflow's cost gates: free/preview steps before any paid call.
## Building the document
When the client supports artifacts, render the final document as a plain HTML artifact (NEVER React/JSX — a JSX rewrite loses the stylesheet) built from `references/popety-kit.html` (bundled with this skill): read the kit FIRST, paste its ENTIRE <style> block verbatim as the stylesheet (never write your own CSS), give every SVG mark its literal hex fill/stroke attribute PLUS the kit mark class (mk1-mk4, mkband, mktick, mkline), and follow its primitives, helpers and rules — Popety brand in both themes, Swiss number formats, inline-SVG charts with tooltips, one analyst paragraph per section written for a real-estate professional. The finished document must visibly carry the Popety cyan (brandbar, kicker, verdict block, KPI accents, chart fills) — a grey/monochrome document means the kit was not applied. Without artifact support, apply the same structure in clean markdown.
Referenced files: 1 — file references are metadata, not package contents.
---
name: value-estimate
description: "AVM valuation with user-confirmed attributes, cross-checked against the market. Use when the user asks about property valuation, market value, how much a property is worth, price estimate."
disable-model-invocation: false
---
<!-- GENERATED FROM api/popety-mcp/src/prompts.ts — do not edit; run pnpm --filter @popety-io/mcp generate:integrations -->
# Value estimate
AVM valuation with user-confirmed attributes, cross-checked against the market.
**Arguments to collect from the user:**
- `address` — Full Swiss address of the property. Supply at least one of address or building_id. (optional)
- `building_id` — Popety building identifier. Supply at least one of address or building_id. (optional)
## Workflow
Estimate the market value of the Swiss property at "<address>". Follow these steps exactly:
1. RESOLVE THE PROPERTY (free)
Call estimate_property with { address: "<address>" } (no confirm flag).
This returns the register facts (address, building year, category) and the unit attributes still required: living_area, rooms_nb, bathroom_nb — plus construction_year when the register has no building year (common: ~40% of buildings).
2. CONFIRM ATTRIBUTES WITH THE USER
Ask the user for EVERY attribute listed in required_attributes (or confirm the returned suggestion for single-dwelling buildings). NEVER guess or invent them — the valuation is only as good as these inputs.
3. RUN THE VALUATION (paid, 3 credits)
Call estimate_property again with the same target plus { confirm: true, property_attributes: { living_area, rooms_nb, bathroom_nb, construction_year (if required), ... } }.
Extract: estimated purchase price, estimated rent, price per m², and confidence band.
4. MARKET POSITIONING (free — embedded in the confirm response)
The confirmed estimate carries a "market" block: the commune's asking CHF/m² p25/p50/p75 over ACTIVE sale listings, with ads_count. Position the estimate's price per m² against it (above/below the median, inside/outside the p25–p75 band) — no extra call needed. Only when market is null, or the user wants a deeper breakdown (by property type, evolution), call entity_stats with { entity_type: "listings", filters: { municipality: <municipality>, deal_type: "sale" }, section: "city_analysis" } (0.50 credits).
5. COMPARABLE TRANSACTIONS (only where recorded)
Transaction records cover French-speaking cantons and Ticino; Zürich and most DE-CH areas have none — skip this step there and rely on the listings cross-check. Where covered, call search_entities with { entity_type: "transactions", filters: { municipality: <municipality>, date_from: "<2 years ago>", step_name: "sale" } } and select up to 5 comparables.
6. THE DOCUMENT (blueprint — follow the kit)
- Verdict + estimate card: the value as a RANGE VISUAL (lower–mid–upper band with the mid marked, kit band+tick primitive) and the confidence band named
- 4 KPIs: estimated value · CHF/m² vs the commune's asking median · estimated rent/month · implied gross yield
- "Against the market": the property's CHF/m² plotted against the commune percentile fan (city_analysis) — say WHERE in the market it sits
- "Comparables": transactions where available, otherwise active-listing stats
Notes-line material: AI estimate from the confirmed attributes and market data, not a formal appraisal; listing figures are ASKING prices (typically above realised prices); in non-disclosure cantons (VD/VS/FR/TI) transaction prices are largely unpublished and confidence bands are wider.
PRESENTATION — how to write the final answer (applies to every step above):
- The answer is a client-ready document that will be shared as-is. Not a chat log, not an analysis diary.
- Open with a title line (subject + commune + date) and a one-line verdict a reader would pay for. Never open with method, tool narration, or what you are about to do.
- The reader is a real-estate professional (broker, investor, developer). Every section closes with ONE analyst paragraph stating the professional implication — pricing, absorption, sourcing, underwriting — never a definition or a tutorial sentence. Show sample sizes and visibly de-emphasise figures resting on fewer than 3 observations.
- 3–6 titled sections, ordered by what matters most to the reader; one idea per section. Prefer short prose with embedded figures; use a table only when comparing 3+ items across 2+ dimensions, max ~6 rows, one comparison per table. Select the figures that change the reader's decision — do not dump every number you retrieved.
- Swiss formats: CHF 1'250'000 (apostrophe thousands), m², CHF/m²; official Swiss real-estate terminology in the reader's language. Write the whole document in the language the user wrote in.
- Caveats: at most ONE short "Notes" line at the end of the document (e.g. coverage gaps, asking ≠ realised prices). Never inline a disclaimer after a figure. Never mention tools, credits, section ids, API mechanics, or observations "for the platform team" inside the document — if you have a genuine data/product observation, put it after the document under a separate "---" divider, in one or two lines.
- Close the document with at most ONE "Next step" line offering the single most relevant follow-up — an offer, not a menu.
- In clients that support artifacts/canvas, render the document as a styled artifact (clean typography, generous spacing, no emojis) and keep the chat reply to a two-line summary; otherwise use clean markdown with real headings.
---
Requires the Popety connector (bundled with this plugin — authenticate on first use). Follow the workflow's cost gates: free/preview steps before any paid call.
## Building the document
When the client supports artifacts, render the final document as a plain HTML artifact (NEVER React/JSX — a JSX rewrite loses the stylesheet) built from `references/popety-kit.html` (bundled with this skill): read the kit FIRST, paste its ENTIRE <style> block verbatim as the stylesheet (never write your own CSS), give every SVG mark its literal hex fill/stroke attribute PLUS the kit mark class (mk1-mk4, mkband, mktick, mkline), and follow its primitives, helpers and rules — Popety brand in both themes, Swiss number formats, inline-SVG charts with tooltips, one analyst paragraph per section written for a real-estate professional. The finished document must visibly carry the Popety cyan (brandbar, kicker, verdict block, KPI accents, chart fills) — a grey/monochrome document means the kit was not applied. Without artifact support, apply the same structure in clean markdown.
Referenced files: 1 — file references are metadata, not package contents.
Publisher declarations from the archived package. These are separate from our research and the live service's terms.
Package observed Nov 3, 2026.
plugin_asdk_app_6ac8e57de9848191ae058d271d90184b
Download plugin data (JSON)