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

Beyond the readOnlyHint and openWorldHint annotations, the description adds useful conditional behavior: rent statistics are included only when rent contracts can be attributed to the building, and the per-bedroom breakdown appears only when enough contracts resolve a bedroom. This helps the agent set expectations about partial or conditional outputs.

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 a single sentence that front-loads the core purpose and lists the returned metrics efficiently. The conditional rent clauses add necessary nuance without excessive length.

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?

There is no output schema, so the description serves as the return contract. It enumerates the main data categories and explains conditions under which rent fields are present, which is sufficient for an agent to invoke the tool and interpret results. Minor details like exact date ranges of 'recent' are not specified but do not block correct usage.

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?

The schema provides only type and length constraints, so the description carries the full burden. It explains that both communitySlug and buildingSlug are required to identify a building and that they come as a pair from search_locations, which is meaningful guidance beyond the bare schema.

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 names a specific resource (a single building) and enumerates the concrete statistics returned: 12-month sales, median price, trend, recent sales, property-type mix, and rent data. It clearly separates this from broader location or market tools by scoping to one building.

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 provides clear usage context by stating that it takes the communitySlug and buildingSlug pair returned by search_locations, establishing both a precondition and an input source. It does not explicitly name alternative tools or when not to use it, but the single-building scope makes the intended context obvious.

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