Relendi — Commercial Real Estate Loan Tools

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

With no annotations provided, the description carries the full burden and does so well. It discloses the calculation order, the conditional NY CEMA behavior, and the critical failure mode where omitting prepaymentPenaltyPercent overstates borrower proceeds. It stops short of describing exact output shape or side effects, but for an analysis tool this is strong transparency.

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, front-loaded sentences with no filler. The waterfall concept and the critical prepayment-penalty warning each earn their place 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?

Given 11 parameters, no output schema, and no annotations, the description gives a coherent mental model of the computation and the key required-input warning. It does not spell out optional-parameter defaults or full output field names, but the described waterfall is enough for correct selection and 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 coverage is only about 18%, so the description must compensate. It does so by mapping the loan-size constraints (LTV, DSCR, debt-yield) and by explaining the prepayment penalty semantics and the 'state 0 explicitly' rule. The remaining parameters like NOI, property value, and amortization years are not individually explained, but their meanings are clear from context.

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, compound objective — a 'full cash-out refinance waterfall' — and enumerates its outputs from the largest supported loan through payoff, prepayment penalty, and closing costs to net cash. This clearly differentiates it from siblings like size_loan and estimate_closing_costs, even without naming them.

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 scenario (cash-out refinance analysis) is strongly implied by 'Full cash-out refinance waterfall,' and the NY CEMA qualifier adds a state-specific condition. However, there is no explicit when-to-use versus alternatives guidance or exclusions, so the agent must infer the choice from the tool's name and content.

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

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

No annotations are provided, so the description carries the full burden. It does disclose that the answer is 'short', 'grounded in Relendi's knowledge base', and includes 'citations' – useful response-format information. However, it does not discuss caveats like answer precision, the possibility of no answer, or the relationship to knowledge-base search, leaving some behavioral ambiguity for a no-annotation tool.

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, no waste. The primary purpose is front-loaded, and the routing guidance to exact alternatives is placed second. 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?

The description covers the core call flow and gives a partial return description ('short answer ... with citations'). However, with no output schema and no annotations, it leaves unaddressed how this tool differs from the sibling search_cre_knowledge, and it does not state whether the answer is generated or retrieved. An agent might be uncertain which of the two knowledge-related tools to pick.

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 0%, so the description must compensate. It does clarify that the 'question' parameter should be plain-English and on the topic of commercial real estate lending, adding domain context beyond the bare schema name. But it stops short of giving examples, question-quality guidance, or expected phrasing, so compensation is only partial.

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?

States a specific verb ('ask'), a concrete resource ('Relendi's knowledge base'), and the expected output ('short answer ... with citations'). It also distinguishes itself from the exact-math siblings size_loan and run_scenario, so an agent can tell what this tool is for at a glance.

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?

Explicitly tells the agent when not to use this tool: 'For loan math prefer size_loan or run_scenario, which are exact.' This is a clear when-not statement with named alternatives. It implies the appropriate use for plain-English conceptual questions, giving the agent the decision rule it needs.

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

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

With no annotations provided, the description carries the burden. It discloses that metrics are computed on-demand based on available inputs)Skip the format is not described, but the absence of an output schema means the description should at least hint at return structure; it does not, but the partial-input behavior is a good disclosure. Since the tool is non-mutating and purely computational, the lack of side-effect warnings is less critical. However, no annotation context means the description could be more explicit about return format or error handling, hence a 4.

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 lists the metrics and the second explains the partial-input behavior and directs away from self-computation. Every word earns its place, with no fluff. The purpose is front-loaded with the list of metrics, and the usage guidance is concise.

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 complexity (10 parameters) and lack of output schema and annotations, the description is surprisingly strong. It covers what metrics are returned restricted to input availability, and it explicitly advises against self-computation. The only gap is that it doesn't describe the exact output schema (e.g., JSON structure of metrics and formulas), but since the tool is computational and the description clearly states the provided metrics, an agent can infer the output. For a tool with this complexity, it provides most of the needed context, hence a 4.

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 60%, meaning some parameters are documented in the schema (e.g., rate as decimal, annualDebtService as annual). The description adds context that all parameters are optional and that metrics are computed from whatever is supplied, which is a valuable semantic beyond the schema. It also explicitly says each metric is returned only when inputs are present, guiding parameter usage. This compensates for the 40% of parameters that lack schema descriptions, though the description does not enumerate specific parameter relationships (e.g., how NOI derives from revenue - expenses), which the schema partially does. Given the high parameter count and partial coverage, this is strong.

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 computes a specific set of commercial real estate underwriting metrics from raw figures, naming each metric (NOI, cap rate, DSCR, etc.). It distinguishes itself from siblings by explicitly saying to use it instead of computing CRE ratios yourself, which differentiates it from tools like calculate_payment or size_loan.

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 explicitly instructs agents to supply whatever data is available and notes that each metric is returned only when its inputs are present, which guides when to use the tool (when raw figures are available) and implicitly when not (when you need a single payment calculation, use calculate_payment). It also says to use this instead of self-computation, providing clear usage direction.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It transparently lists expected outputs and explains the balloon-balance behavior when the term is shorter than amortization, which is useful. However, it does not disclose default behavior when optional fields like termYears, amortizationYears, or interestOnly are omitted, so behavior beyond the happy path remains hidden.

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 with no wasted words. It front-loads the core purpose, then lists outputs, then adds a helpful illustrative CRE example. 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?

The description is strong on outputs and the key balloon case, but given no output schema and no annotations, it omits important invocation details such as defaults for optional parameters and how the tool behaves when only required fields (loanAmount and rate) are provided. This is a meaningful gap for an agent deciding how to call the tool correctly.

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 only 40%, so the description must compensate. It adds meaning to termYears and amortizationYears by explaining the balloon relationship, and references interest-only behavior. But it does not clarify loanAmount semantics or the effect of omitting optional fields, leaving some parameter meaning to inference.

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 and operation: payment math for a commercial loan, including amortizing and interest-only modes, with concrete output concepts (monthly/annual debt service, total interest, balloon balance). This clearly distinguishes it from siblings like calculate_metrics, size_loan, or compare_loan_offers based on its unique scope.

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 for payment calculations and highlights the common CRE case of a 10-year term on a 30-year schedule, but it does not explicitly state when to choose this tool over siblings such as calculate_metrics or run_scenario, nor does it provide exclusions or alternatives. Usage context is implied rather than explicit.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It discloses the central behavior (accounting for fees over the actual term), the sorting intent, and the returned values (effective rate, total cost, fee burden in basis points). It does not cover edge cases or assumptions, but the core behavior is transparent and non-misleading.

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, efficient sentence that front-loads the primary purpose and then adds only necessary detail. Every clause contributes: the comparison basis, the major fee categories, the actual-term consideration, and the returned outputs.

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 tool with no output schema and no annotations, the description adequately explains what is returned and why ranking is done correctly. It does not list input requirements, but the schema covers those constraints reasonably well. Minor gaps remain around exact output structure and fee semantics, but the description is largely sufficient for an agent to call and interpret the tool.

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 for the top-level parameter is 0%, so the description needs to compensate. It mentions origination, exit, and other fees, but it does not explain the required fields (loanAmount, interestRate, term) or clarify fee units. The nested schema provides some help for a few fields, but the description itself adds limited parameter-level meaning beyond fee categories.

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 ('Rank') and resource ('competing loan offers'), and clarifies the distinguishing criterion ('true cost of capital, not headline rate'). This differentiates it from sibling payment or metric tools without needing to open the schema.

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 clearly implied: use this when multiple loan offers need to be compared by all-in cost. However, it does not explicitly state when not to use it or name alternative tools for simpler single-loan calculations, so the guidance is inferred rather than explicit.

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

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

With no annotations available, the description properly takes on the burden: it states the output behavior, the categories produced, and a non-obvious calculation rule (NYC taxes are several times upstate rates and one NYC tax doesn't exist outside the five boroughs). It doesn't discuss side effects, auth, or limitations, but for a read-only estimation tool the disclosed behavior is largely sufficient.

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?

Three sentences, with the purpose and resource front-loaded, output summarized in the second sentence, and the critical NYC caveat placed last. No filler; each 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 12-parameter tool with no output schema and only 17% schema description coverage, the description covers purpose, output, and the most important jurisdiction-specific rule, but it omits guidance for the many optional parameters and the CEMA option for NY refinances. A competent agent could use the schema descriptions for isNYC and cemaEnabled, so the main gap is the optional fee/tax inputs; overall it is adequate but not fully complete.

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 only 17% (isNYC and cemaEnabled have descriptions), so the tool description needed to compensate for the other 10 parameters. It reinforces isNYC and names output categories, but it doesn't clarify the basis for percent parameters (e.g., originationFeePercent, brokerFeePercent), when optional inputs like existingMortgageBalance are needed, or how optional fields interact with the estimate. The bare parameter names are partially self-explanatory, but the description adds little semantic precision 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 opens with 'Itemize commercial closing costs for a New York or Florida transaction' — a specific verb and resource — and enumerates cost categories (lender, title, government, prepaid, third-party). It also states the output ('Returns every line item plus totals'), making the tool's scope and deliverable unambiguous relative to siblings like calculate_payment or analyze_cash_out_refinance.

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 gives clear operating context (NY or FL commercial transactions) and a mandatory NYC/upstate distinction, but it never explicitly says when to prefer this tool over calculate_payment, compare_loan_offers, or other siblings. The use case is implied by the named resource ('closing costs') rather than stated as an explicit when/when-not rule.

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

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

No annotations are present, so the description carries the full burden; it discloses that execution is deterministic and that it mirrors size_loan's math, which is meaningful for a calculation tool. It does not address side effects, output shape, or failure modes, but for a pure what-if calculator the determinism statement provides baseline transparency.

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 tight sentences front-load the action and modes, and the second sentence adds a useful deterministic/swept qualifier without redundancy. No filler or wasted 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 tool with 8 parameters, a nested thresholds object, no annotations, and no output schema, this description is too sparse to guide a correct call. It does not explain how to assemble a rate ladder or NOI sensitivity run, which constraints are needed, or what the result shape is, so an agent would need to consult size_loan or guess.

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?

With 0% schema description coverage, the description was expected to compensate, but it only loosely maps modes to concepts ('rate ladder', 'NOI sensitivity table', 'feasibility...constraint') and never names the arrays, nested thresholds, required netOperatingIncome/estimatedValue, or totalCost. The agent is left to infer parameter roles from field names and sibling behavior, which is insufficient for 8 parameters.

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 concrete action ('run what-if loan sizing'), enumerates the three supported modes, and anchors the tool in relation to a sibling ('same math as size_loan, swept'), so an agent can tell it apart from a single-point size_loan call. The core purpose is unambiguous and specific.

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 explicitly frames the tool for 'what-if' and 'range of assumptions', which describes when to reach for it. The reference to size_loan and 'swept' hints that a single deterministic sizing could go to size_loan, but it does not spell out when-not-to-use or alternatives such as stress_test.

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

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

No annotations are provided, so the description must carry the full behavioral burden. It does disclose that results are 'source-cited excerpts' and implies a read-only search operation. However, it does not mention whether the search is fuzzy or exact, how results are ordered, or any rate limits. Since the description adds some behavioral nuance (source-cited, grounding intent), a 3 is fair; it is not a harmful omission.

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 long, with the purpose front-loaded in the first sentence and the usage guidance in the second. Every word earns its place; there is no redundant phrasing or 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 the complexity (a knowledge-base search) and the absence of an output schema, the description is fairly complete for basic usage. It tells the agent what it searches and why to use it. However, it does not describe the format of the returned excerpts (e.g., list of strings, metadata) or specify whether the query should be a question or keywords. With no output schema, a bit more on return format could help, but the basics are covered. A 3 is reasonable.

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 0%, so the description must add meaning beyond the schema. The description mentions the query concept but does not elaborate on the 'topK' parameter (e.g., how many results are returned, default value, or its impact on results). The schema already defines topK as an integer 1-5, but the description adds no value for parameter semantics. Thus, a baseline 3 applies because the parameters are simple and self-explanatory.

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 a specific verb ('Search') and resource ('Relendi's curated commercial-real-estate knowledge base'), and specifies what it contains ('lending concepts, deal lifecycle, typical fees and timelines'). It also notes that results are 'source-cited excerpts', which distinguishes it from general Q&A tools like ask_cre_question.

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 explicitly says to use it 'to ground CRE answers rather than relying on memory', which provides clear guidance on when to use it. It implies that for general Q&A without needing grounding, one might use ask_cre_question, and the sibling list confirms alternatives, so the usage context is well-defined.

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

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

With no annotations, the description carries the burden. It discloses that the tool performs deterministic math, which implies no side effects or randomness, and clarifies that it does not quote lender terms, setting expectations. It does not detail error handling or edge cases, but for a calculator that's acceptable.

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 sentences that front-load the purpose and method, with no redundant information. It efficiently communicates the essential behavior and boundary.

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 explains the output concept (minimum of constraints and which binds) which is essential since there is no output schema. It also sets the boundary that it doesn't quote lender terms. It doesn't specify the exact return format, but the concept is clear enough for an agent to use the tool.

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 mentions the four constraints (LTV, DSCR, debt yield, LTC) which correspond to the thresholds object parameters, adding context beyond the schema's dry property descriptions. However, it does not elaborate on the individual input parameters like NOI or estimated value beyond what the schema already states, so the added value is moderate.

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 function: sizing a commercial real estate loan from first principles, and specifies the method (minimum of four constraints) and the output (max supportable loan plus binding constraint). This distinguishes it from sibling tools like compare_loan_offers or calculate_payment, which serve different purposes.

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 usage for loan sizing from first principles and explicitly states it does not quote lender terms, which hints at boundaries. However, it does not name specific alternative tools or provide explicit when-to-use/when-not-to-use guidance beyond that boundary, so it's only partially informative.

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

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

With no annotations, the description carries the full burden. It transparently explains what happens (stress testing against specified shocks) and what is returned (stressed DSCR and verdicts). The unit clarification for rates is valuable. It does not address side effects, but the 'returns' phrasing implies a read-only calculation, which is reasonable for this tool.

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?

Three sentences with no filler. The first sentence front-loads the action and scenarios, the second states the output and verdict, and the third gives the critical unit caveat. 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?

The description covers scenarios, return value, verdict types, and rate units, which is strong for a no-output-schema tool. However, it omits the meaning of minDscr and the exact stress-test scenario parameters, leaving the agent to infer some input semantics from the schema names.

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 only 33%, so the description needs to compensate. It adds only the rate-unit clarification, which is already present in the rate schema description. It does not explain minDscr, which appears to be the pass/marginal/fail threshold, nor does it clarify how propertyValue, loanAmount, or netOperatingIncome feed the scenarios.

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 ('Stress'), a specific resource ('a loan'), and the exact scenarios tested (rate shocks, income decline, combined). It also names the output (stressed DSCR per scenario with pass/marginal/fail verdict). It does not explicitly differentiate from sibling run_scenario, but the specialized scope is clear.

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 the tool: whenever a loan needs credit-committee-style stress testing. It mentions the scenario types and outputs, giving an agent enough context to select it. However, it gives no explicit guidance about when not to use it or which sibling alternative (e.g., run_scenario, calculate_metrics) would be more appropriate.

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