Inside the experiment

What happens between the prompt and the results.

Fyn is a small experimental project: a demonstration of how property portals could expose inventory to AI agents through structured tools, without forcing a model to navigate an interface designed for humans.

The hypothesis
If property inventory were available as a reliable, typed, and traceable tool, an AI could plan the search while the portal retained control over its data, rules, and final experience.
01 · MCP contract

A tool describes what the model is allowed to request

Fyn publishes search_properties through Model Context Protocol. Its schema defines municipalities, transaction type, budget, bedrooms, property types, and preferences. Free text adds context, but execution relies on validated, structured constraints.

In the prototype: MCP SDK + Zod over Streamable HTTP.
02 · Planning

The AI turns intent into a search plan

The model interprets ambiguous phrases—‘near nature’, ‘neighborhood character’, or ‘renovation is fine’—and chooses locations, hard filters, and soft preferences. Fyn does not run another LLM in the backend: it receives that plan and executes it deterministically.

The separation matters: the model reasons; the tool validates and executes.
03 · Adapters

Each portal requires a different translation

A connector registry maps the common contract to each source’s actual capabilities. Today the experiment works with public pages and portal-specific behavior; ideally, these adapters would consume official APIs designed for agents.

Connectors are replaceable: the shared interface does not depend on the source.
04 · Normalization

Heterogeneous data enters one shared model

Available fields become a ListingCard: identifier, portal, URL, price, bedrooms, type, images, and observation time. Hard filters run before ranking so a high score cannot hide a basic constraint violation.

The normalized contract combines sources without erasing provenance.
05 · Ranking and diagnostics

The response includes reasons—and failures

Explicit scoring weighs budget, bedrooms, location, and text signals such as light, views, or exterior aspect. The response adds why_matched and coverage per location and source, including blocks, schema changes, empty results, or outages.

Failure transparency is part of the result, not an internal detail.
What it tries to demonstrate

A possible interaction layer for property portals in the agent era.

01

Tools, not scraping

The desirable end state is official agent APIs with permissions, limits, and stable contracts.

02

Planning outside the portal

Users keep their conversation while AI composes searches over authorized inventory.

03

Control for the source

A portal can define fields, quotas, attribution, links, access, and commercial rules.

04

Verifiable results

Every property retains its source and the user completes the journey on the original listing.

The prototype is open to inspection.

Review the MCP contract and test the endpoint to see what works today and where the boundaries are.