What can you do with this server?

The OurFamilyWizard MCP server lets you manage your co-parenting account across messages, calendar, expenses, and journal entries. Profile & Notifications * View profile info for yourself and your co-parent * Check dashboard notifications (unread messages, upcoming events, outstanding expenses) Messaging * List message folders with unread counts * List, search (by folder, date range, subject/body keyword), and read messages * Send messages, reply to threads, or send from drafts * Save, update, list, and delete drafts * Track sent messages not yet read by recipients * Sync messages to a local cache * Upload file attachments to OFW My Files; download attachments from messages Calendar * List events within a date range * Create, update, and delete events (title, dates, location, reminders, child assignments, pickup/dropoff info) Expenses * View expense summary totals (owed/paid) * List existing expenses * Log new expenses with amount and description Journal * List journal entries * Create new journal entries with a title and body

How do I use OurFamilyWizard MCP?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@OurFamilyWizard MCP What's on the kids' calendar this week?" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

OurFamilyWizard MCP

by chrischall

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Local

Hemnet MCP

npm license

An MCP server for hemnet.se, Sweden's largest real-estate portal. Search for-sale listings, look up sold prices (slutpriser), pull full listing detail and photos, compute market statistics, resolve addresses, and run a Swedish mortgage calculation — all from Claude.

⚠️ This project is built and maintained by AI (Claude). It reads hemnet.se through its public GraphQL API. Use at your own discretion and within hemnet.se's terms of service.

Highlights

No configuration. Hemnet serves its read queries anonymously — no login, no API key, no browser extension. npx hemnet-mcp just works.
Sold prices (slutpriser). Hemnet's signature dataset: achieved final price, asking price, and over/under-asking percentage — the comps an agent needs to value a home.
Swedish-native. Money in SEK, areas in m², rooms, bostadsrätt fees (avgift), energy class, and a mortgage model that follows Swedish rules (amorteringskrav, ränteavdrag).
Embeddable. Ships as a standalone MCP server and as a library so it can be composed into a larger multi-portal server.

Related MCP server: whoop-mcp

Install

Claude Code / Claude Desktop (npx)

{
  "mcpServers": {
    "hemnet": {
      "command": "npx",
      "args": ["-y", "hemnet-mcp"]
    }
  }
}

From source

git clone https://github.com/chrischall/hemnet-mcp
cd hemnet-mcp
npm install
npm run build
node dist/index.js

Tools

Tool	What it does
`hemnet_autocomplete_location`	Resolve a place name (`"Vasastan"`) to Hemnet location ids — the starting point for search.
`hemnet_search_listings`	Search active for-sale listings by location + filters (price SEK, rooms, m², property type, keywords).
`hemnet_get_listing`	Full detail for one listing (price, fee, running costs, m², rooms, tenure, energy class, broker, description, photos).
`hemnet_get_listing_photos`	Just the gallery photo URLs.
`hemnet_search_sold`	Search sold listings with final price, asking price, and over/under-asking %.
`hemnet_get_sold_listing`	Full detail for one sold listing.
`hemnet_get_market_stats`	Median/average final price and price-per-m² for a location.
`hemnet_compare_listings`	Fetch several listings at once for side-by-side comparison.
`hemnet_get_by_address`	Resolve a free-text street address to a live listing.
`hemnet_calculate_mortgage`	Local Swedish monthly-cost calculator (interest + amortisation + fee, gross & after-tax). No network.
`hemnet_healthcheck`	Verify the Hemnet GraphQL endpoint is reachable. Reports which transport served the probe (`transport`: direct fetch or the browser bridge, plus the configured `HEMNET_TRANSPORT`), the bridge's role/port/extension-link state (`bridge`, once a bridge exists), a classified `error.kind` (e.g. `cloudflare_challenge`, `session_not_ready`) and a next-step hint.

Example flow

1. hemnet_autocomplete_location { query: "Vasastan" }
   → location_id 925970
2. hemnet_search_listings { location_ids: ["925970"], rooms_min: 2, price_max: 6000000 }
   → listing summaries
3. hemnet_get_market_stats { location_ids: ["925970"], housing_form_groups: ["APARTMENTS"] }
   → median final price, price-per-m²
4. hemnet_calculate_mortgage { price: 4695000, interest_rate: 3.9, monthly_fee: 2800 }
   → monthly cost, gross and after-tax

Or pass a free-text location to any search tool and it resolves the top hit for you.

Money & units

All output records use numbers: price / final_price / fee_monthly in SEK, living_area_sqm / land_area_sqm in m², rooms as a number. A derived price_per_sqm is always included when price and living area allow it (even when Hemnet omits it, common on houses). The original Hemnet-formatted strings are kept alongside as *_formatted.

Library use

hemnet-mcp is also importable, so it can serve as a Hemnet portal source inside a larger project (e.g. a cross-portal realty orchestrator):

import { createHemnetClient, computeMarketStats } from 'hemnet-mcp';

const hemnet = createHemnetClient();
const { cards } = await hemnet.searchSales({ locationIds: ['925970'] }, { limit: 50 });
const stats = computeMarketStats(cards.map(formatSaleCard));

The library entry (import … from 'hemnet-mcp') re-exports the client, the normalised record types, the pure derivations (computeMarketStats, calculateSwedishMortgage, money/url helpers), and every tool registrar (registerHemnetTools(server, client) to graft the tools onto your own MCP server).

Development

npm test               # vitest (mocked transport, no network)
npm run test:coverage  # 100% coverage enforced on src/**
npm run typecheck
npm run build

Tests drive every tool and the client through an in-memory fake transport — no live hemnet.se calls. See CLAUDE.md for architecture, the GraphQL quirks, and contribution conventions.

License

MIT

Available Tools

11 tools

hemnet_autocomplete_locationResolve a place name to Hemnet location idsA

Read-onlyIdempotent

Look up Hemnet location ids for a free-text place name (municipality, district, or area). Returns ranked hits with location_id, full_name, and parent_full_name. Feed a location_id into hemnet_search_listings / hemnet_search_sold. Read-only.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Default 10.
`query`	Yes	Place name, e.g. "Vasastan" or "Malmö".

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already indicate readOnlyHint, openWorldHint, idempotentHint. Description reinforces read-only and adds detail about return format (ranked hits with specific fields). No contradictions. The description adds value beyond annotations.

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?

Two sentences, front-loaded with purpose, no wasted words. The structure is efficient and easy to parse.

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?

Given the tool's simplicity, good annotations, and no output schema, the description adequately covers purpose, usage, and return format. It is complete for the agent to use correctly.

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 coverage is 100%, so description does not need to add much. It provides a default for limit (10) not present in schema, and an example for query. This adds minor value beyond the schema definitions.

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 clearly states the tool's purpose: 'Look up Hemnet location ids for a free-text place name.' It specifies the scope (municipality, district, or area) and mentions return fields. It distinguishes from siblings by noting that the location_id feeds into hemnet_search_listings/hemnet_search_sold.

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

Usage Guidelines4/5

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

The description provides clear usage guidance: use this tool before search tools to obtain location_ids. It specifies read-only behavior and suggests feeding the result into other tools. However, it does not explicitly state when not to use it, but the context is sufficient.

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

hemnet_calculate_mortgageCalculate a Swedish monthly mortgage costA

Read-onlyIdempotent

Local-only Swedish mortgage calculator (all amounts SEK). Returns the monthly cost broken into interest, mandated amortisation (amorteringskrav from LTV + a debt-ratio surcharge when income is given), BRF fee (avgift), and operating cost — with both gross and after-tax (ränteavdrag) totals. Provide down_payment OR down_payment_percent (defaults to the legal 15% minimum). No network call.

ParametersJSON Schema

Name	Required	Description
`price`	Yes	Purchase price in SEK.
`monthly_fee`	No	BRF monthly fee (avgift) in SEK — for bostadsrätt apartments.
`down_payment`	No	SEK
`interest_rate`	Yes	Annual interest rate %, e.g. 3.5
`amortization_rate`	No	Override the computed amortisation rate (annual % of loan).
`gross_yearly_income`	No	Gross household income/year in SEK — enables the +1% debt-ratio amortisation surcharge.
`down_payment_percent`	No	Percent of price; defaults to the legal 15% minimum.
`monthly_operating_cost`	No	Monthly operating cost (driftkostnad) in SEK — typically houses.

TDQS

A4.7/5.0

Behavior5/5

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

Discloses key behaviors: no network call, uses Swedish amortisation rules (amorteringskrav, debt-ratio surcharge), includes ränteavdrag tax deduction. Annotations (readOnlyHint, idempotentHint) are consistent and the description enriches them with algorithmic details.

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?

Fairly concise for a complex tool; the core purpose is front-loaded. A few extra details (e.g., 'BRF fee (avgift)') are useful but could be slightly trimmed. Still highly effective.

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?

No output schema, but the description fully explains the return value (monthly cost breakdown with gross/after-tax). All parameters are covered, and the context (local-only, Swedish rules) is complete for an agent to use this tool correctly.

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

Parameters5/5

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

Schema coverage is 100% with descriptions. The description adds beyond schema by clarifying defaults (down_payment_percent defaults to 15% legal minimum) and the effect of gross_yearly_income (enables +1% surcharge). This meaningfully aids parameter understanding.

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 uses a specific verb ('Calculate a Swedish monthly mortgage cost') and explicitly details what it computes (interest, amortisation, BRF fee, operating cost, gross/after-tax totals). It is distinct from all sibling tools, which are search, listing, or location tools.

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

Usage Guidelines4/5

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

Implies usage context: Swedish mortgages only, local amounts. No explicit when-not-to-use or alternatives, but no sibling calculator exists, so the differentiation is clear. A 4 reflects minor room for explicit exclusion statements.

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

hemnet_compare_listingsCompare several Hemnet listingsA

Read-onlyIdempotent

Fetch and normalise multiple active for-sale Hemnet listings at once (by id or /bostad/ URL) for side-by-side comparison. Up to 20 targets; input order preserved; per-row errors captured. Read-only.

ParametersJSON Schema

Name	Required	Description	Default
`ids`	Yes	Hemnet listing ids or /bostad/ URLs (max 20).

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds valuable behavioral details: 'Up to 20 targets; input order preserved; per-row errors captured. Read-only.' This goes beyond annotations without contradiction.

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 two sentences, front-loading the purpose and then listing constraints. No extraneous words; every sentence adds value.

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 simple tool with one parameter, no output schema, and thorough annotations, the description is complete. It covers functionality, constraints, and error handling without missing critical information.

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 coverage is 100% for the single parameter 'ids', and the description does not add additional meaning beyond what the schema already provides (listing IDs or URLs, max 20). Baseline score of 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 clearly states the verb 'fetch and normalise', the resource 'multiple active for-sale Hemnet listings', and the purpose 'for side-by-side comparison'. It distinguishes from siblings like hemnet_get_listing by emphasizing multiple listings and comparison.

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

Usage Guidelines4/5

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

The description implies when to use (comparing multiple listings) but does not explicitly state when not to use or provide alternatives beyond the sibling list. It is clear enough for the intended use case.

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

hemnet_get_by_addressResolve a street address to a Hemnet listingA

Read-onlyIdempotent

Resolve a free-text Swedish street address to a live Hemnet for-sale listing. Give the address (street + number) and a location (city/area/municipality). Returns the matched listing with a matched: true, the match score, and matched_via, or { resolved: false } when nothing matches. Read-only.

ParametersJSON Schema

Name	Required	Description
`address`	Yes	Street address incl. number, e.g. "Gäddstigen 1".
`location`	Yes	City / area / municipality, e.g. "Södertälje" or "Vasastan".
`price_max`	No	SEK, narrows the search rung.
`price_min`	No	SEK, narrows the search rung.

TDQS

A4.2/5.0

Behavior4/5

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

Annotations (readOnlyHint, openWorldHint, idempotentHint) already indicate safe, read-only behavior. The description reinforces 'Read-only' and adds details about the return format (matched: true, score, matched_via, or resolved: false), which is valuable beyond the annotations.

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?

Extremely concise: 3 sentences covering purpose, input format, and output. No redundant words. Front-loaded with the main verb and resource. Every sentence earns its place.

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?

For a tool with 4 parameters and no output schema, the description adequately covers the return structure and input expectations. It mentions both success and failure cases. Minor omission: no mention of error states or edge cases like multiple matches, but overall complete enough.

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 baseline is 3. The description repeats the meaning of address and location but does not add new semantics for the optional price parameters beyond what is in the schema. No contradiction, but no significant added value.

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?

Clearly states the action (resolve a free-text Swedish street address to a live Hemnet for-sale listing), specifies required inputs (address and location), and describes the output structure. Distinguishes from sibling tools like hemnet_search_listings by focusing on a single address resolution.

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

Usage Guidelines4/5

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

Provides clear context on when to use: when you have a specific street address and location. Does not explicitly mention when not to use or name alternative tools, but the purpose is sufficiently distinct from siblings. The instruction 'Give the address and location' guides invocation.

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

hemnet_get_listingGet a Hemnet for-sale listing by id or URLA

Read-onlyIdempotent

Fetch the full detail of a single active for-sale listing by its Hemnet id or a /bostad/ URL. Returns price, monthly fee, yearly running costs, living/land area in m², rooms, tenure, construction year, energy class, broker, description, status labels, coordinates, and gallery photo URLs. For a SOLD listing use hemnet_get_sold_listing instead. Read-only.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Hemnet listing id, or a full hemnet.se /bostad/ URL.
`photo_limit`	No	Max gallery photos to include. Default 50.

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already provide readOnlyHint, openWorldHint, and idempotentHint. The description reinforces 'Read-only' and lists return fields, adding value without contradicting annotations. It does not discuss auth or rate limits, but annotations cover safety.

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?

Two sentences plus 'Read-only'—extremely concise. The key action is front-loaded, followed by return fields, then usage guidance. No fluff.

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?

Despite no output schema, the description enumerates return fields extensively. Input is clearly defined via schema and description. The tool is simple (two params), and the description covers all essential aspects: what it returns, input format, and sibling differentiation.

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%, with both parameters well-documented (id accepts id or URL, photo_limit has max/min/default). The tool description does not add new parameter semantics beyond what the schema already provides.

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 clearly states it fetches a single active for-sale listing by id or URL, distinguishing it from the sold listing tool. The verb 'Fetch' and resource 'single active for-sale listing' are specific and unambiguous.

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?

Explicitly states when to use (active for-sale listing) and when not (sold listing), with a direct pointer to the alternative tool hemnet_get_sold_listing. This provides clear decision support.

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

hemnet_get_listing_photosGet photo URLs for a Hemnet listingA

Read-onlyIdempotent

Return the gallery photo URLs for an active for-sale Hemnet listing by id or /bostad/ URL. Read-only.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Hemnet listing id, or a full hemnet.se /bostad/ URL.
`limit`	No	Max photos to return. Default 50.

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds the behavioral constraint that the listing must be 'active for-sale', which is valuable beyond the annotations. It is transparent about the read-only nature, though it does not detail error behavior or response format.

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 a single concise sentence that conveys the core functionality without superfluous words. It is front-loaded with the primary action and constraints, earning every word.

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?

Given the simplicity of the tool and good annotations, the description is mostly complete. However, it lacks any mention of output format or error conditions (e.g., what happens if id is invalid or listing not active). This leaves a minor gap, but overall it provides sufficient context for an agent.

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 coverage is 100% with both parameters (id and limit) well-described in the schema. The description does not add any new meaning beyond what is already in the schema, so the baseline of 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 clearly states the tool returns gallery photo URLs for active for-sale Hemnet listings, specifying input as id or URL. This is a specific verb-resource combination that distinguishes it from siblings like hemnet_get_listing (likely returns listing details) and hemnet_search_listings.

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

Usage Guidelines4/5

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

The description gives clear context for using the tool (to fetch photos for a specific listing) but lacks explicit guidance on when not to use it or mention of alternatives. It is straightforward for an agent to infer, but a more explicit exclusion or mention of sibling tools would elevate it.

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

hemnet_get_market_statsHemnet sold-price market statisticsA

Read-onlyIdempotent

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. Provide location_ids or a free-text location. Read-only.

ParametersJSON Schema

Name	Required	Description
`sort`	No	NEWEST (default) or OLDEST.
`limit`	No	Default 25, max 50.
`offset`	No	Pagination offset.
`keywords`	No	Free-text keyword filter (e.g. "sjönära", "balkong").
`location`	No	Free-text place name (e.g. "Vasastan", "Göteborg") resolved to its top Hemnet location. Ignored when `location_ids` is set.
`price_max`	No	SEK
`price_min`	No	SEK
`rooms_max`	No
`rooms_min`	No
`location_ids`	No	Numeric Hemnet location ids (from hemnet_autocomplete_location). Provide this OR `location`.
`living_area_max`	No	m²
`living_area_min`	No	m²
`housing_form_groups`	No	Property-type groups: HOUSES (villa), APARTMENTS (lägenhet/bostadsrätt), ROW_HOUSES (radhus/parhus), VACATION_HOMES (fritidshus), PLOTS (tomt), OTHERS.

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint. Description adds 'Read-only' and clarifies it aggregates from recent sold listings. This adds marginal context beyond annotations, but no further behavioral details (e.g., rate limits, data freshness). With high annotation coverage, a score of 3 is appropriate.

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?

Description is two sentences: first lists all metrics, second gives key parameter guidance. No unnecessary words. Front-loaded with the most important information. Every sentence earns its place.

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?

Given 13 parameters and no output schema, the description covers the main purpose and key metrics returned. It mentions location and filters but omits pagination/sorting behavior. However, the output is summarized (median/average stats), so the description is mostly complete. A score of 4 reflects the minor gap.

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 coverage is high (85%), so the schema already describes most parameters. The description adds context that location_ids or location should be provided, and mentions property-type/size filters, but does not add deeper meaning for individual parameters like sort, limit, or offset. Baseline 3 is suitable.

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?

Description clearly states the verb 'aggregate' and resource 'median/average statistics from recent SOLD listings'. It specifies the metrics (median & average price, price per m², over/under-asking) and distinguishes from sibling tools like hemnet_search_sold which returns individual listings.

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?

Description says to provide location_ids or free-text location, and mentions optional filters. However, it does not explicitly advise when to use this tool over alternatives (e.g., for aggregated stats vs individual sold listings). The read-only hint is present but no exclusions or when-not-to-use guidance.

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

hemnet_get_sold_listingGet a Hemnet sold listing by id or URLA

Read-onlyIdempotent

Fetch the full detail of a single SOLD listing by its Hemnet id or a /salda/ URL. Returns final price, asking price, price change, m², rooms, tenure, broker, and coordinates. Read-only.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Hemnet sold-listing id, or a full hemnet.se /salda/ URL.

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds value by stating the tool is read-only and listing the specific fields returned (e.g., final price, m², broker). No contradictions.

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?

Two concise sentences, no wasted words. Front-loaded with the core action and purpose, making it easy to parse.

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 single-parameter, read-only lookup tool with no output schema, the description fully covers what the tool does, the input format, and the output fields. It is complete and sufficient.

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 has 100% coverage, giving baseline 3. The description reinforces the parameter by stating the id can be a Hemnet id or a full URL, adding meaningful context beyond the schema description alone.

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 clearly states it fetches a single SOLD listing using its id or a /salda/ URL, and lists key returned fields. It explicitly distinguishes from siblings like hemnet_get_listing (non-sold) and hemnet_search_sold (search).

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

Usage Guidelines4/5

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

It specifies the tool is for sold listings, providing clear context. However, it does not explicitly state when not to use it or mention alternatives, though siblings indirectly cover that.

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

hemnet_healthcheckVerify the fetchproxy bridge end-to-endA

Read-onlyIdempotent

Round-trips a small public www.hemnet.se URL (/graphql) through the fetchproxy bridge and returns diagnostics: the bridge's role (host/peer/null), port, version, the extension link (linked / pair pending / not attached / never answered), the elapsed round-trip time, and a plain-English hint distinguishing 'bridge never came up' from 'extension not connected' from 'real www.hemnet.se-side problem'. Call this when a real tool fails and you want to know which hop broke. Read-only, no auth required.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds meaningful behavioral context beyond that: it performs a real network round-trip, reports bridge role/port/version, link state, latency, and distinguishes failure modes. It also explicitly states 'Read-only, no auth required,' which directly helps an agent decide to invoke it safely.

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 dense but every clause earns its place: it states the action, the exact endpoint, the full list of returned diagnostics, the interpretation hint, and the trigger condition. The usage guidance is placed at the end after the behavior, which is logical for a diagnostic tool.

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?

With no output schema, the description carries the burden of explaining what the agent will receive, and it does so thoroughly: role, port, version, extension link status, elapsed time, and a plain-English failure-mode hint. It also explains the three possible failure interpretations, making the response actionable. Nothing critical is missing for a zero-parameter health-check tool.

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?

The tool has zero parameters and 100% schema coverage (empty schema), so parameter documentation is trivially complete. The description adds no parameter semantics because none are needed; it instead focuses on the output diagnostics, which is the right priority for a parameterless tool.

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 uses a specific verb ('Round-trips') and a concrete resource ('a small public www.hemnet.se URL (/graphql) through the fetchproxy bridge'), then enumerates exactly what diagnostics are returned. It clearly differentiates this tool from the data-fetching siblings by framing it as a bridge health check rather than a listing/search operation.

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?

The description explicitly states when to call it: 'Call this when a real tool fails and you want to know which hop broke.' This gives the agent a clear trigger condition and makes the diagnostic intent obvious. No alternatives are named, but none are needed because no sibling provides this health-check function.

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

hemnet_search_listingsSearch Hemnet for-sale listingsA

Read-onlyIdempotent

Search active for-sale property listings on hemnet.se by location and optional filters (price band in SEK, rooms, living area in m², property-type groups, keywords). Returns listing summaries with price, fee, m², rooms, price-per-m², and coordinates. Provide location_ids (from hemnet_autocomplete_location) or a free-text location. Read-only.

ParametersJSON Schema

Name	Required	Description
`sort`	No	NEWEST (default) or OLDEST.
`limit`	No	Default 25, max 50.
`offset`	No	Pagination offset.
`keywords`	No	Free-text keyword filter (e.g. "sjönära", "balkong").
`location`	No	Free-text place name (e.g. "Vasastan", "Göteborg") resolved to its top Hemnet location. Ignored when `location_ids` is set.
`price_max`	No	SEK
`price_min`	No	SEK
`rooms_max`	No
`rooms_min`	No
`location_ids`	No	Numeric Hemnet location ids (from hemnet_autocomplete_location). Provide this OR `location`.
`living_area_max`	No	m²
`living_area_min`	No	m²
`housing_form_groups`	No	Property-type groups: HOUSES (villa), APARTMENTS (lägenhet/bostadsrätt), ROW_HOUSES (radhus/parhus), VACATION_HOMES (fritidshus), PLOTS (tomt), OTHERS.

TDQS

A4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint. The description reinforces read-only and mentions return fields, but adds no new behavioral details such as rate limits or pagination behavior. Value added is minimal beyond annotations.

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?

Four short sentences, no fluff. The purpose is front-loaded, and every sentence adds essential information. Efficiently communicates what the tool does and its key parameters.

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 13 parameters and no output schema, the description explains return structure (price, fee, m², etc.) and the location input options. It could mention sort/limit/offset but those are well-defined in schema. Adequate for an agent to invoke correctly.

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 85%, so baseline is 3. The description summarizes filter types (price band, rooms, etc.) and clarifies the location_ids vs location distinction, but most parameter details are already in the schema. No significant added meaning.

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 clearly states the tool searches active for-sale listings by location and optional filters, returning summaries. It distinguishes itself from siblings like hemnet_autocomplete_location and hemnet_search_sold by mentioning location_ids from autocomplete and focusing on for-sale listings.

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

Usage Guidelines4/5

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

The description provides clear context: use for active for-sale listings, provide location_ids or free-text location, and notes it is read-only. It implies not for sold listings (by contrast to hemnet_search_sold) but does not explicitly state when not to use or mention alternatives.

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

hemnet_search_soldSearch Hemnet sold listings (slutpriser)A

Read-onlyIdempotent

Search SOLD property listings ("slutpriser") on hemnet.se by location and optional filters. Each result carries the achieved final price, the asking price, and the over/under-asking percentage — the core comps signal for valuation. Provide location_ids (from hemnet_autocomplete_location) or a free-text location. Read-only.

ParametersJSON Schema

Name	Required	Description
`sort`	No	NEWEST (default) or OLDEST.
`limit`	No	Default 25, max 50.
`offset`	No	Pagination offset.
`keywords`	No	Free-text keyword filter (e.g. "sjönära", "balkong").
`location`	No	Free-text place name (e.g. "Vasastan", "Göteborg") resolved to its top Hemnet location. Ignored when `location_ids` is set.
`price_max`	No	SEK
`price_min`	No	SEK
`rooms_max`	No
`rooms_min`	No
`location_ids`	No	Numeric Hemnet location ids (from hemnet_autocomplete_location). Provide this OR `location`.
`living_area_max`	No	m²
`living_area_min`	No	m²
`housing_form_groups`	No	Property-type groups: HOUSES (villa), APARTMENTS (lägenhet/bostadsrätt), ROW_HOUSES (radhus/parhus), VACATION_HOMES (fritidshus), PLOTS (tomt), OTHERS.

TDQS

A4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint; description adds the core comps signal as output context, but does not elaborate on pagination, sorting, or rate limits. For a read-only tool, the description adds some value beyond annotations.

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?

Two sentences that front-load the purpose and key outputs. Every clause is informative; no redundant or unnecessary words.

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?

Despite 13 parameters and no output schema, the description covers the essential inputs and outputs for a search tool. Could mention default sorting but schema covers it; overall adequate.

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 85%, so parameters are mostly self-explanatory. The description adds value by explaining the relationship between location_ids and location, but does not provide additional semantic meaning for other parameters beyond what the schema offers.

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?

Description clearly states verb 'Search' and resource 'SOLD property listings', specifies the key output signals (final price, asking price, over/under-asking percentage), and distinguishes from siblings like hemnet_search_listings and hemnet_get_sold_listing.

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

Usage Guidelines4/5

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

Provides clear context on how to provide location (location_ids from a sibling tool or free-text), but does not explicitly state when to use this tool vs alternatives like scanning active listings or fetching a single sold listing.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

33 tool updatesv0.2.0Jul 9, 2026
- Addedhemnet_autocomplete_location
- Addedhemnet_calculate_mortgage
- Addedhemnet_compare_listings
- Addedhemnet_get_by_address
- Addedhemnet_get_listing
- Addedhemnet_get_listing_photos
- Addedhemnet_get_market_stats
- Addedhemnet_get_sold_listing
- Addedhemnet_healthcheck
- Addedhemnet_search_listings
- Addedhemnet_search_sold
- Removedofw_create_event
- Removedofw_create_expense
- Removedofw_create_journal_entry
- Removedofw_delete_draft
- Removedofw_delete_event
- Removedofw_download_attachment
- Removedofw_get_expense_totals
- Removedofw_get_message
- Removedofw_get_notifications
- Removedofw_get_profile
- Removedofw_get_unread_sent
- Removedofw_list_drafts
- Removedofw_list_events
- Removedofw_list_expenses
- Removedofw_list_journal_entries
- Removedofw_list_message_folders
- Removedofw_list_messages
- Removedofw_save_draft
- Removedofw_send_message
- Removedofw_sync_messages
- Removedofw_update_event
- Removedofw_upload_attachment
22 tool updatesv2.4.4Jul 9, 2026
- First observedofw_create_event
- First observedofw_create_expense
- First observedofw_create_journal_entry
- First observedofw_delete_draft
- First observedofw_delete_event
- First observedofw_download_attachment
- First observedofw_get_expense_totals
- First observedofw_get_message
- First observedofw_get_notifications
- First observedofw_get_profile
- First observedofw_get_unread_sent
- First observedofw_list_drafts
- First observedofw_list_events
- First observedofw_list_expenses
- First observedofw_list_journal_entries
- First observedofw_list_message_folders
- First observedofw_list_messages
- First observedofw_save_draft
- First observedofw_send_message
- First observedofw_sync_messages
- First observedofw_update_event
- First observedofw_upload_attachment

Install Server

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

TDQS

A4.4/5.0

Scored 2026-07-09 20:45 across 11 tools

Disambiguation5/5

Each tool targets a distinct function: location autocomplete, active/sold search, listing detail, photos, comparison, address resolution, mortgage calculation, market stats, and health check. No two tools have overlapping purposes; even similarly named tools (e.g. get_listing vs get_sold_listing) are clearly differentiated by the sold vs active context.

Naming Consistency5/5

All tool names follow a consistent 'hemnet_verb_noun' pattern without mixing conventions. Examples include 'autocomplete_location', 'search_listings', 'get_listing', 'calculate_mortgage'. Even 'healthcheck' conforms as a single-word noun.

Tool Count5/5

With 11 tools, the set is well-scoped for a real estate data server. Each tool addresses a specific need (search, detail, comparison, market stats, mortgage calculation) without being excessive or sparse.

Completeness5/5

The tool set covers the full lifecycle of property research: location lookup, searching active and sold listings, retrieving detailed data and photos, comparing listings, resolving addresses, calculating mortgages, and accessing aggregate market statistics. No obvious gaps exist for the intended read-only use case.

Maintenance

ActivityActive

ResponsivenessResponsive

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237
QuallaaOAuth
com.quallaa
Talk to your public-facing AI from any MCP client — Claude, ChatGPT, Cursor, Cline, Windsurf.
AI & Machine Learning Communication
2
Artificial Wit AIOAuth
com.artificialwit
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
ERP Systems CRM Knowledge & Memory
2
cliniko A
io.usefulapi
Hosted MCP server for Cliniko — patients, appointments, availability, and invoices for AI agents.
Biology & Medicine Calendar Management CRM
172

Related MCP Servers

Google Calendar MCP Server
Calendar Management App Automation
takumi0706
A
license
A
quality
A
maintenance
A Model Context Protocol server that integrates Google Calendar with Claude Desktop, enabling users to manage calendar events (view, create, update, delete) through natural language.
Updated 22 days ago (2026-08-18 03:51 UTC)
5
114
58
MIT
whoop-mcp
Health & Wellness Fitness Tracking
souravpn
A
license
Not graded
quality
D
maintenance
A Model Context Protocol (MCP) server that gives Claude access to your WHOOP biometric data — recovery, sleep, strain, and workouts.
Updated 3 months ago (2026-05-27 06:47 UTC)
28
MIT
Withings MCP Server
Health & Wellness Fitness Tracking
akutishevsky
A
license
Not graded
quality
A
maintenance
A Model Context Protocol (MCP) server that brings your Withings health data into Claude, allowing natural conversation access to sleep patterns, body measurements, workouts, heart data, and more.
Updated 10 days ago (2026-08-30 08:07 UTC)
41
MIT
ActivityWatch MCP Server
Monitoring Workplace & Productivity
Jelloeater
A
license
Not graded
quality
C
maintenance
A Model Context Protocol (MCP) server that connects to ActivityWatch, allowing LLMs like Claude to interact with your time tracking data.
Updated 3 months ago (2026-06-13 19:06 UTC)
4
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/chrischall/hemnet-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server