immoswipe-ai

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

With no annotations provided, the description carries the behavioral burden and does well: it names the data sources (BFS vacancy, rent, ZKB market data), the score range, and that it suggests alternative regions. It also implies this tool only checks chances and that registration happens separately via join_tenant_pool, which is useful side-effect context.

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, front-loaded with the purpose, and every clause adds value: what it does, what it uses, the score range, an example, and the next step. No filler or 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 tool with 10 parameters and no output schema, the description conveys the core outcome, example input, data provenance, and follow-up action. It does not detail the response structure beyond the 0–100 score and alternatives, but that is arguably sufficient for selecting and invoking the tool 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 90%, so the schema already documents the parameters. The description adds contextual meaning by linking the query example to a 'search profile', but it does not explain individual parameters beyond the schema baseline.

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 ('rates chances'), a precise resource (rental market chances from a search profile), and a concrete output (tenant score 0–100 plus alternative region suggestions). This clearly distinguishes it from sibling listing, FAQ, and pool tools.

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?

Provides an explicit example query ('how are my chances of finding a 3.5-room flat in Zürich for 2200') and a follow-up action via join_tenant_pool. It does not explicitly state when not to use it or name alternatives, but the context is clear enough for an agent to select it.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Get FAQs' and lists topics, but does not state that the tool returns a list, supports filtering by role/locale, or describe any side effects. The agent cannot infer behavior beyond basic retrieval, making it insufficiently transparent.

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 sentence that is front-loaded with the action ('Get Immoswipe FAQs') and concisely lists the FAQ categories. No wasted words or redundant detail.

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 simple nature of the tool, the description covers the basic purpose, but with no output schema and no annotations, it does not explain response format, how role/locale affect results, or filtering behavior. These gaps are moderate for a straightforward FAQ retrieval task.

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 describes two of three parameters (role and search_by) with meaningful text, and locale is self-documenting via enum. The description itself adds no parameter-specific meaning, leaving the schema to handle parameter semantics. This is adequate but not enhanced.

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 clearly states the tool retrieves Immoswipe FAQs and specifies the covered topics (platform usage, renting, listing, photography/tour services, pricing). This distinguishes it from sibling tools like get_guide and search_guides, which handle guides rather than FAQs.

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 implies this is the tool for FAQ-related queries, but it does not explicitly say when to use it over alternatives or mention any when-not-to-use conditions. Context is clear from the topic (FAQs), but there is no explicit guidance about choosing this vs. other guide 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?

With no annotations, the description carries the disclosure burden. It implies a read-only operation via 'Read' and specifies the return format ('Markdown text'), but it doesn't mention locale behavior, error handling, or any side effects. It's 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 a single sentence with no wasted words, front-loaded with the action and resource. It's concise and well-structured.

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 read tool with two parameters and no output schema, the description is sufficient: it tells how to get the input and what to expect as output. However, it omits any mention of the optional locale parameter, which could be considered a minor gap.

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 description adds context to the slug parameter ('by slug', 'get the slug from search_guides'), reinforcing its purpose. However, the locale parameter is not mentioned at all, and since schema coverage is only 50%, the description only partially compensates for the gap.

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 clearly states the tool reads a specific guide/article by slug, with a specific verb ('Read') and resource ('Markdown text of a specific Immoswipe guide/blog article'). It distinguishes from siblings by explicitly referencing search_guides for obtaining the slug.

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 instructs to get the slug from search_guides, which implies a workflow: use search_guides first, then get_guide. This is clear context for when to use the tool, though it doesn't explicitly state when not to use it or mention 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?

With no annotations provided, the description carries the full burden. It discloses the type of data returned (amenities, pricing breakdown, contact info, images), which is useful. However, it does not mention potential error behavior, authentication requirements, or the read-only nature explicitly, leaving some transparency gaps.

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 primary purpose, and contains no filler or redundant information. Every word 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?

Given the tool's simplicity (2 params, no output schema), the description covers the essential return value details. It does not explain locale usage or error handling, but for a straightforward detail-fetching tool, it is sufficiently complete. Lacking annotations, it could be more thorough, but it meets the needs of most use cases.

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 50% (only listing_id has a description). The tool description adds 'by ID', reinforcing the meaning of listing_id, but it does not explain the 'locale' parameter at all. The description provides some additional context beyond the schema but does not fully compensate for the undocumented parameter.

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 clearly states a specific action ('Get full details') and a specific resource ('a specific property by ID'). It distinguishes itself from sibling tools like 'get_popular_listings' and 'get_similar_listings' by emphasizing the ID-based lookup, making its purpose unambiguous.

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 implies usage: use this when you have a specific property ID and need full details. However, it provides no explicit guidance on when to use this tool over alternatives like 'get_similar_listings' or 'search_listings', nor does it mention any exclusions or prerequisites beyond the ID.

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?

With no annotations provided, the description carries the behavioral disclosure burden. It discloses that data is public, aggregate only, contains no personal data, and provides the specific counters returned. It doesn't describe response formatting or failure modes, but for a simple stats tool it gives the key safety/scope behavior an agent needs.

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 concise: three short sentences, front-loaded with the core purpose, followed by privacy scope and a concrete usage scenario. Every sentence adds useful information and there is no filler or repetition.

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?

The tool is simple, takes no required parameters, and has no output schema, so the description bears the burden of explaining what is returned. It names both returned metrics (registered tenants and Chancen-Checks) and the recommended use case. The only notable gap is the meaning of the locale parameter, which keeps it from a perfect score.

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 has one optional 'locale' parameter with an en/de enum but no description, and the schema description coverage is 0%. The tool description does not explain what 'locale' affects or how to choose between 'en' and 'de'. That is a meaningful gap because the description could have noted that locale determines which language the returned labels/text use.

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 clearly identifies the tool as retrieving public pool counters: the number of registered tenants and the number of Chancen-Checks run. It uses specific, actionable language ('Public counters', 'how many tenants are registered') and distinguishes itself from siblings like join_tenant_pool because it is a read-only stats operation rather than a sign-up action.

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 provides explicit usage context: 'Use to show a tenant the pool size before offering the sign-up via join_tenant_pool.' This tells an agent when to call the tool. It doesn't explicitly state exclusion cases or compare it to alternative stats tools, but the intended placement in the flow is 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?

No annotations are provided, and the description gives no behavioral details beyond 'Fetch'. It does not disclose return format, sorting logic, pagination, or any data limitations, leaving the agent to infer 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 a single sentence that directly states the purpose without any fluff or redundant information.

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 simple one-parameter schema and lack of output schema, the description captures the main purpose but misses context around what 'popular' means and whether locale is required or optional. It is adequate but has clear gaps.

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 description does not mention the 'locale' parameter or how it affects results. The schema's enum for locale provides some semantics, but with 0% schema description coverage, the description fails to compensate.

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 clearly states a specific action ('Fetch') and resource ('most popular/trending Swiss property listings'), distinguishing it from sibling search tools like search_listings and get_similar_listings.

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?

No explicit usage guidance or alternative comparison is provided. The description implies use when trending listings are needed the description implies usage but does not explain when to choose this over other 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?

No annotations are provided, so the description carries the full burden. It states the tool returns blocked date ranges but does not clarify whether the returned ranges are filtered by the given from/to dates, how inclusive the boundaries are, or if locale affects output. Basic read-only nature is implied but not explicitly confirmed.

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 concise sentences with no filler. It is front-loaded with the action ('Check availability') and delivers the key information efficiently. Every word 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?

The description is short and leaves gaps: no output schema exists, and the description only vaguely says 'Returns blocked date ranges.' It does not specify the structure of the output, whether the date range parameters filter the results, or if there are any special behaviors. For a moderate-complexity tool, more detail would improve completeness, though it is not severely inadequate.

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 covers 75% of parameters with descriptions (listing_id, from_date, to_date), and the locale has an enum but no description. The tool description adds little beyond the schema, merely reinforcing 'specific property' and 'availability'. Since schema coverage is high, the baseline of 3 applies; the description does not significantly enhance parameter understanding.

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 clearly states the tool's function: 'Check availability/booking dates for a specific property.' It uses a specific verb ('check') and resource ('availability/booking dates'), and notes the output ('Returns blocked date ranges'). This distinguishes it from siblings like get_listing_detail or search_listings, which serve different purposes.

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 implies the usage context: you use this when you have a specific property and want to know its booked/blocked date ranges. However, it does not explicitly mention when not to use it or point to alternatives. The context is clear but exclusions are absent, which places it at a 4 rather than 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?

With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only states what the tool does, not how it behaves—no mention of read-only status, potential side effects, ordering, pagination, or result limits. The 'same area/category' clause is a semantic definition of similarity, but it does not disclose operational behavior. The agent remains unaware of any special constraints or response characteristics.

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, front-loaded sentence that efficiently communicates the core purpose and key criterion (same area/category). There is no redundancy or extraneous information; every word contributes meaning.

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 tool with no output schema and no annotations, the description is quite thin. It does not cover what the response structure looks like, whether results are paginated, how many similar listings are returned, or whether the original listing is excluded. Given the richness of the sibling tools (e.g., search_listings), this description is incomplete for an agent to rely on without additional assumptions.

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 50%: listing_id has a schema description ('Property ID'), but locale only has an enum with no explanatory text. The description adds no parameter-specific meaning beyond the schema—'given property' merely restates the concept of listing_id. It does not clarify what 'locale' affects (e.g., language of results). With marginal value added, the score is below the baseline of 3.

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 clearly states the verb 'Return' and the resource 'listings similar to a given property', and it adds the scope 'same area/category' which defines similarity. It is specific enough to distinguish from sibling tools like get_popular_listings or search_listings, though it does not explicitly name alternatives. This is a clear, non-tautological statement of 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 implies when to use the tool: when you have a property ID and need similar listings based on area/category. However, it provides no explicit guidance on when to prefer this over sibling tools like search_listings or get_popular_listings, nor any exclusion criteria. This is implied usage only, not clear contextual 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?

With no annotations, the description carries the full burden — it explicitly discloses 'WRITE operation with personal data' and the mandatory consent gate. This flags both the mutating nature and the privacy sensitivity of the operation. It doesn't mention post-registration side effects like account creation or confirmation emails, but the critical safety traits are disclosed.

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 with zero fluff: purpose, then critical safety warning, then workflow. The most important information (write nature, explicit consent, consent=true) is front-loaded ahead of the flow guidance. Every sentence 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 17-parameter tool with no output schema, the description covers the essential decision factors: what the operation does, when to call it, the consent requirement, and the ordering relative to check_rental_chances. It doesn't describe return values or post-registration outcomes (confirmation emails, account creation) which the agent might need, but the critical prerequisites are all 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 coverage is 59%, so the description partially compensates by emphasizing that consent must be true and by tying the score parameter to the check_rental_chances flow. However, it doesn't clarify the undocumented parameters (rooms, budget, income, locale, household, timeframe, location_type, workplace_address) beyond what their enum names imply. It adds value on consent but leaves the coverage gap unfilled.

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 (register) with a clear resource (Swiss tenant in Immoswipe Mieter-Pool) and a concrete purpose (property managers see profile and contact about matching units). It clearly distinguishes from all sibling tools, which are GET/search operations — only check_rental_chances is related, and the description explicitly differentiates the registration from 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?

Provides explicit when-to-use guidance: 'ONLY call after the user has EXPLICITLY agreed to join the pool' and 'Typical flow: run check_rental_chances first, then offer the sign-up.' It names the relevant sibling (check_rental_chances), orders the flow, and states the consent precondition, leaving nothing 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?

With no annotations provided, the description carries the disclosure burden. It states the return format (titles, slugs, links) and that get_guide is needed for full content, giving expectations about output. It doesn't explicitly say it's read-only, but 'Search' implies a safe read operation, so this is adequate.

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 with no fluff. It front-loads the verb and resource, gives practical examples, and ends with a clear pointer to a sibling tool. Every sentence 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 simple optional-parameter search tool, the description covers the purpose, usage, and output format. The main gap is the unexplained 'locale' parameter, which could affect search results. Otherwise, it is sufficiently complete for an agent to select and invoke 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 only 50%, so the description should compensate for undocumented parameters. It partially does by implying 'query' filters articles, but it never mentions the 'locale' parameter or its effect. The description adds little beyond the schema's existing query description.

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 clearly states the tool searches blog/guide articles about Swiss housing, with specific topics like renting tips and tenancy law. It distinguishes from siblings: get_guide reads full articles, and search_listings handles property listings, so the purpose is unambiguous.

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 explicitly says 'Use for "how to" / advice questions', giving a clear trigger for when to invoke this tool. It also directs users to get_guide for reading the full article, providing an actionable alternative for the next step.

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?

There are no annotations, so the description carries the full burden of behavioral disclosure. It only restates filter capabilities that are already present in the schema and gives example queries; it does not mention pagination behavior, output format, whether results are summaries or full listings, default ordering, or any side effects. 'Search' implies a read operation, but no concrete behavioral context is added.

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 sentences with no filler: it front-loads the action and resource, lists the key filter dimensions, and closes with useful examples. The second sentence partially overlaps with schema property descriptions, but the examples justify the extra length.

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 19 optional parameters, no annotations, and no output schema, the description provides only a broad orientation and relies heavily on the schema for parameter details. It does not clarify what a bare call returns, pagination defaults, or result object shape, leaving operational gaps. However, the schema's 100% parameter coverage and the examples make the tool usable enough for an agent to attempt a call, so this is adequate with clear gaps rather than deficient.

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 detailed descriptions for all 19 parameters, including units, enums, defaults, and examples for fields like address_city and per_page. The description adds only illustrative city names and natural-language query examples, which do not meaningfully extend the parameter semantics. Baseline 3 is appropriate because the schema does the heavy lifting.

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 ('Search Swiss apartments and houses for rent or sale') and then enumerates the main filter dimensions plus three concrete examples. It is clearly about a property search tool, but it does not explicitly set it apart from sibling tools like get_popular_listings or get_similar_listings, so it stops short of a 5.

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 examples imply that this is a general-purpose property search entry point, but there is no explicit statement of when to use search_listings versus alternatives such as get_listing_detail, get_popular_listings, or check_rental_chances. No exclusions or conditions are given, so the guidance is effectively absent beyond the tool's own existence.

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