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

Annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the description's job is to add context beyond that. It adds the public-only scope constraint (not present in the schema) and the non-obvious SALE_AND_RENT inclusion behavior. That behavior is partially redundant with the operation_type parameter description, but the description still adds genuine value over the annotations alone.

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 with the core purpose front-loaded; each sentence serves a distinct function: scoping the tool, disclosing inclusion behavior, and routing to the sibling. The SALE_AND_RENT sentence is slightly redundant with the operation_type schema description, which keeps this from a 5, but there is no wasted prose.

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?

Given the output schema exists, annotations carry the safety profile, and the sibling set is large (five tools), the description covers the critical routing decisions (vs `search`), the scope boundary (public only), and a non-obvious result behavior. The main gap is that with 0 required parameters, the description never states what happens when no filters are supplied, and it doesn't clarify pagination behavior — minor gaps for a read-only, output-schema-backed search tool.

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 67%, below the high-coverage baseline, so the description should compensate. It names the filter dimensions (price, property type, area, bedrooms, bathrooms) which loosely maps to the undocumented params (min_price, max_price, property_type), providing some compensation. However, it doesn't add detailed semantics beyond what the schema's own parameter descriptions already state, and pagination params (limit, offset) are not mentioned 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?

The description opens with a specific action ('Use this when the user wants only public EPK Properties listings') naming both the verb and the exact resource scope, then enumerates the filter dimensions (country, sale/rent, property type, price, bedroom, bathroom, area, location, keywords). It differentiates from the sibling `search` tool directly in the final sentence, so an agent can distinguish them without opening either schema.

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 an explicit when-to-use condition ('when the user wants only public EPK Properties listings with explicit... filters') and an explicit when-not-to-use with a named alternative ('If the same request also asks for guides or regulations, use search instead'). The SALE_AND_RENT inclusion note also prevents a class of incorrect calls where an agent assumes SALE returns only SALE listings.

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