rendimento_aluguelRendimento bruto anual do aluguel: 12 aluguéis divididos pelo preço de venda, pelo m² mediano. Serve para responder se compensa comprar para alugar num bairro.
| Name | Required | Description | Default |
|---|---|---|---|
| tipo | No | Tipo de imóvel. Padrão: apartamento. | |
| bairro | No | Bairro. Opcional: sem ele, responde a cidade inteira. | |
| cidade | Yes | Cidade. Uma das 6 cobertas pelo índice. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint already covers the safety profile, and the description adds the computation semantics and aggregate nature (median m², gross annual yield), which is useful beyond the annotations. It does not describe output shape or data limitations, but those are minor for a simple read-only metric.
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 with no filler: the formula is front-loaded, and the real-world use case follows immediately. Every sentence earns its place.
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 three-parameter read-only tool with full schema coverage, the description gives enough context to select the tool and understand its output concept. It could mention the output format explicitly, but the metric definition largely supplies that implicitly.
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 100%, so the schema already documents tipo, bairro, and cidade adequately. The description mentions bairro and median m² in the formula, but adds no significant parameter-level meaning beyond what the schema provides.
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 defines a specific metric—gross annual rental yield as 12 rents divided by sale price per median m²—and states the practical question it answers: whether buying to rent in a neighborhood is worthwhile. This clearly distinguishes it from siblings like preco_m2 or ranking_bairros.
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?
It provides a clear usage context: use this tool when deciding whether buying a property to rent in a neighborhood pays off. It does not explicitly name alternatives or state when not to use it, so it falls just short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool has a clearly distinct purpose: comparison, methodology, single-place price lookup, neighborhood ranking, and rental yield. The closest pair, comparar and preco_m2, is separated by side-by-side comparison versus detailed single-place lookup, so an agent can choose reliably.
Most names follow a consistent output-oriented lowercase Portuguese pattern with underscores for multi-word terms, such as preco_m2, ranking_bairros, and rendimento_aluguel. The only deviation is comparar, a verb instead of a noun, which is minor and does not cause confusion.
Five tools is well-scoped for a focused real-estate metro-square-price domain. Each tool covers a distinct dimension of the index without redundancy, and no tool feels unnecessary.
The tool set covers the main user needs: obtaining m2 prices, comparing places, finding expensive or cheap neighborhoods, evaluating rental yield, and understanding the underlying methodology. There are no obvious dead ends or missing operations for the domain.