dxb-data

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

No annotations provided, so description must carry behavioral transparency. It discloses that it filters by median sale price and sorts results, but does not mention behavior for edge cases (e.g., no areas found), output format, or data freshness. Adequate but not comprehensive.

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?

Single, well-structured sentence that front-loads the action and condition. Every word earns its place; no redundancies or filler.

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 tool with 2 parameters and no output schema, the description covers core functionality. Lacks details on default property_type behavior and what happens if budget yields no results, but overall sufficient for a straightforward use case.

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 covers 100% of parameters with descriptions. Description adds context that budget_aed is in AED, but does not explain that property_type filters by 'Flat' or 'Villa' or that its default is 'Flat'. Minimal added value beyond 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?

Description clearly states the tool lists Dubai areas where median sale price fits within a budget, sorted descending by price. Distinguishes from siblings like list_areas (which likely lists all areas) and compare_areas (which compares multiple areas).

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?

Implies usage when user has a budget in AED and wants affordable areas, but does not explicitly mention when not to use or suggest alternatives among sibling tools. Context signals include sibling names but no 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?

No annotations are provided, so the description carries the full burden. It clearly states the tool provides a read-only snapshot from 'official DLD sale transactions', indicating non-destructive behavior. However, it does not mention data freshness, update frequency, or any limitations.

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, well-structured sentence that front-loads the core purpose and key outputs. No wasted words, and every element adds value.

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 tool with no output schema, the description adequately explains the output (sample size, median sale price, median price per m2, date range). It provides enough context for an agent to understand what the tool returns, without needing additional documentation.

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 100% of parameters with descriptions. The description does not add additional meaning beyond what the schema provides for the parameters themselves, but it does hint at the output structure (sample size, median prices). Baseline 3 is appropriate given full schema coverage.

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 it provides a price snapshot for a residential property in a Dubai area, including sample size, median prices, and date range. It uses specific verb 'snapshot' and resource 'price snapshot', and distinguishes from siblings like 'list_areas' (listing areas) and 'market_overview' (broader market) by focusing on area-specific transaction 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 implies usage for getting price data for a specific area, but does not explicitly state when to use this tool versus alternatives like 'market_overview' or 'rental_yield'. No explicit context or exclusions are provided, relying on the agent to infer from sibling names.

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 provided, so description carries full burden. Only states the action and output fields, without disclosing traits like data freshness, performance limits, or response format. Lacks context for safe invocation.

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?

Single, front-loaded sentence that communicates purpose and output in 15 words. No filler or repetition. 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 lack of output schema, the description covers the core functionality and output metrics but omits output format (e.g., numbers, table), error handling for invalid area names, and edge cases (e.g., less than 2 areas). Adequate but not comprehensive.

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% and includes the 2-5 constraint and English requirement. Description adds value by listing the three output metrics (median sale price, price per m2, gross rental yield), which are not in the schema. This helps the agent understand what data is returned.

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?

Clearly states the verb 'compare', the resource '2-5 Dubai areas side by side', and the specific metrics: median sale price, price per m2, gross rental yield. Distinguishes from sibling tools like 'area_snapshot' (single area) and 'list_areas' (listing without comparison).

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?

Implies usage when needing multi-area comparison but does not explicitly state when to avoid (e.g., single area or non-Dubai). No mention of alternatives like 'area_snapshot' or 'rental_yield'.

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 states it 'list[s] all Dubai areas,' without specifying the return format, whether it is read-only, performance characteristics, or any side effects. The description adds little beyond the tool name.

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 extremely concise at 12 words in two sentences. The first sentence front-loads the primary action and resource. Every word adds value without 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?

Given the tool's simplicity (no params, no output schema), the description covers the core purpose and use case. However, it omits the return format (e.g., array of strings) and any ordering constraints. The completeness is adequate but not fully detailed.

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 has 0 parameters with 100% coverage, so the baseline is 4. The description does not need to add parameter details. It clarifies the list scope (Dubai areas, dataset), which is sufficient.

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 'list' and resource 'Dubai areas', clearly stating the action. It adds value by noting 'available in the dataset' and explicitly mentions the use case 'discover valid area names', which hints at its role as a discovery tool. This differentiates it from sibling tools like area_snapshot (single area details) and market_overview (aggregate 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 states to 'use to discover valid area names,' which implies the tool is meant for finding valid inputs for other tools. However, it does not explicitly mention when to use it versus alternatives (e.g., area_snapshot) or provide exclusions. The guidance is implied but not robust.

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 burden. It clearly states the output includes total transactions, areas, date range, median sale price, and top 5 areas. It does not mention side effects or safety, but the empty input schema suggests it's a read-only query. A safety note would improve transparency.

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, front-loaded with the purpose, and lists output components concisely without extraneous 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?

The description covers what the tool returns, but it does not specify whether the date range is fixed or configurable (given no parameters). For a simple overview, it is mostly complete but could clarify the scope.

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 is empty (0 parameters) with 100% coverage. Baseline for 0 parameters is 4. The description adds no parameter info because there are none, which 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 clearly states it provides an overall Dubai real estate snapshot, listing specific data points (total transactions, median sale price, top areas). It distinguishes from sibling tools like area_snapshot (focused on a single area) and rental_yield (yield 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 implies use for a high-level market overview but does not explicitly guide when to use this tool vs. alternatives like area_snapshot or rental_yield. No 'when not to use' or context for sibling differentiation.

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 carries the full burden. It discloses data source (official DLD sale + rental data) but does not mention return format, data freshness, or that it's read-only. Adequate but not detailed.

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, front-loading the action and use case. No unnecessary 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 only 2 parameters, no output schema, and no annotations, the description covers the essential purpose and data source. It could mention it's read-only, but overall is sufficient.

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 defines 'limit' and 'property_type'. The description adds no additional meaning beyond the schema, so baseline 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 clearly states the tool ranks Dubai areas by gross rental yield (highest first), using official DLD data. It distinguishes from sibling tools like 'rental_yield' or 'list_areas' by focusing on ranking and best-yielding neighborhoods.

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 for finding best-yielding neighborhoods, but lacks explicit guidance on when not to use or how it compares to siblings. It is clear enough for an agent to know its primary purpose.

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 full burden. It discloses data sources (DLD sale + Ejari), indicating authoritative and official data. It does not mention caching, rate limits, or data recency, but the tool is a simple query with no side effects.

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?

Single sentence with no wasted words. Clearly states purpose, metrics, data source, and geographic scope. Front-loaded with essential 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 no output schema, the description adequately specifies what the tool returns (three metrics). The tool is simple (2 parameters, no nested objects), and the description provides enough context for an agent to understand behavior and output without ambiguity.

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 does not add additional parameter-level context beyond what the schema provides (area name, property type default). The description's mention of 'residential property' aligns with schema but adds no new semantic detail.

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 returns gross rental yield for residential property in a Dubai area, specifying the exact metrics (median rent/sale per m2, yield %). It distinguishes from siblings like area_snapshot and market_overview by focusing on yield calculations from official DLD 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 does not explicitly state when to use this tool versus alternatives (e.g., market_overview). It implies usage for yield analysis but provides no exclusionary criteria or context for choosing between tools.

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