Voxhouses (Portugal)

get_market_stats

Read-onlyIdempotent

Get price statistics for a slice of the Portugal property market: how many listings match, the median price, the p25–p75 range, the median price per m² and a breakdown by typology. Use this when the user asks what something costs, whether an asking price is fair, or how two areas compare — instead of listing individual properties. Takes the same filters as search_properties and describes exactly the set that tool would return, so the two never disagree. Reports medians and quartiles rather than averages, because property prices have a long right tail and a single luxury listing moves an average. Call once per area to compare areas.

Input Schema

Name	Required	Description
`minArea`	No	Minimum floor area in m². Matches either the gross or the useful area, whichever the source published. Only matches listings that published an area.
`location`	No	Location: district, municipality, neighbourhood, town or postal-code prefix (e.g. Lisbon, Cascais, Chiado, 2750). Not a free-text keyword search — words that are not places (e.g. 'sea view') will not match.
`priceMax`	No	Maximum price, in the market currency. Note: listings advertised 'price on request' have no price and are excluded by either price bound.
`priceMin`	No	Minimum price, in the market currency.
`typology`	No	Normalised typology code (T0, T1, T2, T3…), where the number is the count of bedrooms. Used in every market, including the German and Polish ones. Matched exactly; pass an array to match several. The buckets `T0–T1` and `T4+` are also accepted.
`condition`	No	State of repair, or an array of states. Only matches listings whose source published it.
`operation`	No	buy = for sale, rent = to let. Defaults to buy; a listing is one or the other, so call twice to cover both.
`energyClass`	No	Energy certificate class. Selects the whole band the class belongs to: A+/A, B/B-, C, or D-and-below. Only matches listings that carry a certificate.
`minBathrooms`	No	Minimum number of bathrooms. Only matches listings whose source published a bathroom count.
`propertyType`	No	Property type, or an array of types. Omit to search all types. `farm` covers rural estates (quintas); `building` is a whole apartment block.

Output Schema

Name	Required	Description
`count`	Yes	Listings matching the filters, with or without a published price.
`price`	No	Price distribution, in percentiles. null when no matching listing publishes a price. There is deliberately no min or max: listings come from third-party sources and the extremes are set by data errors, not by the market.
`market`	Yes
`priced`	Yes	Subset with a published price — the base of every figure below. A large gap to `count` means many listings in this slice are 'price on request'.
`currency`	Yes
`operation`	Yes
`byTypology`	Yes	Up to 6 most represented typologies, each with its own median.
`pricePerM2Median`	No	Median price per m² among listings that published both a price and an area. Best figure for comparing areas.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 21, 2026

changedInput schema / properties / energyClass / enum

Previous value: -[
-  "A+",
-  "A",
-  "B",
-  "B-",
-  "C",
-  "D",
-  "E",
-  "F"
-]New value: +[
+  "A++",
+  "A+",
+  "A",
+  "B",
+  "B-",
+  "C",
+  "D",
+  "E",
+  "F",
+  "G",
+  "H"
+]

First observedSep 1, 2026

TDQS

A4.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety bar is low; the description nonetheless adds real substance — the guarantee that the tool describes exactly the result set search_properties would return, and the median/quartile methodology rationale. It stops short of covering edge behavior such as what a slice with zero matches reports, which keeps it off a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and return payload, then usage, then the consistency guarantee and methodology note — each sentence contributes a distinct fact. The median-versus-average sentence justifies a design choice an agent might otherwise question, so it earns its place rather than padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 10-parameter, zero-required aggregate tool with a full output schema, the description supplies what structured fields cannot: intent routing, the sibling equivalence guarantee, and the one-call-per-area pattern. Return values are described at a level that complements rather than duplicates the output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already carries per-parameter meaning; the description adds a semantic anchor by declaring the filter set identical to search_properties, which tells the agent the two tools partition the same data consistently. It adds no parameter-specific detail beyond that, which is acceptable given full schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Get price statistics for a slice of the Portugal property market') and enumerates exactly what is returned: match count, median, p25–p75, median price per m², typology breakdown. It also explicitly distinguishes itself from the sibling that lists individual properties, so an agent can route without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete triggering questions ('what something costs', 'whether an asking price is fair', 'how two areas compare') and an explicit exclusion ('instead of listing individual properties'), naming search_properties as the alternative. It closes the loop with per-call guidance ('Call once per area to compare areas'), leaving little to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Voxhouses (Portugal) tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?