RealityCents — Hawaii Mortgage & VA Loan Calculators

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

The annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so "Read-only" largely restates structured data. The privacy constraint ("No personal identifiers") is a genuine behavioral addition, since it tells the agent not to pass names or SSNs, but there is nothing about output shape or rounding/assumption caveats beyond the schema notes.

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 short sentences, front-loaded with the core computation and followed by the return and safety notes. Nothing is padded, though the trailing "Read-only. No personal identifiers." is somewhat clipped rather than fully developed.

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 15-parameter pricing tool with no output schema, the description covers the core calculation and DTI defaults but says only "Returns the payment at that price" about output — no indication of the breakdown (principal, interest, taxes, insurance, PMI) the agent should expect. Annotations and 80% schema coverage fill much of the gap, keeping this at minimum-viable rather than inadequate.

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 80%, so the schema carries most parameter meaning. The description's DTI defaults (45 for VA/FHA, 41 for conventional/jumbo) duplicate the dtiTarget schema text almost verbatim and add no new syntax or constraint information.

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?

It states a specific verb and resource — estimate a maximum purchase price — and names the driving inputs (gross income, debts, DTI target). It does not, however, distinguish itself from close siblings like calculate_mortgage_payment or va_purchase_power, which computes the same figure for VA borrowers.

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 only implied by the input set: an agent can infer this is the reverse of a payment calculator because it takes income and produces a price. There is no explicit when-to-use, when-not-to-use, or routing to the overlapping siblings (calculate_mortgage_payment, va_purchase_power, compare_loans).

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 readOnlyHint, idempotentHint, and destructiveHint=false, so 'Read-only' is largely redundant. However, the caveat that 'The note rate is an example, not a quote' is genuine added context an agent must relay, which slightly exceeds the annotation coverage.

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 compact sentences, front-loaded with the core purpose and output scope, followed by the read-only and disclaimer notes. No filler, though the sentence structure is slightly compressed.

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, the description carries the return-value burden and does so reasonably by specifying year-by-year breakdown vs upfront cost. The two undocumented numeric params (noteRate, termYears) are the main remaining gap, but the required inputs are enumerated.

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%, but the description's naming of the buydown variants partially maps to the buydownType enum, a value already visible in the schema. It adds little meaning for noteRate, termYears, or loanAmount beyond what the schema states, so it only marginally compensates for the coverage gap.

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?

Specific verb+resource ('Calculate buydown') with explicit output scope: year-by-year P&I and subsidy cost for temporary buydowns vs upfront cost for permanent points. This clearly distinguishes it from siblings like calculate_mortgage_payment and calculate_affordability.

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 the tool applies by enumerating buydown products (2-1, 1-0, 3-2-1, permanent points), but gives no explicit when/when-not guidance or named alternatives among the many sibling calculators. Usage is inferable from the product list rather than stated.

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 readOnlyHint, idempotentHint, and destructiveHint=false, yet the description adds genuinely new behavioral context: explicit PII restrictions (no name, email, phone, SSN, street address) and the caveat that rates are illustrative, not quotes. It stops short of describing pagination or output shape, but the PII and disclaimer details are real value beyond the annotations.

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 tightly packed sentences with zero filler, and the core purpose (PITI for a Hawaii purchase) is front-loaded ahead of the compliance caveats.

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 14-parameter, output-schema-less calculator, the description conveys what is computed and what data must not be supplied, supplemented by a rich schema. It could mention the shape of the returned estimate, but coverage is otherwise strong.

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 86%, so the schema already documents nearly every parameter (defaults, ranges, PITI components, PMI vs MIP vs funding fee branching). The description reinforces the PITI component set but adds no syntax or format detail the schema lacks; 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?

States a specific verb (Estimate) and a precisely scoped resource (PITI for a Hawaii purchase) and enumerates the components it covers: principal/interest, property tax, insurance, HOA, and PMI/MIP/VA funding fee. This clearly distinguishes it from siblings like compare_loans, calculate_buydown, or calculate_affordability.

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?

Provides guardrails ('Read-only', no PII fields, rates are examples not quotes) which imply a planning/estimation context, but never states when to choose this tool over calculate_buydown, compare_loans, or rent_vs_buy. Usage is implied rather than routed.

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 readOnlyHint, idempotentHint and destructiveHint=false, so the 'Read-only' line largely repeats structured data. However, it adds two useful facts not in annotations: 'Rates are examples' (data reliability disclaimer) and the return contents (payment, cash-to-close, total interest), which matters since no output schema exists.

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 short sentences, front-loaded with the operation and scope, then outputs, then the read-only/rates disclaimer. No filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description usefully names the three returned values, which is more than most. But for a 9-parameter nested tool with 0% schema coverage it leaves multiple input parameters unexplained and gives no guidance on rate/cost assumptions.

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% across 9 top-level params and nested scenario fields, so the description must carry the load. It mentions loan type, rate, down payment, term and discount points, but omits creditScore, hoaMonthly, insuranceMonthly, propertyTaxRatePercent, monthlyTaxOverride, vaFirstUse/vaDisabilityExempt, and never clarifies downPaymentUnit or the points 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 (compare) and resource (2-4 loan scenarios) and enumerates the dimensions compared (type, rate, down payment, term, points) on a single purchase price. It does not distinguish itself from calculate_mortgage_payment or calculate_buydown, so it stops short of 5.

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 'compare 2 to 4 scenarios' framing implies this is the multi-scenario tool versus the single-payment siblings, but it never says when to pick it over calculate_mortgage_payment or when not to use it. Usage is implied rather than stated.

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 readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered structurally. The description adds genuine extra context beyond the annotations: it states the data is public and that the tool 'does not ask for or store personal information', which is a meaningful privacy/data-handling disclosure.

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 short sentences, front-loaded with the returned artifacts and followed by the privacy note. Every clause carries information with no 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?

For a zero-parameter, read-only retrieval tool whose annotations cover the safety profile, the description is essentially complete. It could optionally hint at the return shape (e.g., that the link/contact is returned verbatim), but nothing needed to invoke it correctly is absent.

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 takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. No syntax or input details are needed or missing.

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 (Jay Miller's public CMG Home Loans application link) and a second concrete output (published business contact), with a clear retrieval verb. It is unmistakably distinct from the calculator/guidance siblings, though it never explicitly contrasts itself with 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 use (get a pre-approval/application link) is implied by the name and description, but there is no explicit when-to-use guidance, no mention of the sibling tools, and no stated prerequisites or conditions for calling it.

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 read-only/idempotent/no-side-effects, so the bar is lower. The description still adds useful provenance ("Drawn from RealityCents articles") and a scope exclusion ("No rate quotes"), implying static, possibly non-live content. It does not disclose staleness/update frequency, which would matter for 2026 loan limits.

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 the content type, followed by the topic enumeration and two short constraint sentences. Every sentence earns its place; only the near-duplication of the enum values is slightly wasteful.

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-enum, read-only lookup with no output schema, the definition conveys enough: what it returns (concise factual notes), its source, and its exclusions. Missing only a hint about return shape/format and content currency.

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 topic enum enumerates the allowed values, and the description restates them in prose (property tax, VA loans, leasehold vs fee simple, condo approval, loan limits, BAH/COLA, closing costs, pre-approval). This mirrors the schema rather than adding semantics about what each topic returns, and schema description coverage is 0%.

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?

Names a specific resource and content type: factual notes on a defined set of Hawaii mortgage topics, sourced from RealityCents articles. It is clearly distinguishable from the calculator siblings, though the verb is implied ("notes on...") rather than stated as an explicit action.

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 "No rate quotes" boundary is a real when-not signal, and the topic list implies this is for static reference facts rather than computation. However, it never explicitly says to use this instead of va_purchase_power or calculate_* when the agent wants numbers versus facts.

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 readOnly/idempotent/non-destructive, but the description adds material context: what comes back (status, VA ID, data date, official lookup link), the PII prohibition, the current Oahu-only scope, and the caveat that VA approval does not guarantee loan approval. 'Read-only' restates the annotation, but the rest earns its place.

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 tight sentences, front-loaded with the purpose, followed by return content and then constraints/caveats. No filler or 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?

No output schema exists, but the description names the returned fields (status, VA ID, data date, verification link). Combined with the scope limit, PII rule, and approval caveat, an agent has everything needed to call and interpret this 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 is 100%, and the schema already documents both parameters including fuzzy matching, okina/spelling tolerance, the VA ID format example, and the PII warning. The description only restates the accepted query forms, adding no syntax or format detail beyond the schema, so baseline 3 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?

States a precise verb (check/look up) and resource (Oahu condo on the VA accepted condo list), plus the three lookup key types. This is clearly distinguishable from the calculator and guidance siblings.

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 clear context ('Check whether an Oahu condo project is on the VA's accepted condo list') and a geographic exclusion ('Oahu only for now'), plus a data-hygiene exclusion ('Do not send a unit number or personal information'). It does not explicitly name which sibling to use instead for other VA topics, so no explicit alternative routing.

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 readOnlyHint, idempotentHint, and destructiveHint=false, so the 'Read-only' line in the description is largely redundant. The description does add two non-schema behavioral facts: the 0.35% Honolulu property-tax default applied unless overridden, and the explicit limit that this is not a forecast — genuinely useful context beyond the annotations.

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 short sentences with the core computation front-loaded, followed by the default assumption and the negative scope. Every clause carries information; nothing is padding.

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 exists, so the description should signal what the comparison returns (e.g., net difference, break-even year), and it does not. Combined with 18 mostly undocumented parameters and a low schema coverage rate, the definition is under-specified for a computation of this complexity.

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 18 parameters and only 28% schema description coverage, the description must carry weight, yet it only mentions one parameter implicitly (the 0.35% tax rate default). Critical inputs such as loanType, vaFirstUse, vaDisabilityExempt, creditScore, downPaymentUnit, and sellingCostPercent receive no interpretive guidance, leaving most of the parameter surface undocumented.

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 comparison ('Compare cumulative rent with the net cost of buying over a holding period') and names the dimensions compared, which cleanly distinguishes it from mortgage-payment, affordability, and buydown siblings. The closing 'Not a price or rent forecast' sharpens the tool's remit further.

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 scenario (choosing between renting and buying) and notes a Honolulu tax default, but gives no explicit when-to-use guidance or routing versus siblings like calculate_affordability or compare_loans. The exclusion of forecasting is useful but is a scope boundary, not a usage 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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so 'Read-only' adds nothing, but the description contributes genuinely new behavioral context: the 2026 pay-table data source (which bounds output validity) and an explicit PII constraint ('Do not send a name or SSN'). It still does not describe the response shape or any limits beyond that.

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 tight sentences, front-loaded with what is computed and then the data source and safety note; no filler. It is close to optimally sized for a short description, though the parameter coverage gap suggests some budget could have been spent there instead of restating 'Read-only'.

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 13-parameter financial calculator with no output schema, the description establishes the domain and key inputs but omits what the result actually contains (monthly payment, price, income breakdown) and how the major optional levers (rate, maxDti, tax/insurance) shape the estimate. Annotations cover safety, so the remaining gap is about the assumptions and outputs of the calculation.

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 46% across 13 parameters, so the description is expected to compensate and does not. It names just three inputs (pay grade, years of service, dependents) and leaves rate, maxDti, downPayment, hoaMonthly, otherDebts, vaFirstUse, vaDisabilityExempt, insuranceMonthly, monthlyTaxOverride and propertyTaxRatePercent entirely unexplained in prose.

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?

Specific verb (estimate) plus a well-scoped resource: Honolulu County military income components (base pay, BAH, BAS, COLA) and a VA purchase price, with the data source named (RealityCents 2026 pay tables). It is clearly distinct in flavor from generic siblings like calculate_affordability, but it never explicitly names or rules out the closest alternative (calculate_affordability, va_remaining_entitlement), so sibling differentiation is left to inference.

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 by the input framing ('from pay grade, years of service, and dependents') and the Honolulu/military scope, which tells an agent roughly when this applies. However there is no explicit when-to-use statement, no exclusion (e.g. vs calculate_affordability), and no prerequisites, so the agent must infer routing.

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 readOnlyHint and idempotentHint, so safety is covered. The description adds a genuinely useful behavioral rule not in the annotations or schema enum: $0 entitlement is treated as full entitlement with no county cap, which changes how the caller should interpret inputs. The trailing 'Read-only' merely repeats the annotation.

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 dense sentence front-loads the computation and its outputs, with the edge-case rule second. Nearly every clause earns its place, though the closing 'Read-only' is redundant with the annotation.

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, the description correctly enumerates what the caller gets back (remaining entitlement, max $0-down loan, down payment), which is exactly the missing piece. Coverage of the $0 edge case and the county cap makes it complete enough to call without ambiguity.

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 67%, with county and entitlementAlreadyInUse documented in the schema itself. The description restates the $0/entitlement rule and ties county to a conforming-limit cap, but adds nothing about purchasePrice syntax or the interaction between the in-use amount and the county limit calculations. 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?

States a specific computation with three concrete outputs (remaining entitlement, max $0-down loan, and the 25% down payment above that), which is far beyond a tautology. It does not, however, name or contrast itself with the closest sibling, va_purchase_power, so sibling differentiation is left to inference.

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 scope ('For a Hawaii county') implies when the tool applies, but there is no explicit when-to-use guidance and no mention of alternatives such as va_purchase_power or calculate_affordability, even though those siblings overlap in territory. Usage is implied rather than directed.

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