OurFamilyWizard MCP

by chrischall

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v2.4.4
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.
Average 4.3/5 across 11 of 11 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 3 of 3 community issues answered or closed in the last 6 months
- 30 commits in the last 12 weeks
- Last stable release on August 6, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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.
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.
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.
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.
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, indicating safe, idempotent behavior. Description adds concrete behavioral details: it performs a round-trip query and reports specific outputs (reachability, elapsed time, hint). This provides useful context beyond the structured fields.
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 20-word sentence that immediately states the action and outputs. It is front-loaded, concise, and contains no superfluous information.
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 no output schema, the description explains the three reported items. It is complete for a simple health check tool. However, it could briefly clarify what 'hint' means (e.g., error details), but this is a minor gap.
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?
No parameters in the input schema, so the description has no need to elaborate on parameter semantics. Baseline for zero parameters is 4. The description is sufficient.
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 tool performs a health check on the Hemnet GraphQL endpoint, with a specific verb ('round-trips') and resource ('hemnet.se GraphQL'). It reports three outputs (reachability, elapsed time, hint). This distinguishes it from all sibling tools which serve functional purposes like searching or getting 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 implies usage: use to verify endpoint availability before other queries. However, no explicit guidance on when to use vs alternatives or when not to use. Sibling tools are all different, so selection is clear by purpose, but the description could be improved by stating 'Use this to check if the Hemnet API is reachable before making other calls.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
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.
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.
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.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![hemnet-mcp MCP server](https://glama.ai/mcp/servers/chrischall/hemnet-mcp/badges/card.svg)](https://glama.ai/mcp/servers/chrischall/hemnet-mcp)

Score Badge

Copy to your README.md:

[![hemnet-mcp MCP server](https://glama.ai/mcp/servers/chrischall/hemnet-mcp/badges/score.svg)](https://glama.ai/mcp/servers/chrischall/hemnet-mcp)

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