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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so safety is covered. The description adds that results are ranked and enumerates returned fields, but it does not disclose ranking criteria, no-match behavior, or ambiguity handling; this is adequate but not rich.

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

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

The description is compact and front-loaded with the action, and the return fields plus downstream usage are useful. The final 'Read-only.' is mildly redundant with readOnlyHint=true, so it is not completely waste-free.

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

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

For a two-parameter lookup tool with rich annotations, the description is complete: it states the input shape, names the returned fields, and explains how to consume the result. Since there is no output schema, explicitly listing location_id, full_name, and parent_full_name gives the agent enough to call it correctly.

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

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

Schema coverage is 100% and both parameters already have descriptions, so the baseline is 3. The description adds meaning by explaining that query is a free-text place name and enumerating acceptable location levels (municipality, district, or area), which is more precise than the schema's bare 'Place name' label.

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

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

The description opens with a specific verb and object ('Look up Hemnet location ids') and scopes the input to free-text place names such as municipality, district, or area. It clearly differentiates this from sibling tools like hemnet_search_listings and hemnet_get_listing, which operate on listings rather than resolving location identifiers.

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

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

It states the intended workflow by telling the agent to feed the returned location_id into hemnet_search_listings or hemnet_search_sold, giving clear context for when to use this tool. It does not explicitly name alternatives or list when not to use it, so it stops short of a 5.

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

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

Beyond the readOnly/idempotent annotations, the description discloses that the tool is local-only, makes no network call, applies Swedish amortisation rules as of 1 April 2026, handles after-tax deductions (ränteavdrag), and ignores the deprecated income parameter. This is rich behavioral context and contradicts nothing in 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.

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

The description is information-dense but compact: purpose, output breakdown, key parameter rule, and side-effect note all fit in three sentences. Each sentence contributes meaning and important facts are front-loaded.

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

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

Despite having eight parameters and no output schema, the description explains the return composition, currency, and tax treatment, while the schema covers all parameter details. An agent has everything needed to decide when to call it and what response shape to expect.

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

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

Schema coverage is 100%, so the schema already documents each parameter. The description adds useful semantic value by stating the down_payment OR down_payment_percent choice and the legal 10% default, which is not obvious from the JSON schema alone.

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

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

The description opens with a specific verb and resource: 'Local-only Swedish mortgage calculator,' then lists exactly what the tool returns (interest, amortisation, BRF fee, operating cost, gross and after-tax totals). It is clearly distinct from sibling listing/search/photo tools, which all concern property lookup rather than calculation.

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

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

It supplies clear context for invocation: Swedish property purchase in SEK, with the legal 10% down-payment default and the choice between down_payment and down_payment_percent. Because no sibling performs mortgage calculation, there is no need for an explicit alternative; 'No network call' and 'Local-only' further signal the intended use as a pure calculator.

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

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

Beyond the annotations (readOnly, openWorld, idempotent), the description adds meaningful behavioral constraints: up to 20 targets, input order is preserved, per-row errors are captured, and the operation is read-only. This gives the agent useful execution expectations without contradicting 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.

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

Two sentences convey purpose, accepted input format, cardinality, ordering behavior, error handling, and read-only nature. Every clause earns its place and the most important info is front-loaded.

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

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

For a single-parameter tool with rich annotations and a fully documented schema, the description covers the key operational details: what it does, what inputs it accepts, limits, order preservation, and error behavior. No critical gap prevents correct invocation.

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

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

The schema fully documents the ids parameter, so the baseline is 3. The description adds value beyond the schema by stating that input order is preserved and that each row can have its own captured error, which affects how the agent should interpret the array parameter and results.

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

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

The description states a specific verb ('fetch and normalise') and a specific resource ('multiple active for-sale Hemnet listings'), and clarifies the purpose: side-by-side comparison. This clearly distinguishes it from single-listing siblings like hemnet_get_listing and sold-listing tools like 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.

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

The description makes the intended context explicit: use it when you need multiple active listings at once for comparison. It does not explicitly name sibling alternatives or state when not to use it, but the context is clear enough for an agent to select it appropriately.

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

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

Beyond the readOnlyHint/openWorldHint/idempotentHint annotations, the description adds meaningful behavioral detail: it scans up to 500 listings, a miss with truncated: true is not definitive, and matches include a score and matched_via. 'Read-only' and 'live … listing' align with the annotations; there is no contradiction.

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

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

Four sentences front-load the core purpose, then cover inputs, output shape, and the truncation caveat in logical order; every sentence earns its place. The only waste is the trailing 'Read-only,' which duplicates the readOnlyHint annotation.

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

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

With no output schema, the description rightly takes on the job of spelling out return values—matched: true, score, matched_via, or { resolved: false }—and explains the failure mode plus mitigations. Minor gaps remain: the fields inside a matched listing and how matched_via is populated, which an agent would need to chain to hemnet_get_listing.

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

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

Schema description coverage is 100% with worked examples ('Gäddstigen 1', 'Södertälje', 'Vasastan'), so the baseline is 3. The description adds modest value by linking price_min/price_max to 'narrowing the search rung' in the truncation caveat, but this is incremental to what the schema already documents.

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

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

The description uses a specific verb-resource pair—'Resolve a free-text Swedish street address to a live Hemnet for-sale listing'—and immediately distinguishes itself from siblings like hemnet_search_listings (broad search) and hemnet_get_listing (fetch by ID). It states what goes in (address + location) and what comes out, so an agent cannot mistake its job.

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

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

The use case is explicit: call this when you have a free-text street address and want the matching live for-sale listing. It also gives concrete conditional guidance—on a truncated miss, narrow with price_min/price_max or a smaller location—but it never names sibling alternatives or states when not to use it (e.g., sold listings via hemnet_search_sold), leaving some routing to inference.

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

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

Annotations already provide readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is clear. The description adds the active-only scoping and the sold-listing exclusion, but otherwise mostly enumerates return fields and repeats 'Read-only' rather than disclosing additional behavioral traits like rate limits, error cases, or URL/detail variations.

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

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

Three sentences with no wasted words: purpose, return contents, and alternative routing. The long list of returned fields is dense but valuable given there is no output schema, and the most important scoping information is front-loaded.

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

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

For a read-only, two-parameter single-listing tool, this is complete. The return field list compensates for the missing output schema, the id/URL input is documented in the schema, annotations cover safety behavior, and the sold-listing exception is explicitly handled. Nothing essential for invoking the tool correctly is missing.

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

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

Schema description coverage is 100%: both id and photo_limit are clearly documented in the input schema, including the id-or-URL form and the default/maximum for photo_limit. The description adds no semantic detail beyond the schema, so it neither improves nor harms the parameter story.

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

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

The description opens with a specific verb ('Fetch') and resource ('full detail of a single active for-sale listing'), and identifies the input mechanism ('by its Hemnet id or a /bostad/ URL'). It also distinguishes itself from the sold-listing sibling directly, so an agent can select it correctly without opening schemas.

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

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

The description explicitly tells the agent to use hemnet_get_sold_listing for sold listings, and the 'active for-sale' phrasing makes the scope clear. However, it does not mention when to prefer hemnet_get_listing_photos or hemnet_get_by_address over this tool, leaving some sibling-routing implicit.

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

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

The readOnlyHint and idempotentHint annotations already cover the safety profile, and the description reinforces it with 'Read-only' while adding an active-for-sale constraint. It does not, however, disclose failure behavior for invalid or inactive listing IDs, nor the shape of the returned URL collection.

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

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

A single front-loaded sentence states the action, resource, scope, and accepted input form with no filler. Every phrase earns its place.

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

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

For a two-parameter read-only tool with a fully described schema and annotations, this is nearly complete: it names the return concept (photo URLs), restricts to active for-sale listings, and tells how to specify the listing. It only lacks an explicit note about response format/empty results and sibling routing.

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

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

The input schema already documents both parameters at 100% coverage, including that id can be an id or a full /bostad/ URL and that limit has a default of 50. The description adds no parameter meaning beyond the schema, so the baseline of 3 applies.

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

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

The description uses a specific verb and resource: it returns gallery photo URLs for active for-sale Hemnet listings, and it accepts either an id or a /bostad/ URL. This scope clearly separates it from sibling tools like hemnet_get_listing and hemnet_get_sold_listing, even though no sibling is named.

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

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

It clearly states the intended context: active for-sale listings requiring photo URLs, which implies it is not for sold/inactive listings. It does not explicitly name alternatives such as hemnet_get_listing for full details, so it stops just short of full when/when-not guidance.

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

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 without contradiction. The description adds context about the data source ('recent SOLD listings') and the computed metrics, but it does not disclose additional runtime behavior such as pagination behavior, response shape, or what happens when a free-text location cannot be resolved.

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

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

The description is compact and front-loaded: it opens with the core purpose and the exact statistics returned before moving to input guidance. It has no filler, though 'Read-only' mildly repeats the readOnlyHint annotation.

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

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

For a 13-parameter tool with no output schema, the description supplies the key call pattern (location_ids or location), the optional filter dimensions, and the return metric set. It does not detail output structure or edge cases like both location inputs being supplied, but the schema covers most of the remaining operational details.

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

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

Schema description coverage is 85%, so the schema already documents nearly all parameters in detail. The description reinforces the key choice between location_ids and location and mentions property-type/size filters, but it adds no syntax or semantic information beyond what the schema provides.

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

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

States a specific operation ('Aggregate median/average statistics from recent SOLD listings') and names the resource/scope: a location with optional property-type/size filters. This clearly differentiates it from sibling tools like hemnet_search_sold and hemnet_get_sold_listing, which return individual listing records rather than aggregate market statistics.

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

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

The description explains the core input requirement ('Provide location_ids or a free-text location') and mentions optional filters, but it never explicitly tells an agent when to choose this tool over hemnet_search_sold or when not to. Usage is implied by the aggregate-statistics framing rather than stated as a rule with exclusions.

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

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

Annotations already establish read-only, open-world, and idempotent behavior. The description adds useful context by enumerating the returned data: final price, asking price, price change, m², rooms, tenure, broker, and coordinates. There is no contradiction and no hidden mutation or side-effect concern.

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

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

The description is two sentences, front-loaded with the operation and input form, and followed by a compact list of return fields. Every sentence earns its place with no filler or redundant explanation.

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

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 with no output schema, the description is complete: it states the accepted input forms and the main returned data fields. An agent has enough information to select the tool, invoke it, and understand the expected result.

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

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

Schema coverage is 100%, and the schema description already states that id is either a Hemnet sold-listing id or a full hemnet.se /salda/ URL. The tool description repeats the accepted input forms but adds no new format, validation detail, or examples beyond the schema.

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

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

The description uses a specific verb ('Fetch'), names the exact resource ('SOLD listing'), and specifies both accepted input forms (Hemnet id or /salda/ URL). The 'SOLD' qualifier clearly distinguishes this from sibling tools like hemnet_get_listing and 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.

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

The description clearly implies this is for retrieving full detail of a single sold listing when an id or URL is already known, rather than for searching or listing multiple results. It does not explicitly name alternatives or state when not to use it, so it stops short of full top-tier guidance.

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

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

Beyond the readOnly/openWorld/idempotent annotations, the description discloses that it makes a real round-trip, requires no auth, and reports hop-level failure categories (bridge never came up vs extension not connected vs remote-side problem). This is useful behavioral context that annotations alone do not provide.

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

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

The description is a single dense paragraph, but each clause earns its place by naming a diagnostic field or the invocation condition. It front-loads the action and output before the usage guidance.

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

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

For a no-parameter diagnostic tool with no output schema, the description fully specifies the returned diagnostics and the failure classes it can distinguish. Combined with the annotations and sibling list, an agent has everything needed to call and interpret it.

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

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

The tool has zero parameters and the schema coverage is 100%, so there is no parameter meaning for the description to add. Baseline 4 applies for a parameterless tool; no further documentation is needed.

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

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

The description names a concrete action (round-trips a public /graphql URL through the fetchproxy bridge) and the output (diagnostics about role, port, version, link, latency, and a plain-English fault hint). This distinguishes it sharply from the listing/search siblings, which are data-retrieval tools rather than infrastructure diagnostics.

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

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

It gives an explicit trigger: "Call this when a real tool fails and you want to know which hop broke." That tells an agent exactly when to invoke it and frames it as a diagnostic fallback, separate from normal Hemnet lookups.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=true. The description adds useful context beyond those: it only searches active listings, returns listing summaries with specific fields, and is read-only. No contradiction with annotations.

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

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

Three sentences with no filler. The purpose, key inputs, return content, and safety posture are all front-loaded and concise.

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

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

For a 13-parameter read-only search tool with strong schema coverage and no output schema, the description is sufficiently complete. It names the return fields and the required location mechanism; pagination and defaults are already covered by the schema. It does not describe error cases or result-count limits, but those are minor given the schema and annotations.

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

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

Schema description coverage is high (85%), and the schema already documents most parameter units and meanings. The description summarizes filter categories (price, rooms, area, property-type groups, keywords) but does not add substantial meaning beyond the schema.

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

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

States a specific verb ('Search'), resource ('active for-sale property listings on hemnet.se'), and scope ('by location and optional filters'). The phrase 'active for-sale' clearly distinguishes it from hemnet_search_sold 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.

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

Gives actionable guidance on the two mutually exclusive location inputs: use `location_ids` from hemnet_autocomplete_location or free-text `location`. It does not explicitly name a sibling alternative for sold listings, but 'active for-sale' makes that distinction clear enough.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds useful behavioral context beyond that: it confirms read-only behavior and reveals what each result carries (final price, asking price, over/under-asking percentage). It does not contradict annotations.

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

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

Three short sentences: what the tool does, what the results mean, and how to specify the location. It is front-loaded and every sentence contributes essential information without redundancy.

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

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

For a read-only search tool with no output schema, the description covers what matters most: the returned comps signal, the location input pattern, and the read-only nature. The 13 optional parameters are adequately documented in the input schema, so the description does not need to enumerate them.

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

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

With 85% schema description coverage, the schema already documents most parameters. The description adds meaningful relational guidance: `location_ids` comes from hemnet_autocomplete_location and is an alternative to free-text `location`. It also adds the output semantics that make the parameters (price filters, location) relevant to valuation.

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

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

The description uses a specific verb ('Search') and a well-defined resource ('SOLD property listings (slutpriser) on hemnet.se'), immediately differentiating it from active-listing search and singular listing lookup. The mention of achieved price, asking price, and over/under percentage clarifies the specific comps-focused purpose.

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

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

The description clearly states how to specify the search scope: provide `location_ids` from hemnet_autocomplete_location or a free-text `location`. It does not explicitly say 'use hemnet_search_listings for active listings', but the SOLD designation and search semantics make the intended context clear.

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