Motor financeiro determinístico: simula comprar vs alugar imóvel.
Calcula o CET (Custo Efetivo Total) anual de um financiamento imobiliário, incluindo juros, seguros MIP/DFI e taxas administrativas. Aceita os mesmos parâmetros da simulação comprar vs alugar.
| Name | Required | Description | Default |
|---|---|---|---|
| cetPct | No | CET (Custo Efetivo Total) anual informado (%) | |
| itbiPct | No | ITBI (% do valor do imóvel) | |
| prazoAnos | No | Prazo do financiamento em anos | |
| seguroPct | No | Seguro anual do financiamento (% do valor do imóvel) | |
| trHistory | No | Série mensal de TR (% a.m.), ex: [0.0052, 0.0048, ...] | |
| entradaPct | No | Percentual de entrada (%) | |
| inflacaoPct | No | Inflação anual esperada (%) | |
| trMensalPct | No | Taxa mensal de referência TR (%) para correção do saldo devedor | |
| valorImovel | Yes | Valor do imóvel (R$) | |
| iptuAnualPct | No | IPTU anual (% do valor do imóvel) | |
| aluguelMensal | Yes | Aluguel mensal inicial (R$) | |
| fgtsDisponivel | No | Saldo do FGTS disponível para entrada ou amortização (R$) | |
| rentIncreasePct | No | Reajuste anual do aluguel (%) | |
| spreadOverTRPct | No | Spread anual sobre a TR quando indexer = TR_PLUS_SPREAD (%) | |
| financingIndexer | No | Indexador do financiamento: FIXA, TR ou TR_PLUS_SPREAD | |
| insuranceMonthly | No | Seguro MIP/DFI mensal fixo em R$ | |
| amortizationSystem | No | Sistema de amortização (PRICE ou SAC) | |
| taxaValorizacaoPct | No | Taxa anual de valorização do imóvel (%) | |
| custosManutencaoPct | No | Custos anuais de manutenção (% do valor do imóvel) | |
| custoOportunidadePct | No | Rendimento anual alternativo do capital (%) | |
| tempoPermanenciaAnos | No | Horizonte de permanência em anos | |
| amortizacaoExtraMensal | No | Amortização extra mensal (R$) | |
| taxasTransacaoVendaPct | No | Total de taxas de transação de venda (% do valor do imóvel) | |
| taxasTransacaoCompraPct | No | Total de taxas de transação de compra (% do valor do imóvel) | |
| administrativeFeeMonthly | No | Taxa administrativa fixa mensal em R$ | |
| taxaAdministrativaMensal | No | Taxa administrativa mensal do banco (R$) | |
| rendaExtraMensalInvestida | No | Renda extra mensal investida pelo comprador (R$) | |
| condominioMensalPctOfValue | No | Condomínio mensal (% do valor do imóvel) | |
| taxaFinanciamentoNominalPct | No | Taxa de juros nominal anual do financiamento (%) | |
| amortizacaoExtraordinariaMensal | No | Amortização extraordinária mensal (R$) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It states what is calculated but does not mention return format, side effects, prerequisites, or whether it is read-only. For a calculation tool, this is acceptable in terms of side effects, but the absence of any output description leaves the agent guessing about the result structure.
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, front-loaded with the core purpose and a brief inclusion list. It wastes no words and is appropriately concise for a calculator tool.
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 the 30-parameter complexity and no output schema or annotations, this description is too thin. It does not explain what the tool returns, any dependencies between parameters, or how the CET calculation differs from other calculations. The completeness is low; the description only covers the basic purpose.
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 all 30 parameters are already documented. The description adds no specific parameter details beyond the general note about accepting same parameters as buy vs rent, which is not additional meaning for individual params. Baseline 3 applies because the schema handles parameter semantics adequately.
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 verb ('Calcula') and resource ('CET anual de um financiamento imobiliário'), listing included components (juros, seguros MIP/DFI, taxas administrativas). It is clear what the tool computes, though it does not explicitly contrast with sibling tools like simulate_buy_vs_rent, so it loses a point for not differentiating itself.
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?
There is no explicit guidance on when to use this tool versus the many siblings. The only hint is 'Aceita os mesmos parâmetros da simulação comprar vs alugar', which implies a relationship but does not state conditions for choosing this tool over alternatives. No exclusions or when-not-to-use advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calcula o valor máximo de imóvel que a renda familiar consegue financiar, considerando regras de comprometimento de renda, entrada e custos de transação.
| Name | Required | Description | Default |
|---|---|---|---|
| itbiPct | No | ITBI (% do valor do imóvel) | |
| prazoAnos | No | Prazo do financiamento em anos | |
| entradaPct | No | Percentual de entrada (%) | |
| taxaJurosAnualPct | No | Taxa de juros anual (%) | |
| custosTransacaoPct | No | Custos totais de transação (% do valor do imóvel) | |
| rendaLiquidaMensal | Yes | ||
| comprometimentoExistenteMensal | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the behavioral burden. It transparently describes the calculation and the factors considered, but it does not state default assumptions for omitted optional parameters, the output format, or explicitly confirm it is side-effect-free beyond the verb 'calcula'.
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?
One sentence, direct, and front-loaded with the main action. No filler, no redundancy, and no repetition of the tool name.
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 no output schema and seven parameters, the description is adequate but not rich. An agent learns the purpose and scope, but not the shape of the returned value or how missing optional parameters are handled—both meaningful gaps for a calculation tool in a larger simulation flow.
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 input schema already documents all parameters with descriptions, and schema coverage is around 71%. The description adds only conceptual grouping of parameters into the calculation context, which is marginal value beyond 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 names a specific calculation—'valor máximo de imóvel'—and the constraints that define it (comprometimento de renda, entrada, custos de transação). This is clearly distinct from siblings such as simulate_buy_vs_rent or calculate_cet.
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 purpose statement gives clear context: use this when the agent needs the maximum property price a family income can finance. It does not explicitly name alternatives or when-not conditions, but the specificity of the description implies the appropriate use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compara 3 estratégias de uso de uma renda extra mensal: A) pagar apenas a parcela do financiamento, B) investir a renda extra, C) amortizar extraordinariamente o financiamento. Retorna o patrimônio líquido final de cada estratégia, o breakeven e uma recomendação.
| Name | Required | Description | Default |
|---|---|---|---|
| itbiPct | No | ITBI (% do valor do imóvel) | |
| prazoAnos | No | Prazo do financiamento em anos | |
| entradaPct | No | Percentual de entrada (%) | |
| valorImovel | Yes | Valor do imóvel (R$) | |
| iptuAnualPct | No | IPTU anual (% do valor do imóvel) | |
| aluguelMensal | Yes | Aluguel mensal inicial (R$) | |
| rentIncreasePct | No | Reajuste anual do aluguel (%) | |
| rendaExtraMensal | Yes | Renda extra mensal disponível para amortização ou investimento (R$) | |
| amortizationSystem | No | Sistema de amortização (PRICE ou SAC) | |
| taxaValorizacaoPct | No | Taxa anual de valorização do imóvel (%) | |
| custoOportunidadePct | No | Rendimento anual alternativo do capital (%) | |
| tempoPermanenciaAnos | No | Horizonte de permanência em anos | |
| taxasTransacaoVendaPct | No | Total de taxas de transação de venda (% do valor do imóvel) | |
| taxasTransacaoCompraPct | No | Total de taxas de transação de compra (% do valor do imóvel) | |
| taxaFinanciamentoNominalPct | No | Taxa de juros nominal anual do financiamento (%) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does clarify what the tool compares and returns, but it does not disclose underlying assumptions, how the strategies are modeled, or any limitations; the agent only learns that this is an analysis/comparison tool rather than a mutating operation.
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, information-dense sentence that front-loads the main action, enumerates the three strategies clearly, and states the outputs. Every part earns its place with 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?
Given 15 parameters, no annotations, and no output schema, the description gives a useful overview but remains thin for the tool's complexity. It does not explain what 'breakeven' means, which parameters drive each strategy, or the expected output format, so an agent has to infer significant context from parameter names alone.
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 parameters are already well documented. The description adds little parameter-level meaning beyond mentioning 'renda extra mensal' and 'amortizar', which is consistent with the high baseline but does not elevate it.
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 ('Compara') and exactly which three strategies are compared, listing them as A, B, and C. It also names concrete outputs (final net worth, breakeven, recommendation), which clearly distinguishes this from sibling tools like simulate_buy_vs_rent and sensitivity_analysis.
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 intended context is implied: use when deciding what to do with a monthly extra income in a financing scenario. However, the description does not explicitly state when to prefer this tool over alternatives or when not to use it, leaving the routing decision to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retorna o conjunto ativo de parâmetros padrão brasileiros (taxas, prazos, custos) usados pelo site e pelas simulações.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 explain that the tool returns the 'active' default parameters and lists their categories, but it does not mention output format, potential side effects, or whether data might be cached or dynamically sourced.
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, compact sentence that efficiently conveys the tool's purpose and content. There is no redundancy or filler, and the key information is immediately accessible.
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 parameterless getter, the description is reasonably complete: it identifies the returned data, its categories, and its usage context. Since there is no output schema, a bit more detail about the exact structure or format of the returned parameters would improve completeness, but the low complexity makes the current description adequate.
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 tool has zero parameters, so parameter-specific semantics are not needed. The schema confirms an empty object with additionalProperties false, and the description adds no unnecessary parameter commentary, which is appropriate here.
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 verb 'Retorna' and the resource 'conjunto ativo de parâmetros padrão brasileiros', specifying the content categories (taxas, prazos, custos) and its intended use by the site and simulations. This distinguishes it from the sibling calculation/comparison tools.
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 the tool is relevant when defaults are needed for site behavior or simulations, but it does not explicitly state when to use it instead of alternatives like get_municipio_rates or get_site_info. No exclusions or direct sibling comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Busca alíquotas de ITBI, IPTU, escritura e registro de um município brasileiro. Passe municipioId para busca exata, ou uf/nome para filtrar. Sem filtro retorna a lista completa.
| Name | Required | Description | Default |
|---|---|---|---|
| uf | No | Sigla da UF (ex: SP) | |
| nome | No | Nome do município (busca parcial, ex: São Paulo) | |
| municipioId | No | ID do município (ex: sao-paulo-sp) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It discloses the exact-match vs filtering behavior and the unfiltered full-list return, which is useful. However, it does not mention response format, match-count behavior, or edge cases such as no results or ambiguous matches.
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 resource is front-loaded and the usage rules are compactly sequenced. Every clause contributes either the purpose or the parameter behavior.
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 lookup tool with three optional, fully described parameters, the description covers purpose, search modes, and unfiltered behavior. Since there is no output schema, it could describe the response shape or error handling more explicitly, but the listed rate types imply the return content.
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 coverage is 100%, so the baseline is 3. The description adds value by positioning municipioId as an exact lookup and uf/nome as filters, and by clarifying that omitting all filters returns the full list. It does not discuss parameter combinations or validation details.
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 begins with a specific verb and resource: 'Busca alíquotas de ITBI, IPTU, escritura e registro de um município brasileiro.' This clearly distinguishes the tool as a municipal rates lookup from the sibling simulation and calculation tools.
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 gives explicit usage context: 'Passe municipioId para busca exata, ou uf/nome para filtrar. Sem filtro retorna a lista completa.' This clarifies how to choose among parameters, though it does not explicitly contrast with sibling tools or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calcula o rental yield (retorno anual e mensal) a partir do valor do imóvel e do aluguel mensal. Interpreta o indicador: < 5% a.a. = aluguel relativamente barato; 5–7% = intermediário; 7–9% = aluguel caro; > 9% = aluguel muito caro. Indicador inicial, não é uma regra absoluta.
| Name | Required | Description | Default |
|---|---|---|---|
| valorImovel | Yes | Valor do imóvel (R$) | |
| aluguelMensal | Yes | Aluguel mensal (R$) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does well: it states that both annual and monthly returns are calculated, provides band-based interpretation, and adds the important caveat that this is an initial indicator, not an absolute rule. Only the exact output formatting is left unspecified.
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 compact and front-loaded: the core computation is stated first, followed by interpretation thresholds and a caveat. Every sentence contributes information; there is no repetition of schema data.
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 two-parameter calculator with no output schema and no annotations, the description covers the inputs, the calculation type (annual and monthly yield), interpretation bands, and a caveat. It does not explicitly describe the return format, but the tool's simplicity makes this a minor omission.
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%, and the description adds the conceptual link that the parameters are used to compute rental yield and the interpretation thresholds. It does not add new format or constraint details beyond the schema, so the baseline 3 is appropriate.
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 opens with a specific verb ('Calcula') and a precise object ('rental yield') tied to two named inputs: property value and monthly rent. Rental yield is a distinct concept among the siblings such as max_price_from_rent or calculate_cet, so the tool is easy to tell apart.
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 makes the usage context clear by naming the required inputs and providing interpretation thresholds for the resulting indicator. It does not explicitly mention alternatives or when not to use it, but the calculation scenario is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retorna informações sobre o site É melhor alugar ou comprar um imóvel e como acessar os painéis interativos.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. 'Retorna' makes clear this is a read-only information retrieval tool, and the description states what kind of output to expect. It does not mention authentication or rate limits, but for a zero-parameter metadata tool this risk is minimal.
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?
A single, well-structured sentence that front-loads the action, states the resource, and adds the panel-access detail. There is no redundant wording or unnecessary fluff.
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 zero-parameter informational tool, the description provides adequate context about what is returned: site information and how to access interactive panels. There is no output schema, so a bit more detail on the exact format or scope of the information could be useful, but it is not essential at this complexity level.
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 tool has zero parameters, so the schema fully covers parameter semantics. The description does not need to add parameter details, and the baseline for a zero-parameter tool applies.
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 identifies the tool's purpose: returning information about the site and how to access interactive panels. It is distinct from the calculation-focused sibling tools, although it does not explicitly name any sibling.
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?
Usage is implied: the tool is for retrieving site information and panel access instructions. However, there is no explicit guidance on when to choose this tool over alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calcula o preço máximo de imóvel compatível com um aluguel mensal máximo informado. Considera parcela de financiamento (PRICE), condomínio, IPTU, manutenção, seguros e custo de oportunidade da entrada. Retorna o preço máximo e o custo mensal estimado nos cenários atual, otimista (taxa -2%) e pessimista (taxa +2%).
| Name | Required | Description | Default |
|---|---|---|---|
| prazoAnos | No | Prazo do financiamento em anos | |
| seguroPct | No | Seguro anual do imóvel (% do valor do imóvel) | |
| entradaPct | No | Percentual de entrada (%) | |
| iptuAnualPct | No | IPTU anual (% do valor do imóvel) | |
| seguroMipDfiPct | No | Seguro MIP/DFI anual (% do saldo devedor) | |
| taxaJurosAnualPct | No | Taxa de juros anual (%) | |
| amortizationSystem | No | Sistema de amortização (PRICE ou SAC) | |
| aluguelMensalMaximo | Yes | Aluguel mensal máximo que o usuário aceita pagar (R$) | |
| condominioMensalPct | No | Condomínio mensal (% do valor do imóvel) | |
| custosManutencaoPct | No | Custos anuais de manutenção (% do valor do imóvel) | |
| custoOportunidadePct | No | Rendimento anual alternativo do capital (%) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose considered cost components and the three scenario outputs. However, it mentions 'parcela de financiamento (PRICE)' while the schema's `amortizationSystem` parameter also supports SAC, inaccurately narrowing the described behavior and omitting a configurable option.
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 compact sentences with no redundant information. The primary purpose is front-loaded, and each sentence adds a necessary layer: the calculation goal, the inputs considered, and the output scenarios.
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 the tool's complexity (11 parameters, no output schema), the description provides a solid high-level contract: purpose, key inputs, and the returned scenarios. It omits default-value assumptions and the SAC option, but the schema handles parameter definitions, so the description remains sufficient for correct invocation.
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 individual parameters are already well documented. The description only restates the cost categories considered (condomínio, IPTU, manutenção, seguros, etc.) without adding new semantic detail beyond 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's specific verb ('Calcula') and resource ('preço máximo de imóvel compatível com um aluguel mensal máximo informado'). It also explains what the tool considers and returns, making it easily distinguishable from siblings like check_affordability or simulate_buy_vs_rent.
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?
Usage context is implied through the phrase 'compatível com um aluguel mensal máximo informado', but there is no explicit statement of when to use this tool versus alternatives, nor any exclusions or examples. The guidance is adequate but leaves the agent to infer the intended scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gera uma recomendação contextual entre alugar e comprar, considerando horizonte de permanência e sensibilidade aos parâmetros de valorização do imóvel e rendimento do investimento alternativo. Retorna horizonte de corte (breakeven patrimonial), veredito ano a ano, thresholds de sensibilidade e um texto de recomendação pronto para o usuário.
| Name | Required | Description | Default |
|---|---|---|---|
| cetPct | No | CET (Custo Efetivo Total) anual informado (%) | |
| itbiPct | No | ITBI (% do valor do imóvel) | |
| prazoAnos | No | Prazo do financiamento em anos | |
| seguroPct | No | Seguro anual do financiamento (% do valor do imóvel) | |
| trHistory | No | Série mensal de TR (% a.m.), ex: [0.0052, 0.0048, ...] | |
| entradaPct | No | Percentual de entrada (%) | |
| inflacaoPct | No | Inflação anual esperada (%) | |
| trMensalPct | No | Taxa mensal de referência TR (%) para correção do saldo devedor | |
| valorImovel | Yes | Valor do imóvel (R$) | |
| iptuAnualPct | No | IPTU anual (% do valor do imóvel) | |
| aluguelMensal | Yes | Aluguel mensal inicial (R$) | |
| fgtsDisponivel | No | Saldo do FGTS disponível para entrada ou amortização (R$) | |
| rentIncreasePct | No | Reajuste anual do aluguel (%) | |
| spreadOverTRPct | No | Spread anual sobre a TR quando indexer = TR_PLUS_SPREAD (%) | |
| financingIndexer | No | Indexador do financiamento: FIXA, TR ou TR_PLUS_SPREAD | |
| insuranceMonthly | No | Seguro MIP/DFI mensal fixo em R$ | |
| amortizationSystem | No | Sistema de amortização (PRICE ou SAC) | |
| taxaValorizacaoPct | No | Taxa anual de valorização do imóvel (%) | |
| custosManutencaoPct | No | Custos anuais de manutenção (% do valor do imóvel) | |
| custoOportunidadePct | No | Rendimento anual alternativo do capital (%) | |
| tempoPermanenciaAnos | No | Horizonte de permanência em anos | |
| amortizacaoExtraMensal | No | Amortização extra mensal (R$) | |
| taxasTransacaoVendaPct | No | Total de taxas de transação de venda (% do valor do imóvel) | |
| taxasTransacaoCompraPct | No | Total de taxas de transação de compra (% do valor do imóvel) | |
| administrativeFeeMonthly | No | Taxa administrativa fixa mensal em R$ | |
| taxaAdministrativaMensal | No | Taxa administrativa mensal do banco (R$) | |
| rendaExtraMensalInvestida | No | Renda extra mensal investida pelo comprador (R$) | |
| condominioMensalPctOfValue | No | Condomínio mensal (% do valor do imóvel) | |
| taxaFinanciamentoNominalPct | No | Taxa de juros nominal anual do financiamento (%) | |
| amortizacaoExtraordinariaMensal | No | Amortização extraordinária mensal (R$) |
| Name | Required | Description |
|---|---|---|
| textoRecomendacao | Yes | Texto formatado com horizontes de corte e thresholds de sensibilidade |
| horizonteCorteAnos | Yes | Número de anos até o breakeven patrimonial (ou null se não houver) |
| thresholdsSensibilidade | Yes | |
| recomendacaoPorHorizonte | Yes | Veredito ano a ano para cada horizonte de permanência |
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 usefully states that the tool returns a breakeven horizon, year-by-year verdict, sensitivity thresholds, and a recommendation text. It does not explicitly state whether the operation has side effects or is read-only, though the wording strongly suggests a pure computation.
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 concise, front-loaded sentences that state the purpose and the exact outputs with no filler. It covers substantial content despite the tool's high parameter count, and every clause 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?
Given a rich 100%-described schema, an output schema, and no annotations, the description supplies the missing conceptual framing: a contextual recommendation tool with breakeven and sensitivity outputs. It could add sibling differentiation, but that gap is covered under usage guidelines. Overall, an agent has enough to understand the tool's role and 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 input schema has 100% parameter description coverage, so the description does not need to document individual parameters. It adds conceptual value by identifying horizon, property appreciation, and alternative investment return as sensitivity drivers. It provides no additional syntax, defaults, or parameter relationship details beyond 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 names a specific verb (Gera), resource (recomendação contextual entre alugar e comprar), and enumerates concrete outputs like breakeven horizon, year-by-year verdict, and sensitivity thresholds. However, it does not explicitly differentiate itself from close siblings like simulate_buy_vs_rent or sensitivity_analysis.
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 use when a contextual buy-vs-rent recommendation is needed, especially when horizon and sensitivity to appreciation and opportunity cost matter. It gives no explicit when-to-use or when-not-to-use guidance and never references sibling tools, so the selection is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Executa uma análise de sensibilidade cruzando taxas de valorização do imóvel com rendimentos do investimento alternativo. Retorna uma matriz onde cada célula indica se compensa comprar (C) ou alugar (A), além do ano de breakeven patrimonial. Reusa o mesmo motor de simulação de simulate_buy_vs_rent.
| Name | Required | Description | Default |
|---|---|---|---|
| cetPct | No | CET (Custo Efetivo Total) anual informado (%) | |
| itbiPct | No | ITBI (% do valor do imóvel) | |
| prazoAnos | No | Prazo do financiamento em anos | |
| seguroPct | No | Seguro anual do financiamento (% do valor do imóvel) | |
| trHistory | No | Série mensal de TR (% a.m.), ex: [0.0052, 0.0048, ...] | |
| entradaPct | No | Percentual de entrada (%) | |
| inflacaoPct | No | Inflação anual esperada (%) | |
| trMensalPct | No | Taxa mensal de referência TR (%) para correção do saldo devedor | |
| valorImovel | Yes | Valor do imóvel (R$) | |
| iptuAnualPct | No | IPTU anual (% do valor do imóvel) | |
| aluguelMensal | Yes | Aluguel mensal inicial (R$) | |
| fgtsDisponivel | No | Saldo do FGTS disponível para entrada ou amortização (R$) | |
| rentIncreasePct | No | Reajuste anual do aluguel (%) | |
| spreadOverTRPct | No | Spread anual sobre a TR quando indexer = TR_PLUS_SPREAD (%) | |
| financingIndexer | No | Indexador do financiamento: FIXA, TR ou TR_PLUS_SPREAD | |
| insuranceMonthly | No | Seguro MIP/DFI mensal fixo em R$ | |
| appreciationRates | No | Valores de valorização anual do imóvel (%) para as linhas da matriz | |
| amortizationSystem | No | Sistema de amortização (PRICE ou SAC) | |
| taxaValorizacaoPct | No | Taxa anual de valorização do imóvel (%) | |
| custosManutencaoPct | No | Custos anuais de manutenção (% do valor do imóvel) | |
| custoOportunidadePct | No | Rendimento anual alternativo do capital (%) | |
| tempoPermanenciaAnos | No | Horizonte de permanência em anos | |
| investmentReturnRates | No | Valores de rendimento anual do investimento alternativo (%) para as colunas da matriz | |
| amortizacaoExtraMensal | No | Amortização extra mensal (R$) | |
| taxasTransacaoVendaPct | No | Total de taxas de transação de venda (% do valor do imóvel) | |
| taxasTransacaoCompraPct | No | Total de taxas de transação de compra (% do valor do imóvel) | |
| administrativeFeeMonthly | No | Taxa administrativa fixa mensal em R$ | |
| taxaAdministrativaMensal | No | Taxa administrativa mensal do banco (R$) | |
| rendaExtraMensalInvestida | No | Renda extra mensal investida pelo comprador (R$) | |
| condominioMensalPctOfValue | No | Condomínio mensal (% do valor do imóvel) | |
| taxaFinanciamentoNominalPct | No | Taxa de juros nominal anual do financiamento (%) | |
| amortizacaoExtraordinariaMensal | No | Amortização extraordinária mensal (R$) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses the output as a matrix with C/Alugar labels and breakeven year, and it reveals that the calculation reuses simulate_buy_vs_rent's simulation engine. It does not mention side effects, but the compute-and-return nature is reasonably clear.
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 dense sentences: the first states the core operation and output, the second adds the engine reuse. No filler or repeated schema information.
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 32-parameter tool without an output schema, the description is on the shorter side, but it covers the essential decision output and the relationship to simulate_buy_vs_rent. The 100% schema coverage compensates for the parameters; the main missing information is explicit guidance on the required appreciation/investment arrays and matrix orientation.
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 baseline is 3. The description adds semantic value by linking the two matrix axes to appreciation rates and alternative returns and by explaining what each cell means, which is not fully captured by the individual parameter 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 opens with a specific verb and resource ('Executa uma análise de sensibilidade'), names the two crossed dimensions, and states the matrix output with C/A decisions and breakeven year. It is easy to distinguish from simulate_buy_vs_rent because it frames the multi-scenario sweep rather than a single scenario.
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 crossing of property appreciation rates with alternative investment returns clearly implies the tool is for sweeping over those two dimensions. The final sentence ties it to simulate_buy_vs_rent's engine, giving the agent context, though it does not explicitly say 'use this instead of simulate_buy_vs_rent' or list exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Executa a simulação determinística "comprar vs alugar" para um imóvel. Aceita parâmetros simples ou múltiplos cenários (pessimista/base/otimista) via campo "cenarios". Retorna veredito, ano e mês de breakeven, vantagem patrimonial final, custos do primeiro mês, snapshots anuais com patrimônio comprador e locatário, e um link para o painel interativo em https://alugar-ou-comprar.vercel.app.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden and does disclose meaningful behavior: the simulation is deterministic and it enumerates returned verdict, breakeven year/month, asset advantage, first-month costs, annual snapshots, and a dashboard link. However, it is silent on assumptions, defaults, and limitations, and its claim of accepting a 'cenarios' field is unsupported by the empty input schema.
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 dense sentence that front-loads the core purpose before covering accepted input modes and return values. It contains no obvious filler, though the long output enumeration could be structured as a list for easier parsing.
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?
No output schema or annotations exist, so the description must carry input, output, and usage context. It lists outputs well but fails to document the actual callable parameters, the scenario format, or when to choose this over related siblings such as sensitivity_analysis and simulate_tr_evolution, leaving a material invocation gap.
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 description adds qualitative parameter information — 'parâmetros simples', multiple scenarios (pessimista/base/otimista), and a field named 'cenarios' — but the input schema declares zero properties. This mismatch makes it impossible for an agent to construct a valid invocation from the provided definition, and no types, shapes, or required fields are specified.
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 opens with a specific action and object: 'Executa a simulação determinística comprar vs alugar para um imóvel.' It clearly conveys the resource and highlights the deterministic nature, distinguishing it from generic simulation tools. It does not explicitly name alternatives, but the purpose is unambiguous.
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 intended use is implied by the tool name and the opening sentence: use it to model buy-versus-rent outcomes. However, there is no explicit 'use when' or 'do not use when' guidance, and no reference to nearby siblings like sensitivity_analysis, so the agent must infer selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retorna uma série mensal projetada de TR (Taxa Referencial) para uso em financiamentos indexados. Modo 'historical' usa os dados de data/tr_historical.json; modo 'projected' usa TR base constante.
| Name | Required | Description | Default |
|---|---|---|---|
| baseTR | No | TR base mensal projetada (% a.m.) | |
| months | Yes | Quantidade de meses da série | |
| scenario | No | Cenário da série: historical ou projected |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden and does well by explaining that 'historical' reads from data/tr_historical.json while 'projected' uses a constant base TR. It does not cover edge cases like default scenario behavior or failure modes, which keeps it from a 5.
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 concise sentences with no filler. The main purpose is front-loaded, and the mode explanation is compressed into the second sentence without redundancy.
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?
The description is mostly adequate for a 3-parameter tool, but because scenario is optional in the schema and no default is documented, it is unclear what happens when scenario is omitted. There is also no output schema, so the description should ideally mention the returned series' format or structure; this gap leaves the definition incomplete.
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 coverage is 100%, so the baseline is 3. The description adds meaningful semantic value by tying the scenario parameter to concrete behavior: historical mode uses the JSON file, projected mode uses the constant TR base, which clarifies the role of baseTR beyond 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 names a specific verb ('Retorna'), a specific resource ('série mensal projetada de TR'), and the domain context ('financiamentos indexados'). This clearly differentiates it from siblings like simulate_buy_vs_rent or calculate_cet.
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 clear context for when to use the tool — any need for a projected monthly TR series — and explains the two scenario modes. However, it does not explicitly mention alternative tools or state when not to use it, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
calculate_cet2 fields changedInput schema / properties / amortizacaoExtraordinariaMensalAdded value: +{
+ "description": "Amortização extraordinária mensal (R$)",
+ "minimum": 0,
+ "type": "number"
+}Input schema / properties / rendaExtraMensalInvestidaAdded value: +{
+ "description": "Renda extra mensal investida pelo comprador (R$)",
+ "minimum": 0,
+ "type": "number"
+}compare_amortization_strategiesrecommendation_contextual2 fields changedInput schema / properties / amortizacaoExtraordinariaMensalAdded value: +{
+ "description": "Amortização extraordinária mensal (R$)",
+ "minimum": 0,
+ "type": "number"
+}Input schema / properties / rendaExtraMensalInvestidaAdded value: +{
+ "description": "Renda extra mensal investida pelo comprador (R$)",
+ "minimum": 0,
+ "type": "number"
+}sensitivity_analysis2 fields changedInput schema / properties / amortizacaoExtraordinariaMensalAdded value: +{
+ "description": "Amortização extraordinária mensal (R$)",
+ "minimum": 0,
+ "type": "number"
+}Input schema / properties / rendaExtraMensalInvestidaAdded value: +{
+ "description": "Renda extra mensal investida pelo comprador (R$)",
+ "minimum": 0,
+ "type": "number"
+}calculate_cet4 fields changedInput schema / properties / amortizacaoExtraMensalAdded value: +{
+ "description": "Amortização extra mensal (R$)",
+ "minimum": 0,
+ "type": "number"
+}Input schema / properties / fgtsDisponivelAdded value: +{
+ "description": "Saldo do FGTS disponível para entrada ou amortização (R$)",
+ "minimum": 0,
+ "type": "number"
+}Input schema / properties / taxaAdministrativaMensalAdded value: +{
+ "description": "Taxa administrativa mensal do banco (R$)",
+ "minimum": 0,
+ "type": "number"
+}Input schema / properties / trMensalPctAdded value: +{
+ "description": "Taxa mensal de referência TR (%) para correção do saldo devedor",
+ "maximum": 100,
+ "minimum": 0,
+ "type": "number"
+}get_rental_yieldmax_price_from_rentrecommendation_contextualsensitivity_analysis4 fields changedInput schema / properties / amortizacaoExtraMensalAdded value: +{
+ "description": "Amortização extra mensal (R$)",
+ "minimum": 0,
+ "type": "number"
+}Input schema / properties / fgtsDisponivelAdded value: +{
+ "description": "Saldo do FGTS disponível para entrada ou amortização (R$)",
+ "minimum": 0,
+ "type": "number"
+}Input schema / properties / taxaAdministrativaMensalAdded value: +{
+ "description": "Taxa administrativa mensal do banco (R$)",
+ "minimum": 0,
+ "type": "number"
+}Input schema / properties / trMensalPctAdded value: +{
+ "description": "Taxa mensal de referência TR (%) para correção do saldo devedor",
+ "maximum": 100,
+ "minimum": 0,
+ "type": "number"
+}calculate_cetcheck_affordabilitygenerate_share_linkget_default_parametersget_municipio_ratesget_site_infosensitivity_analysissimulate_buy_vs_rentsimulate_tr_evolutionClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Deterministic US financial planning: retirement Monte Carlo, Roth conversion, RMD, tax, IRMAA, SS
Deterministic finance tools for AI agents — IRR, NPV, MOIC, DCF, WACC and sensitivity.
Deterministic what-if & scenario simulation for AI agents: projections, sensitivity & break-even.
Deterministic real estate underwriting, deal analysis & reports: Fix & Flip, BRRRR, construction.
Add one secure layer between your agents and this server.
Most tools map to clearly distinct outputs: full buy-vs-rent simulation, sensitivity matrix, CET, affordability, TR series, municipal rates, defaults, share links, and site info. The only potential confusion is between sensitivity_analysis and simulate_buy_vs_rent, since both reuse the same engine and produce buy/rent verdicts, but the descriptions clarify their different inputs and output shapes.
The majority of names follow a clear verb_noun snake_case pattern, with consistent get_* and simulate_* groups. sensitivity_analysis is the one outlier, since it is a noun phrase rather than a verb-led action; run_sensitivity_analysis would have been more consistent.
Nine tools is a well-scoped size for this domain. Each tool covers a meaningful part of the buy-vs-rent workflow, and there is no obvious redundancy or bloat.
The tool surface covers the domain thoroughly: deterministic simulation, scenario sensitivity, affordability, financing costs, TR projection, municipal rates, default parameters, shareable output, and site context. No critical dead-end or missing workflow is evident for the stated purpose.
