brokeria_comparar_imoveisCompara de 2 a 4 imoveis lado a lado a partir dos ids retornados pelas buscas. Monta uma tabela com preco anunciado, area, quartos, vagas, bairro, imobiliaria responsavel e preco por metro quadrado. Util pra visualizar trade-offs objetivos. Nao indica qual e o "melhor" — a decisao e do usuario.
| Name | Required | Description | Default |
|---|---|---|---|
| imovel_ids | Yes | Lista de 2 a 4 UUIDs de imoveis retornados pela busca |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false; the description adds behavioral details by explaining it builds a table with specific columns and does not rank or judge. This is consistent with annotations and gives context about the tool's output and limitations.
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 three concise sentences: the first defines the action and constraint, the second lists the output content, and the third explains the use case and limitation. No redundant words.
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 simple read-only tool with one parameter and no output schema, the description is fully complete. It explains what the tool does, what the table contains, and its purpose, so the agent knows what to expect.
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 already provides full coverage for the single parameter, including min/max. The description adds meaning by reinforcing the 2-4 item limit and clarifying the IDs come from previous searches, which is not in the 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 clearly states the tool compares 2 to 4 properties side-by-side from IDs returned by searches, and lists the specific comparison fields (price, area, bedrooms, etc.). This makes it distinct from siblings like 'brokeria_buscar_imoveis' and 'brokeria_detalhes_imovel'.
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 specifies this tool is used after a search ('a partir dos ids retornados pelas buscas') and for visualizing objective trade-offs. It also notes it does not indicate which property is best, implying the agent should not delegate decisions to the tool, though it doesn't explicitly name alternative tools.
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 addresses a distinct step in the real estate journey: financial pre-qualification, property search, proximity search, detail viewing, comparison, visit scheduling, payment estimation, and neighborhood analytics. No two tools have overlapping responsibilities; even the two estimation tools focus on different questions (affordable price vs. monthly payment).
Most tools follow a verb_noun pattern like buscar_imoveis and agendar_visita, but others are noun-based (detalhes_imovel, info_bairro) and one mixes English with Portuguese (capacidade_pre_search). The consistent 'brokeria' prefix mitigates this, but the varied structures and language mixing are noticeable.
At 8 tools, the set is appropriately scoped for a real estate assistant, covering both discovery (search, nearby) and action (scheduling) without redundancy. Each tool has a clear role, and there is no excess or obvious bloat.
The tool set delivers a complete workflow: budgeting (capacidade_pre_search), searching (buscar_imoveis/imoveis_proximos), evaluating (detalhes_imovel/comparar_imoveis), contextualizing (info_bairro), and acting (agendar_visita). It also covers financing education with estimar_parcela_educacional. Missing features like listing purchases or broker contact are out of scope for a buyer-facing assistant.