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

Annotations already declare readOnlyHint=true and openWorldHint=false, yet the description still adds real operational context: the data provenance (Dubai Land Department registrations), the 90-day freshness window, and a CC BY 4.0 attribution obligation to Binayah Properties. The attribution requirement is a genuine behavioral constraint an agent must honor, not a restatement of annotations. It does not cover edge behavior such as an unknown area name or an area with too few sales to be reliable.

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 sentences, front-loaded with the metric and scope, then the return payload, then the input convenience note. Almost every clause earns its place, including the licence line, which carries a real obligation. The enumerated return-field list is long but justified by the absence of an output schema.

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 correctly takes on the job of enumerating return values (median, sale count, off-plan share, as-of date, method, licence, DOI), and it discloses provenance and freshness. For a two-parameter read tool this is nearly everything an agent needs to call it and interpret the result. The remaining gap is failure behavior: what is returned for an unrecognized area or one with sparse sales.

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%: 'area' is documented in the schema, while 'property_type' has an enum and default but no prose. The description compensates partly by stating that common names (JVC, Dubai Marina, Downtown Dubai) are accepted for 'area' and by framing results as covering apartments and villas, which maps loosely to the property_type values. It never explains what 'both' means or when an agent should narrow to a single property type, so the gap is only half closed.

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 precise metric and resource: median price per square foot for apartments and villas in a Dubai area, sourced from Dubai Land Department sales over a 90-day window. That is far more specific than a restated title, and the area-level scope implicitly separates it from a project-level sibling. It stops short of naming which sibling to use for a specific building, so it is clear but not fully differentiated.

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?

Usage is implied rather than stated: the agent can infer this is the tool for area-level price benchmarks and that common names like JVC or Dubai Marina are acceptable inputs. There is no explicit when-to-use versus when-not guidance and no alternative tool is named for project-specific or deal-level checks. Adequate for routing, but the agent must infer the boundary.

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