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 reinforces 'Read-only' and adds the useful behavioral detail that both active and sold properties are supported, but it does not add substantial new behavioral context beyond that.

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 three short sentences with no filler. The core purpose is front-loaded, and every sentence earns its place by conveying scope, input origin, or safety.

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 simple single-resource getter, this is complete: it names the required identifier, defines its provenance, notes optional response shape via the view parameter, and states applicability to active and sold properties. An output schema is absent, but the description's 'full detail' plus the view parameter documentation is sufficient for 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?

Schema description coverage is 100%, so the baseline is 3. The description adds a small but real semantic cue by explaining that residence_id can come from either a booli.se/bostad/<id> URL or a search result's residence_id field, which helps the agent source the value correctly.

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 and resource: 'Full detail for one property by its Booli residence id.' It clearly identifies the lookup key and distinguishes this from the sibling search/stats/health tools, which do different jobs.

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 tells the agent the precondition for use: the agent must already have a Booli residence id, either from a URL or a search result. It also clarifies that the tool works for both active and sold properties. It does not explicitly name alternative tools for cases where no id is available, but the context and sibling names make this reasonably clear.

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?

Goes well beyond the annotations by enumerating the returned diagnostics (bridge role, port, version, extension link state, elapsed time) and enumerating the failure classes the hint distinguishes (bridge never came up / extension not connected / browser can't serve capability / server-side problem). It also confirms 'no auth required'. This is real behavioral context an agent cannot infer from readOnlyHint/idempotentHint alone.

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 dense sentence plus a short routing instruction, front-loaded with the action and ending with the failure-mode enumeration. The list of diagnostics is long but each item earns its place; the only minor cost is one very overloaded sentence.

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 carries the full burden of explaining what comes back, and it does so comprehensively – listing every diagnostic field and the interpretive hint. Nothing needed to call or interpret this tool 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?

The tool takes zero parameters, so the baseline is 4. There is nothing for the description to disambiguate beyond confirming the call is parameter-free, which it implicitly does by describing a self-contained round-trip.

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 action (round-trips a public booli.se URL through ContextMint Bridge), the exact resource (/graphql), and the nature of the result (diagnostics). It is unmistakably a health/diagnostic tool, distinct from the listing/search/stats siblings, without opening any schema.

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?

Explicitly says when to call it: 'Call this when a real tool fails and you want to know which hop broke.' That is a clear trigger condition and implicitly positions it as a fallback to the other booli_* tools.

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 mark readOnlyHint=true, so the description's 'Read-only' is redundant. However, it adds valuable behavioral context: the tool operates over exactly one page of results and warns about sample_size affecting median reliability. These are not derivable from annotations or schema, so they meaningfully disclose behavior.

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-loads the purpose, and includes the key caveat about sample_size. Every sentence carries meaning with no filler or repetition of schema details. It is appropriately concise for the tool's complexity.

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?

Given the tool has 22 parameters, no output schema, and is a read-only aggregation, the description is sufficient. It explains what it returns, its relationship to booli_search_sold, and a practical trust caveat. It does not detail return structure or pagination beyond one page, but that is reasonably implied. For an aggregation tool with this complexity, it is well-rounded.

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 (82%), so the schema already documents most parameters. The description adds no per-parameter detail, but it references that the tool shares the same filters as booli_search_sold, which implies parameter reuse. Since the schema covers the parameters, a baseline of 3 is appropriate; the description adds marginal value 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 opens with a specific verb ('Aggregate') and a clear resource ('sold-price statistics'), and explicitly lists the derived metrics (median/average final price, price per m², average over/under-asking %). It also differentiates from sibling tools by referencing booli_search_sold as the scope basis, so an agent can distinguish it from listing retrieval.

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 tool takes 'the same scope and filters as booli_search_sold', giving clear context on when to use it (for aggregate stats on a page of sold results). It also adds a practical tip ('Check sample_size before trusting a thin median'). It does not explicitly name alternatives or exclusions, but the reference to booli_search_sold implicitly routes away from listing tools.

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 annotations already cover safety with readOnlyHint, idempotentHint, and openWorldHint, lowering the bar. The description adds some behavioral context by specifying that it returns municipalities, districts, and streets each with an `area_id`, but 'Read-only' merely repeats what readOnlyHint already declares. It does not disclose ambiguity handling, multiple match behavior, or other runtime quirks.

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 core sentence is dense, front-loaded, and contains the essential purpose, output types, and downstream usage in one line. The trailing 'Read-only.' is redundant with the annotations but is harmless; the overall definition is compact and efficient.

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 simple two-parameter resolver with safe annotations, the description is largely complete: it explains the input, the output types, and how the output is consumed by sibling tools. Because there is no output schema, it would be slightly stronger to state what happens on no match or how many areas may be returned, but the essential calling context is present.

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%, so the schema already explains both `query` and `limit`. The description reinforces that `query` is a place name and that the result carries `area_id`, but it does not add meaningful parameter-level detail beyond what the input schema provides, 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.

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

The description uses a specific verb ('Resolve') plus a clear resource ('place name to Booli areas') and names the concrete output types: municipalities, districts, streets. It also differentiates the tool by stating that the resulting `area_id` feeds into booli_search_listings / booli_search_sold, so an agent can distinguish it from its siblings without opening their 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 gives clear context for when to use the tool: resolving a place name before searching listings or sold data via the returned `area_id`. It names the downstream tools, which implies the intended workflow, but it does not explicitly state when not to use this tool or name a direct alternative.

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 and openWorldHint=true, and the description reinforces this with 'Read-only.' It adds behavioral context beyond annotations by describing pagination ('Paginated by `page`; check `total_count`/`pages`') and the scoping rule ('area_id ... OR location'). No contradictions; the description complements the annotations with operational detail.

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, no wasted words. The purpose is stated first, then scoping, then filters, then pagination. Every clause earns its place. The structure is front-loaded with the most important information and reads naturally.

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 20-parameter search tool with no output schema, the description covers the core behaviors: what it searches, how to scope, what filters exist, and how pagination works. It references a sibling for area_id resolution. It doesn't mention authentication or rate limits, but those are not essential for selection. The description is sufficient for an agent 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 description coverage is 80%, so the baseline is 3. The description adds value by explaining the relationship between area_id and location (location ignored when area_id is set), and by grouping filters by category (price, rooms, living area, etc.). It also clarifies that area_id comes from booli_search_areas, which is not in the schema. This goes beyond the schema's per-parameter descriptions, warranting a 4.

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 precise verb+resource: 'Search active for-sale property listings on booli.se.' It distinguishes itself from siblings by the 'active for-sale' qualifier, which sets it apart from booli_search_sold (sold listings), booli_get_listing (single listing), and the others. An agent can tell exactly what this tool does and when to reach for it.

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 gives clear context: it's for active for-sale listings, and it even references booli_search_areas for obtaining area_id. It implies the 'when' (when you need active listings) but does not explicitly state exclusions like 'use booli_search_sold for sold listings.' However, the 'active' qualifier and the sibling names make the usage boundary evident, so it's clear enough without being exhaustive.

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 and openWorldHint, and the description reinforces safety with 'Read-only.' It adds useful behavioral context beyond annotations by specifying the result includes achieved final price and over/under-asking %, plus pagination by page. No contradictions with annotations are present.

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 core purpose before filter details. It earns its place overall, though 'Read-only' repeats the annotation and the single long sentence could be split for slightly easier parsing.

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 22 optional parameters and no output schema, the description plus schema covers scope selection, filter dimensions, pagination, and key return fields. An agent can determine how to invoke the tool, though deeper output-shape details are left unspecified.

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 at 82%, so the baseline is 3. The description adds a helpful high-level grouping of scope by area_id/location and filter categories, but it does not add substantial new parameter meaning beyond what the schema already documents for the remaining parameters.

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 and resource: searching sold properties (slutpriser) on booli.se. It also adds distinguishing scope by mentioning achieved final price and over/under-asking %, positioning it as the comparables tool next to siblings like booli_search_listings and booli_market_stats.

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 phrase 'the comparables for valuation' gives clear context for when this tool is the right choice. It does not explicitly name alternatives or exclusion conditions, but the sold-property framing strongly separates it from active listing or stats siblings.

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