Get a Hemnet for-sale listing by id or URL

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.