brokeria_detalhes_imovelRetorna os detalhes publicos de um imovel especifico pelo id retornado por uma busca. Inclui fotos, descricao, caracteristicas (quartos, suites, vagas, area), endereco aproximado, preco anunciado e imobiliaria responsavel. Nao calcula financiamento nem avalia elegibilidade em programa de credito.
| Name | Required | Description | Default |
|---|---|---|---|
| imovel_id | Yes | UUID do imovel |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only and non-destructive. The description adds that the address is approximate, which is a behavioral caveat beyond annotations, and clarifies it does not compute financing or eligibility. This adds useful context without contradiction.
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 two sentences: the first states the core action, the second lists contents and exclusions. It is concise, front-loaded, and contains no filler.
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?
With one simple parameter and no output schema, the description lists the expected return fields and clearly states limitations. It gives enough context for the agent to use the tool correctly and set expectations.
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 covers the parameter fully with 'UUID do imovel' at 100% coverage. The description adds that the ID comes from a search result, providing provenance that helps the agent understand where to obtain the value. This goes beyond schema-only info.
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 returns public details for a specific property using the ID from a search, and lists the included fields (photos, description, features, approximate address, price, agency). This distinguishes it from sibling tools like buscar_imoveis or comparar_imoveis.
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 it by saying 'pelo id retornado por uma busca', indicating a prior search step. It also explicitly states what it does not do (calculate financing or assess credit eligibility), providing a when-not. However, it does not name alternative tools directly.
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.