Server Quality Checklist

Tool Scores

• booli_search_listingsA
  3.9/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds that the tool is read-only, paginated (via page param, check total_count/pages), and only returns active listings. This extra context about pagination behavior and listing status goes beyond what annotations provide, though it doesn't elaborate on rate limits or data freshness.

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

  Conciseness5/5

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

  Two sentences, no wasted words. First sentence conveys purpose and key scope/filter options; second covers pagination and read-only nature. Information is front-loaded and efficient.

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

  Completeness3/5

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

  Given 20 parameters and no output schema, the description adequately covers input usage and pagination hints (total_count/pages). However, it does not describe the output structure (e.g., each listing includes id, address, etc.), leaving a gap for an agent. Annotations (openWorldHint) partially compensate, but more detail on return format would improve completeness.

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

  Parameters3/5

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

  Schema coverage is 80% (16 of 20 parameters have descriptions). The description summarizes filter categories (price, rooms, living area, etc.) but adds no detailed semantics beyond what the schema already provides. Baseline of 3 is appropriate as the schema does the heavy lifting.

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

  Purpose5/5

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

  The description clearly states the tool searches 'active for-sale property listings' on booli.se, specifying the verb 'search' and resource 'listings'. It distinguishes from siblings like booli_search_sold (sold listings) and booli_get_listing (single listing) by focusing on active for-sale properties and referencing booli_search_areas for area IDs.

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

  Usage Guidelines3/5

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

  Basic usage is provided: scope by area_id or location, filter by various criteria, and pagination. However, no explicit guidance on when to use this tool versus siblings (e.g., sold listings via booli_search_sold) or when not to use it. The description is functional but lacks comparative context.

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

• booli_market_statsA
  4.1/5.0
  Behavior4/5

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

  Annotations indicate readOnlyHint and openWorldHint are true; description confirms 'Read-only' and warns about thin medians via sample_size. It also clarifies it aggregates over one page, a key behavioral trait. 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.

  Conciseness5/5

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

  The description is two sentences, front-loading the purpose and immediately providing scope and usage context. Every sentence adds value without redundancy.

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

  Completeness3/5

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

  Given 22 parameters, no required ones, and no output schema, the description provides adequate context for an agent to use the tool, referencing a sibling tool for filter details and suggesting sample_size checks. However, it lacks details on response structure or pagination behavior.

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

  Parameters3/5

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

  Schema description coverage is high (82%), so baseline is 3. The description does not add additional parameter semantics beyond referencing that filters match booli_search_sold. No new meaning beyond schema.

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

  Purpose5/5

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

  The description clearly states the tool aggregates sold-price statistics (median/average price, price per m², over/under-asking %) for an area. It distinguishes itself from sibling tool booli_search_sold by specifying it operates over one page of sold results.

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

  Usage Guidelines4/5

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

  The description explicitly says it uses the same scope and filters as booli_search_sold, guiding when to use it over individual listings. It also provides a caveat to check sample_size, but does not exhaustively list when not to use it.

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

• booli_search_areasA
  4.1/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds useful context about the types of areas returned (municipalities, districts, streets) and the area_id output, which complements the annotations without contradicting them.

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

  Conciseness5/5

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

  Two sentences, zero waste, front-loaded with the main action and resource. Efficiently communicates purpose, output, and consumption pattern.

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

  Completeness5/5

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

  For a simple 2-parameter lookup tool with strong annotations, the description fully explains the tool's purpose, output (areas with area_id), and how it feeds into sibling tools. No output schema needed given the context provided.

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

  Parameters3/5

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

  Schema coverage is 100% (both parameters described with clear descriptions). The description adds little extra meaning beyond what is in the schema, as the schema already covers the parameter semantics adequately.

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

  Purpose5/5

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

  The description states a specific verb ('Resolve'), a clear resource ('place names to Booli areas'), and explicitly distinguishes from siblings by naming booli_search_listings and booli_search_sold as consumers of the area_id.

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

  Usage Guidelines4/5

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

  The description clearly implies usage when needing area IDs for Booli search tools ('to pass as area_id into booli_search_listings / booli_search_sold'), but does not elaborate on when not to use or alternatives beyond the sibling mention.

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

• booli_search_soldA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=true. Description adds that tool is 'Read-only', paginated, and returns achieved price and over/under-asking %. Provides useful behavioral context beyond annotations.

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

  Conciseness5/5

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

  Two sentences, front-loaded with purpose, then key parameter categories. No unnecessary words. Every sentence earns its place.

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

  Completeness4/5

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

  Given 22 parameters and no output schema, description covers purpose, key filters, pagination, and read-only nature. Could mention sorting options and compact mode, but schema descriptions fill those details. Generally complete for a search tool.

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

  Parameters3/5

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

  Schema coverage is 82%, so most parameters are described in schema. Description groups key dimensions (price, date, rooms, area, object type) but does not add significant meaning beyond what schema already provides. Baseline 3 is appropriate.

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

  Purpose5/5

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

  Description clearly states it searches sold properties with final price and over/under-asking %. The term 'slutpriser' and 'comparables for valuation' distinguish this from sibling booli_search_listings (likely active) and other tools. Specific verb+resource.

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

  Usage Guidelines4/5

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

  Implicitly suggests use for valuation (comparables), and describes scope options (area_id vs location) and filters. No explicit alternatives named, but context makes intended use clear.

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

• booli_healthcheckA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds value by specifying the exact output (reachability, elapsed time, hint) and confirming read-only behavior. No contradictions.

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

  Conciseness5/5

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

  The description is a single, well-structured sentence that efficiently communicates the tool's purpose and output without unnecessary words.

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

  Completeness5/5

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

  Given no parameters, no output schema, and rich annotations, the description provides complete context: what the tool does and what it returns. Nothing else is needed.

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

  Parameters4/5

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

  With zero parameters and 100% schema coverage, the description does not need to add parameter details. Baseline score of 4 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: checking connectivity to booli.se by round-tripping a tiny query and reporting reachability, elapsed time, and a hint. This is distinct from sibling tools that fetch listings or market data.

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

  Usage Guidelines3/5

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

  The description implies the tool is for verifying endpoint reachability, but provides no explicit guidance on when to use it vs. alternatives. No when-not-to-use or comparison to siblings is given.

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

• booli_get_listingA
  4.4/5.0
  Behavior4/5

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

  Description states read-only, consistent with annotations. Adds that it works for active and sold properties. No contradictions. Annotations already cover readOnlyHint, openWorldHint, idempotentHint.

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

  Conciseness5/5

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

  Three sentences, each essential: purpose, ID source, and scope/safety. No redundancy, perfectly front-loaded.

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

  Completeness4/5

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

  For a simple 2-param tool with no output schema, the description covers input derivation, read-only nature, and applicability to both active and sold properties. Slightly ambiguous on what 'full detail' includes, but adequate.

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

  Parameters4/5

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

  Schema coverage is 100%, description adds value by explaining how to obtain residence_id (from URL or search result) and clarifying the compact parameter's purpose.

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

  Purpose5/5

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

  Description clearly states the tool returns full detail for one property by residence ID, including how to find the ID. Distinguishes from siblings (search returns lists, this returns individual detail).

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

  Usage Guidelines4/5

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

  Explicitly tells when to use (when you have a residence ID from URL or search result) and that it works for both active and sold. Lacks explicit mention of alternatives but context is clear.

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