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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real context beyond that: the underlying data source (DLD registered sales), the comparative nature of the output (project median vs area median), and the degraded-data behavior when sales volume is insufficient. It does not discuss freshness, coverage lag, or output shape, which keeps it from a 5.

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, front-loaded with the actual comparison being returned before the input forms. Minor redundancy in 'from Dubai Land Department sales, as shown on the project page,' which conveys source twice, but nothing is wasted overall.

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

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

With no output schema, the description carries the burden of explaining the return value, and it does so at a conceptual level: a per-sqft median compared against the area's median. The insufficient-data caveat covers the main edge case. It could say more about what happens on ambiguous project names, but for a one-parameter read tool this is close to 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?

Schema description coverage is 100% and the single parameter already documents the three accepted identifier forms with an example slug. The description repeats those same three forms rather than adding syntax, normalization, or disambiguation rules (e.g. which form wins if a name matches multiple projects). Baseline 3 is appropriate since 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 names a specific resource (one project's median registered price per sqft) and a specific comparison (against its area's median), sourced from Dubai Land Department sales. That is far more precise than the title alone, and it implicitly contrasts with the area-level sibling area_prices by being explicitly single-project. It stops short of naming a sibling to route away from, so a 4 rather than 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?

It gives clear input guidance (slug, binayah.ae URL, or name) and a useful failure condition: not every project has enough registered sales and the tool will say so. What it lacks is when-to-use routing — nothing tells the agent to prefer area_prices for area-level questions or search_projects when the project identity is unknown. Usage is therefore implied rather than stated.

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