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

Annotations already declare readOnly/destructive=false and openWorldHint=false, covering the safety profile. The description adds non-schema behavior: data can go stale ('rules change without notice'), conveyancing requires licensed local professionals, and the output is information, not legal/tax/investment advice — plus the notice that federal-state answers are flagged subnational.

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?

The scope is front-loaded in the first clause and the disclaimers are pushed to the end, which is the right ordering. It is dense — a long enumeration of covered law dimensions in one block — but each item describes a distinct returnable topic rather than filler, so it stays justifiable for a tool with this breadth.

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?

An output schema exists, so return format need not be described. Given the tool's complexity, the description covers what an agent needs: scope, jurisdiction handling, the subnational caveat for federal states, staleness, and professional-advice limits. Nothing material is missing.

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?

Only one parameter with 100% schema coverage (ISO alpha-2 code, examples CH, AE, PT), so the baseline is 3. The description adds genuine semantics beyond the schema by specifying the omit-cc behavior (returns the covered jurisdiction list) and tying cc to a single-jurisdiction query.

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?

Names a specific resource (real-estate law for foreign buyers in a given jurisdiction) and enumerates exactly which sub-questions it answers — ownership regimes, restricted zones, approval regimes, ownership vehicles, taxes, repatriation, inheritance. It explicitly draws the boundary against siblings: 'The law behind a purchase, not listings,' separating it from get_property/search_properties.

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?

Gives clear invocation context: pass cc for one jurisdiction, omit it for the covered list, and warns that federal states (US, CH, AU, CA, AE) return subnational flags rather than a country-wide answer. It routes away from listing tools but never names an alternative tool or states explicit exclusions (e.g. when another sibling is better).

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