Skip to main content
Glama
chrischall

OurFamilyWizard MCP

by chrischall
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Hemnet sold-price market statistics

hemnet_get_market_stats
Read-onlyIdempotent

Aggregate median and average sold-price statistics from recent sales for a location, including price per m² and over/under-asking percentage, to analyze real estate trends.

Instructions

Aggregate median/average statistics from recent SOLD listings for a location (and optional property-type/size filters): median & average final price, median & average price-per-m², and average over/under-asking percentage. The stats cover the most recent max_sales sales (default 200, max 500), not necessarily every match — compare sampled_sales with total_matching_sales. Provide location_ids or a free-text location. Read-only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sortNoNEWEST (default) or OLDEST.
limitNoDeprecated: use `max_sales`. Read as `max_sales` when that is not given.
offsetNoDeprecated and ignored: the stats always start from the first matching sale.
keywordsNoFree-text keyword filter (e.g. "sjönära", "balkong").
locationNoFree-text place name (e.g. "Vasastan", "Göteborg") resolved to its top Hemnet location. Ignored when `location_ids` is set.
max_salesNoHow many sold listings to aggregate, newest first by default (paged 50 at a time). Default 200, max 500.
price_maxNoSEK
price_minNoSEK
rooms_maxNo
rooms_minNo
location_idsNoNumeric Hemnet location ids (from hemnet_autocomplete_location). Provide this OR `location`.
living_area_maxNom²
living_area_minNom²
housing_form_groupsNoProperty-type groups: HOUSES (villa), APARTMENTS (lägenhet/bostadsrätt), ROW_HOUSES (radhus/parhus), VACATION_HOMES (fritidshus), PLOTS (tomt), OTHERS.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.1.12
    • changedInput schema / properties / limit / description
      Previous value: -"Default 25, max 50."New value: +"Deprecated: use `max_sales`. Read as `max_sales` when that is not given."
    • changedInput schema / properties / limit / maximum
      Previous value: -50New value: +500
    • addedInput schema / properties / max_sales
      Added value: +{
+  "description": "How many sold listings to aggregate, newest first by default (paged 50 at a time). Default 200, max 500.",
+  "maximum": 500,
+  "minimum": 1,
+  "type": "integer"
+}
    • changedInput schema / properties / offset / description
      Previous value: -"Pagination offset."New value: +"Deprecated and ignored: the stats always start from the first matching sale."
  2. Changed1 schema field changedv1.0.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  3. Addedv0.2.0

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, openWorldHint); the description adds real context beyond them by disclosing that stats cover only the most recent max_sales sales rather than all matches and pointing at the sampled_sales/total_matching_sales comparison. No pagination, caching, or cost behavior is mentioned, keeping it out of 5 territory.

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

Conciseness4/5

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

Dense but well front-loaded: the core purpose and outputs lead, with scoping caveats and the location rule following. Every clause carries information, though the sentence is long and packs several distinct facts into one stream.

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

Completeness4/5

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

With no output schema, the description correctly enumerates the returned metrics and, for a 14-param stats tool, explains the key sampling distinction and required location input. It stops short of noting anything about errors or result shape, but for a read-only aggregate tool this is largely complete.

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 high (86%), so the schema already documents nearly all 14 parameters, including defaults and the deprecated limit/offset fields. The description reinforces a couple of defaults (max_sales 200/500) and the location_ids-vs-location rule but adds little beyond the schema, matching the baseline-3 case.

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

Purpose4/5

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

Specific verb+resource: 'Aggregate median/average statistics from recent SOLD listings', with the exact output metrics enumerated (median/average price, price-per-m², over/under-asking). It implicitly separates itself from listing-returning siblings like hemnet_search_sold, but never names or contrasts an alternative explicitly, so it lands shy of a 5.

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

Usage Guidelines3/5

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

Gives concrete invocation guidance for the location parameter ('Provide `location_ids` or a free-text `location`') and explains the sampling caveat ('compare `sampled_sales` with `total_matching_sales`'). However there is no when-to-use/when-not guidance against alternatives such as hemnet_search_sold, leaving usage largely inferred.

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

Deploy Server

Other Tools