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

With no annotations, the description carries the full burden and does useful work: it discloses the data source (registered prices, PropertyIndex-derived), that a comparable off-plan-to-ready ratio sits behind a paid tier while this returns both sides free, and even shows that the split yields materially different figures (3,645 blend vs 2,790 ready vs 5,483 off-plan). It does not mention authentication, rate limits, or whether the split can return empty buckets for communities lacking segment data.

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?

Front-loaded with the output definition, then the usage rule, then the supporting evidence. The Palm Jumeirah numbers are somewhat verbose but are doing real work by demonstrating why the split matters rather than padding.

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 single-parameter tool with no output schema and no annotations, the description covers what is computed, how it is segmented, when to prefer it, and what form the answer takes (prices on both sides rather than a ratio). Nothing material is left unanswered for an agent deciding whether and how to call it.

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% for the single 'community' parameter, so the schema already documents its meaning and format. The description's example communities ('Palm Jumeirah') echo rather than extend that, so baseline 3 applies.

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 states a specific computation (median registered price per square foot) and its exact segmentation (ready vs off-plan, apartment vs villa), which tells the agent precisely what resource is being returned. It implicitly distinguishes itself from the 'single median' sibling but never names dubai_community_prices or another sibling tool, so differentiation requires inference.

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 positive guidance: use this instead of a single median whenever the question is what something costs to buy, with a concrete rationale (74% of sales are off-plan, so a blend is misleading). It gives no explicit when-not conditions or named alternatives, but the decision context is well specified.

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