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 genuinely useful context beyond annotations — the clarification that rent medians are annual contract values in AED/year prevents unit misinterpretation. However, it doesn't disclose response format, data recency, or month coverage, and with no output schema the return shape is left unspecified.

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?

Two tight sentences with zero waste. The core data product and scope are front-loaded, and the second sentence earns its place with the critical unit clarification for rent medians. Every word carries 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?

For a read-only query tool with no output schema, the description covers the essentials: what data is returned, how to scope it, the sale/rent distinction, the optional property-class filter, and units. The main gap is the absence of response-format detail, but the declared outputs (transaction counts and median prices) largely imply the shape, and annotations cover the safety profile.

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 75% — kind, slug, and propertyClass are already described, and months carries numeric constraints (default 24, min 3, max 60). The description adds marginal value: the AED/year unit tied to rent kind and the 'one property class' limitation, but it largely restates the schema. The months parameter has no semantic description anywhere.

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?

States a specific data product — monthly transaction counts and median prices — with scope (community/area slug or city-wide), transaction kind (sales/rents), and an optional property-class filter. This is clear and specific enough to convey what the tool does, but it stops short of explicitly distinguishing itself from overlapping siblings like get_market_overview or get_trends_movers.

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?

Provides clear scope conditions: use for a community/area slug or city-wide, for sales or rents, optionally filtered to one property class. The when-to-use context is evident, but there are no explicit exclusions or alternative routing ('use X instead when...'), so an agent must infer when a sibling tool is the better fit.

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