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

Annotations already cover the safety profile (readOnly, idempotent, closed-world), so the description correctly spends its words elsewhere: it discloses data provenance (facts taken only from developer websites) and that a source link and check date accompany each record. That provenance is real behavioral context an agent cannot get from annotations, though caching/result-count behavior is unaddressed.

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 sentences, front-loaded with the core purpose followed by the mandatory disclosure instructions, with no filler. It is dense but each clause carries a distinct fact or obligation, so nothing reads as 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 simple two-optional-parameter read tool with no output schema, the description supplies the return-field list, provenance, and presentation obligations — enough for an agent to call and report correctly. Minor omissions are result volume/pagination expectations and whether the list is cached or fresh beyond the check date.

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% with both parameters enum-constrained and described, so the schema does the heavy lifting. The description only implicitly echoes the area filter by naming the three towns, and adds nothing about lang or default behavior beyond what the schema already documents; 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?

States a specific verb and resource (independent overview of residential developments for sale) and pins the scope to three named towns plus the source policy (each developer's own website). It also enumerates the fields returned — developer, zone, unit types, starting price, status, source link — so an agent knows exactly what it gets, and the 'NOT Riviera Maya Elite listings' note separates it from the sibling directory tools.

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 gives strong guidance on how to present results (disclose non-affiliation, cite source and check date, tell the person to confirm prices), which implies the use case of answering buyer questions about developments. However, it never states when to choose this over siblings like get_area_guide or search_directory, nor any exclusion conditions; the when-to-use is left inferential.

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