KeyReady — Australian home loan readiness

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

Annotations already declare readOnly, idempotent and closed-world, so the safety profile is covered. The description earns credit for enumerating the outputs (lender fit count, borrowing power, LVR, stamp duty, grants, scheme eligibility, LMI waivers, fixes, report link) since there is no output schema, though it omits caveats such as results being estimates against published policy rather than approvals.

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: the first front-loads the core action, the second packs the return values into a dense list with no filler. Slightly long return enumeration, but each item is a distinct result the caller needs.

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 23-parameter financial assessment with no output schema, the description gives a reasonable picture of what comes back but says little about input expectations or the estimates-vs-approvals nature of the output. Adequate, but gaps remain for a tool 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 23 parameters and only 61% schema description coverage, the description adds essentially nothing about inputs — no explanation of how savings/gift/loan interact, what 'site' controls, or how multi-applicant income is combined. The enum-heavy, under-documented surface is left entirely to 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?

States a specific verb and resource: checking a borrower's situation against each Australian lender's published rules. It is clear what the tool computes, but it doesn't explicitly position itself against siblings like calculate_stamp_duty or check_5_percent_deposit_scheme even though it partially overlaps 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?

No indication of when to use this composite assessment versus the narrower sibling tools (calculate_stamp_duty, check_5_percent_deposit_scheme, list_lender_rates). The agent must infer that this is the 'full picture' option and the others are point calculators.

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/closed-world, so the safety profile is covered. The description adds genuine context by pinning the rates to the 2026–27 financial year, but says nothing about assumptions, limitations, or that results are jurisdiction-specific estimates.

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-loaded with the exact capability and year, no filler or restated title.

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 read-only calculator with an already-declared safe profile, the core capability and rate vintage are clear. With no output schema, though, the shape of the result (duty amount only, or a breakdown with grant/surcharge components) is left unstated.

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 25% across 8 params, but the description partially compensates by naming the concepts that map to key booleans (first home buyer concessions → first_home, foreign purchaser surcharge → foreign_buyer, owner-occupier rates → owner_occupier). Undocumented flags such as vacant_land and house_and_land_package get no explanation anywhere.

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: exact transfer/stamp duty calculation for Australian states, with the concession types named (first home buyer, owner-occupier, FHOG, foreign surcharge). It is clearly distinguishable from the lending-focused siblings, though it does not name them explicitly.

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 — the description tells you what it computes but not when to choose it over check_5_percent_deposit_scheme or assess_home_loan_readiness. No prerequisites (e.g. must be a purchase, must supply price/state) or exclusions are 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 openWorldHint=false, so safety is covered. The description adds that the check spans two distinct schemes with different deposit thresholds (5% vs 2%) and a location-dependent price cap, but says nothing about what the response contains or how ineligibility is reported.

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 front-loaded sentence naming the schemes first, then the qualifying distinctions, with no wasted clauses. It is dense but every phrase carries 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?

Annotations cover safety and idempotency, and no output schema exists. The gap is parameter meaning rather than missing behavioural framing, so for this complexity level the description is close to sufficient but still leaves key eligibility inputs undefined.

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 7 parameters, so the description must carry the semantic load. It hints at first_home, single_parent, price and state (via 'property price cap for the area'), but leaves location (capital vs regional, which directly drives the cap), will_live_in_it and all_buyers_citizens_or_pr entirely unexplained, which are the least self-evident inputs.

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 (Check eligibility) and a specific resource (Australian Government 5% Deposit Scheme / First Home Guarantee and Family Home Guarantee), including the price-cap dimension. No sibling tool in the list overlaps with eligibility checking, so an agent can route here without opening 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 description implies the scenario (a buyer considering a first-home or single-parent guarantee) but never states when to prefer this over assess_home_loan_readiness or calculate_stamp_duty, nor any exclusions or prerequisites. Usage is inferable from context only.

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, closed-world behavior, and the description adds genuinely new context: the data source is lenders' Open Banking product data, the snapshot date is 2026-10-27, lender names are masked, and a warning must accompany results. These are facts the agent could not derive from the annotations, though it does not state result ordering, pagination, or what happens when no products match.

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 filler. The operational scope (product type, rate basis, LVR, recency, masking) comes first and the mandatory presentation rule second, which is the right priority order for an agent.

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 data provenance, freshness, anonymization, and the required warning, which is substantial for a tool with no output schema. However, it leaves the purpose (owner vs investment) and limit parameters entirely unexplained and gives no sense of result shape beyond 'each rate with its comparison rate', so an agent must guess at two of three inputs.

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 33%: lvr is documented in the schema, while limit and purpose are not. The description restates the LVR scoping (no added syntax or semantics) and never clarifies the owner/investment purpose enum or what limit controls. With two of three parameters undocumented, the description fails to compensate 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?

States a concrete verb/resource pair — live variable principal-and-interest home loan rates with comparison rates, scoped to a given LVR — drawn from lenders' Open Banking product data. The scope qualifiers (variable, P&I only, LVR-based) make the tool's purpose unambiguous, though it never names or distinguishes itself from the sibling tools, which happen to cover clearly different domains (stamp duty, deposit scheme, broker referral).

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: the agent must infer that this tool is for rate-listing at a specific LVR. There is no explicit when-to-use/when-not statement and no routing to alternatives such as assess_home_loan_readiness or refer_to_broker. The one directive present ('Always show the comparison rate beside each rate, with the warning returned') is an output obligation rather than a selection guideline.

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 declare openWorldHint=true and readOnlyHint=false, but the description adds material context the annotations cannot: the name of the external third party receiving the data, the double opt-in flow ('the user then gets an email link to confirm before the broker sees anything'), and the commission/fee arrangement. It does not address what a duplicate call does, which matters given idempotentHint=false, so not 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?

The action and the consent gate are front-loaded, and the quoted disclosure is long but functional since it must be shown verbatim. The closing 'Never call it on the user's behalf without that agreement' restates the earlier precondition and is mild redundancy, but it is defensible for a compliance-critical call.

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 workflow, consent, privacy and third-party disclosure are all covered, which is the highest-risk part of this tool. For a 28-parameter submission with no output schema, however, the description says nothing about the return (confirmation, reference, link re-send) or about which of the many optional financial fields are genuinely needed, leaving an agent under-informed before filling a large payload.

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 50% across 28 parameters, so the description has to carry weight, and it does partially: 'Collect their name, email and phone' maps to three of the eight required fields and the consent gate is emphasized. The other required fields (applicants, state, price, first_home) and the roughly twenty optional financial inputs get no semantic treatment beyond what the schema already says.

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 first sentence states a specific verb and destination: send the user's situation and readiness report to Goodlend Mortgage Brokers, who then contact them. That is unambiguous and no sibling tool (assess/calculate/check/list) does anything comparable. It stops short of naming a sibling or stating the boundary explicitly, which is what keeps it from a 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?

Usage is tightly constrained: 'ONLY call this after you have shown the user this disclosure and they have explicitly agreed in this conversation', reinforced at the end with 'Never call it on the user's behalf without that agreement.' That is a clear precondition and a clear prohibition. What is missing is the alternative path (what to do instead when the user declines), so the agent has no named fallback.

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