immoswipe-ai

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

With no annotations provided, the description carries the full transparency burden. It discloses data sources (BFS vacancy, rent, ZKB market data), the output (tenant score 0–100 and alternative regions), and the nature of the operation (a chances check, not a listing search). It does not mention side effects or limitations, but it is reasonably transparent for a computational tool.

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 and front-loaded, with two sentences that convey the core function, an example, and a related next step. Every sentence earns its place without repetition or fluff.

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 complexity (9 parameters, 5 required, no output schema), the description covers the essential aspects: what it does, how it works, an example use case, and a follow-up action. It might be enhanced by describing the response structure beyond the score and alternative regions, but the provided information is sufficient for an agent to select and invoke 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 89%, so the schema already documents most parameters. The description adds value by giving a natural language example that maps to parameters (location, rooms, budget) and by framing the tool as working 'from a search profile', clarifying that all input parameters collectively define the search. This is helpful beyond the individual parameter descriptions.

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 purpose: to rate rental market chances for Swiss tenants, producing a tenant score from 0–100 based on a search profile. It also distinguishes itself from siblings by explicitly mentioning unique features: using BFS and ZKB market data and suggesting alternative regions. This is a specific verb+resource+scope statement.

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 a concrete example query ('how are my chances of finding a 3.5-room flat in Zürich for 2200') and suggests a follow-up action (join_tenant_pool). This gives clear context for when to use the tool, though it does not explicitly list exclusions or alternative tools for other cases.

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?

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?

Since no annotations are provided, the description carries the burden of behavioral disclosure. It clearly states that this is a WRITE operation with personal data, requires explicit consent, and explains the downstream effect (property managers see the profile). It does not cover error cases or data retention, but the key behavioral trait of requiring consent is well emphasized.

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 the most critical information (purpose, consent requirement, typical flow) front-loaded. No redundancy or filler words.

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 14 parameters, no output schema, and no annotations, the description provides enough context for correct invocation: what it does, when to call, and the critical consent parameter. It could mention required parameters or post-invocation behavior, but for agent selection and invocation, it is sufficiently complete.

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 covers 50% of parameters, and the description adds crucial semantic detail for the consent parameter, explaining it must be true and derived from explicit user agreement. It also hints at the score parameter via the typical flow. However, it leaves most other parameters to the schema, which is partially documented. The description adds value but does not fully compensate for the remaining undocumented params.

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') and clearly identifies the resource ('Swiss tenant in the Immoswipe Mieter-Pool') and the purpose (so property managers see the profile and contact about matching units). It is distinct from the read-only sibling tools, which all query or retrieve data.

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 explicit usage constraints: 'ONLY call after the user has EXPLICITLY agreed' and 'consent must be true.' It also provides a typical flow, naming the sibling tool check_rental_chances as a prior step, which clarifies when this tool should be invoked relative to alternatives.

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?

No annotations exist, so the description must carry the full burden. It does not disclose that the tool expects structured parameters rather than natural language, and the examples ('apartments in Zurich under 2000') could mislead an agent into thinking free-text queries are accepted. It also omits return‐value shape, pagination behavior, or authentication 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 brief and front-loaded, with three sentences that state purpose, supported filters, and examples. No word is wasted, and the examples earn their place by showing realistic use cases.

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 13 parameters and no output schema, the description is insufficient. It fails to explain the bounds parameter, locale options, the 'serviced' price_type, whether city and bounds are mutually exclusive, or what the response contains. An agent would lack critical context for correctly invoking this tool.

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 baseline is 3. The description adds example intents and names additional cities (Bern, Basel) beyond the schema's examples, but it does not map examples to parameter names like address_city or max_monthly_price, limiting added value.

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 resource ('Swiss apartments and houses for rent or sale'), clearly defining the tool's scope. It also differentiates from siblings like get_listing_detail and get_popular_listings by focusing on search with filters.

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?

Clear context is provided: the tool is for searching listings with city, price, rooms, and square meter filters. The examples illustrate intended queries, though no explicit exclusions or alternative tool recommendations are mentioned.

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