Duneland Financial acquisition financing tools

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

Annotations already establish that this is a read-only, idempotent, non-destructive, closed-world calculation. The description adds useful behavioral context by explaining that the senior loan is solved as the remainder and listing the outputs, but it does not discuss assumptions around fixed senior amounts, DSCR targets, or standby-interest handling beyond what the schema covers.

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 front-loaded with the core operation and remainder-solving behavior, then efficiently lists inputs and outputs before closing with the usage condition. It is dense but every sentence contributes information, and there is 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?

For a 21-parameter modeling tool, the description is appropriately complete when read alongside the fully documented schema, annotations, and output schema. It covers the purpose, general inputs, outputs, and use case, though it could mention the fixed seniorAmount alternative and targetDSCR comparison more explicitly.

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 parameter meanings are already fully documented. The description groups the key inputs—price, working capital, closing costs, equity sources, seller-note terms, senior-loan terms, and cash flow—but adds little semantic detail beyond the schema defaults, ranges, and enum documentation.

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 action and object: laying out sources and uses for a business acquisition and solving the senior loan as the remainder. It goes beyond the title by specifying outputs such as the funding gap, source shares, debt service, coverage, and sensitivity, which distinguishes it from a generic acquisition-loan model.

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 an explicit use condition: 'Use when the user asks how the whole purchase gets funded.' That is clear context, but it does not state when to avoid this tool or name sibling alternatives such as model_acquisition_loan or model_seller_note.

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?

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. Beyond that the description adds genuinely useful output context (DSCR measured against a 1.25 reference and an illustrative 1.50) and two explicit scope limits — it does not determine eligibility or approval and is illustrative, not a commitment. It stops short of describing sensitivity or precision behavior.

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 front-loaded sentences: what it computes, what it returns, and the usage/disclaimer clause. The closing pair ('do not determine eligibility or approval' and 'Illustrative, not a commitment') is mildly redundant but each targets a different concern, so little is wasted.

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 an output schema present, the description need not enumerate return fields, and it correctly spends its budget on the computation chain and the eligibility disclaimer appropriate for a lending heuristic. For a 13-parameter model with a rich schema, the remaining gap is only the untested effect of optional inputs and how the 1.25/1.50 benchmarks should be interpreted.

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 every parameter already carries its own description, units and defaults; the baseline is therefore 3. The description mentions four of the thirteen inputs and hints at the deduction logic ('after a market salary and capex'), but adds no meaning beyond the schema for add-backs, seller note terms, standby, or existing debt service.

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 and resource ('Test whether a business acquisition supports its debt') and enumerates both the inputs consumed and the metrics produced (cash flow, senior loan, debt service, DSCR). It implies its position relative to siblings by saying 'Use this first', but it never names model_acquisition_loan or screen_sba_eligibility, so the differentiation is indirect rather than explicit.

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 a clear entry condition: 'Use this first when the user has a price and earnings', which tells the agent when this tool is the right starting point. It does not state when to skip it in favor of a sibling, nor what to do when the user lacks earnings, so a routing gap remains.

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?

Annotations already cover the safety profile (readOnlyHint, idempotentHint, non-destructive, closed-world), so the description's job is to add behavior — and it does, disclosing the DSCR is only returned when cash flow is supplied and that a balloon appears at maturity. It does not mention rounding, rate convention, or error behavior, which keeps it short of 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 tight sentences, front-loaded with the operation before the usage trigger; no filler. The enumeration of return values is mildly redundant given an output schema exists, which is the only thing keeping it from a 5.

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 single-purpose financial calculator with full schema coverage and an output schema, nothing an agent needs to call it correctly is missing — inputs, outputs, conditional DSCR behavior, and the usage trigger are all present.

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 every parameter already has units and defaults documented. The description restates the parameter list (principal, rate, term, amortization period, optional cash flow) and echoes the balloon/term relationship already in the amortizationYears schema text, adding no new semantics.

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 and resource — 'compute the payment and amortization of a senior acquisition loan' — and enumerates the exact inputs and outputs. The 'senior acquisition loan' scope is clearly distinguishable from siblings such as model_seller_note or screen_sba_eligibility without opening any 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?

Gives an explicit trigger: 'Use when the user asks what a loan of a given size costs each month or year.' That is a clear usage context, but no exclusions or named alternatives (e.g. when to prefer build_capital_stack or model_seller_note instead) are provided.

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?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is fully covered without the description. The description adds computational context (it enumerates what gets modelled), but it does not disclose assumptions such as how standby months interact with the amortization clock, or that the tool is a pure calculation with no persistence. Much of the "Returns ..." sentence duplicates the output 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?

Three well-ordered sentences: what it models, what it returns, when to call it. Purpose is front-loaded and there is no filler. The output enumeration is dense and partly redundant with the output schema, which keeps it from a 5.

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 10-parameter pure calculator with a full output schema and complete annotation coverage, the agent has enough to call it correctly: purpose, mode options, and trigger are all stated. What is missing is sibling disambiguation and any note on the interplay between maturityYears and amortizationYears beyond the schema's one-line hint.

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 and the schema already explains units, defaults, ranges and both enums in detail. The description adds only framing for the parameter families (repayment mode, standby treatment, coverage inputs), which is marginal but not zero value.

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?

Opens with a specific verb and resource: "Model seller financing in a business acquisition," and names the mechanics it covers (amortizing or interest-only, standby months, interest treatment). It is clear on its own, but it never distinguishes itself from the sibling model_acquisition_loan, which an agent could plausibly reach for on the same request.

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?

"Use when the user asks what a seller note costs or what is owed at the end" gives an explicit trigger in user-intent terms, which is genuinely useful for routing. There are no exclusions or named alternatives, so the agent must infer that senior/debt financing belongs to model_acquisition_loan or build_capital_stack.

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?

Annotations already cover the safety profile (read-only, idempotent, non-destructive), so the bar is lower, and the description still adds real behavior: add-backs are itemized with a parallel conservative case, double-counted adjustments are excluded, and multiples must come from the user. It stops short of describing validation failures or how the conservative case is derived beyond the refusal of double-counts.

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, front-loaded with the core operation and each carrying distinct information (what it computes, when to use, what it won't do). The parenthetical phrase 'with a conservative case alongside' is slightly clunky, and the return-value sentence is partly redundant with the output schema.

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 nine-parameter, single-required-input computation tool with a full output schema, the description covers the operation, the user intent that selects it, the user-supplied multiple constraint, and the exclusion of industry multiples. Nothing an agent needs to invoke it correctly is missing, and the accurate output listing is harmless redundancy.

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 earns a point by conveying the relationship between inputs — the conservative case maps to includeInConservative, and the multiple range is explicitly user-supplied rather than inferred. It does not explain the bridge deductions or the basis enum beyond what the schema already documents.

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 and resource — normalize earnings into SDE, bridge to debt-service cash flow, apply a user-supplied multiple range — and the domain (valuation math) is clearly distinct from the financing-oriented siblings (build_capital_stack, model_acquisition_loan, screen_sba_eligibility). It also states a negative scope boundary: 'The tool does not supply industry multiples.'

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?

'Use when the user asks what the earnings are or what the business is worth on them' gives an explicit triggering condition rather than implied usage. The exclusions are partial — it rules out supplying multiples but does not say when a sibling (e.g. check_deal_affordability) should be reached for instead.

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?

Annotations already establish readOnly/idempotent/non-destructive, but the description adds real behavioral context the schema cannot: results are tri-state (pass/review/constraint) with source and verification status, and most rules default to review. The explicit warning that no input combination yields "eligible" is exactly the expectation-setting an agent needs before relaying results to a user.

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?

Front-loaded with purpose, then the return shape, then the critical caveat and trigger — a sensible ordering with no filler. The nine-item rule enumeration is dense and slightly list-like, but each item maps to a distinct parameter, so it earns its space.

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 nine optional enum parameters and an existing output schema, the description covers everything an agent needs: what it screens, what comes back, how to interpret the weakest outcome, and when to reach for it. Nothing about calling it correctly is left to inference.

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% and each parameter carries its own question text plus omission guidance, so the schema does the heavy lifting. The description's rule list mirrors the parameter set (citizenship, size standard, change of ownership, equity injection, seller note standby, credit elsewhere) but adds no syntax, threshold, or weighting detail beyond it. 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?

Opens with a specific verb and resource ("Screen a business acquisition against baseline SBA 7(a) requirements") and then enumerates the nine rule domains covered, so its scope is unambiguous. It is clearly a pre-qualification screener rather than a modelling tool, which distinguishes it from siblings like model_acquisition_loan or build_capital_stack.

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 states the trigger condition: "Use when the user asks whether an SBA loan is an option." It also sets a firm boundary on interpretation — "This is a screen, not an eligibility finding... no answer produces 'eligible'." It does not name a sibling alternative or state when to skip this tool in favour of a full eligibility review, so it stops short of a 5.

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