property_search

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does an unusually good job by revealing the fallback to Nominatim/OpenStreetMap and the helpful message returned instead of a bare '0 of 0'. It also communicates the non-obvious response behavior for missing assessment results, which goes beyond what the schema or annotations would convey.

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 description is front-loaded with the core purpose, then adds capability details, then the important fallback behavior. Every sentence earns its place, and the information is dense without being bloated. It is appropriately sized for an 8-parameter search tool with no annotations.

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 no annotations and no parameter descriptions in the schema, the description covers the main call path, supported sort fields, filtering, and fallback behavior. An output schema exists, so return value details are not the description's job. The only meaningful gaps are conventional pagination parameters (limit, offset, order) and city semantics, which are mostly inferable from names and context.

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 0%, so the description must compensate. It adds meaning for sort_by by listing allowed values (assessed_value, address, year_built, community) and explains min_value/max_value as value range filtering. However, it does not explain limit, offset, order, or city beyond their schema names, leaving several parameters underdocumented for a tool with zero schema descriptions.

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 states a specific verb and resource: 'Search for properties by address across 13+ Canadian cities.' It clearly identifies what the tool does and what it returns (assessment data, value, lot size, year built, DLS coordinates). It is easy to distinguish from siblings like property_by_roll or property_report because the search key is explicitly an address.

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 implies when to use the tool (when searching properties by address) and describes supported sorting/filtering, but it does not explicitly state when to prefer an alternative sibling such as property_by_roll for roll-based lookups or property_report for detailed reports. There is no direct comparison or exclusion, leaving some routing decision to the agent.

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