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

TableJSON 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

TableJSON 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.

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already mark it read-only, idempotent, and non-destructive, so the description carries a modest burden. It still adds valuable behavioral context: medians and quartiles are used instead of averages because of the long right tail, and the tool reports exactly the set search_properties would return so the two never disagree. These are meaningful choices an agent needs to interpret results correctly.

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?

The description is compact and every sentence earns its place: one for output definition, one for when to use it, one for filter agreement, one for statistical rationale, and one for comparing areas. The core purpose is front-loaded and no redundant phrasing appears.

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 read-only aggregate tool with 100% schema coverage, an output schema, and strong annotations, the description covers the remaining context: when to call it, how to compare areas, why medians are reported, and how its result set relates to search_properties. Nothing essential is missing for correct invocation.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all 10 parameters in detail. The description adds the useful high-level statement that it 'takes the same filters as search_properties,' but it does not contribute individual parameter semantics beyond the schema. Baseline 3 is appropriate.

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?

The description opens with a specific verb and resource: 'Get price statistics for a slice of the Portugal property market' and enumerates the exact outputs (count, median price, p25–p75, median per m², typology breakdown). It also distinguishes itself from listing tools by saying it is used 'instead of listing individual properties,' so an agent can separate it from siblings like search_properties.

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?

Usage conditions are explicit: use it when the user asks 'what something costs, whether an asking price is fair, or how two areas compare.' It also gives a concrete alternative ('instead of listing individual properties'), references search_properties for filter compatibility, and instructs agents to call once per area. This fully routes the decision.

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

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0

Disambiguation4/5

The two property-search tools overlap slightly, but their descriptions clearly separate structural filtering from free-text description ranking, and get_market_stats is explicitly positioned as statistical aggregation rather than listing retrieval. search_articles and search_neighbourhoods both serve editorial content, but their domains—process guidance versus area guides—are distinguishable enough.

Naming Consistency5/5

All tools use snake_case and follow a consistent search_/get_/find_ verb pattern keyed to the returned object type: search_properties, search_articles, search_neighbourhoods, get_property_detail, get_market_stats. The longer search_properties_by_description still fits the convention and is unambiguous.

Tool Count5/5

Seven tools is well-scoped for a read-only property information server: structured listing search, semantic listing search, similar-property lookup, detail retrieval, market statistics, neighbourhood guides, and editorial articles. Each tool serves a distinct user need without redundancy.

Completeness5/5

The tool surface covers the full informational workflow for Portuguese real estate: finding properties, exploring similar options, viewing full details, comparing market prices, and learning about areas and buying processes. There are no obvious dead ends for typical read-only property questions.

Resources

Need Help?