Open Financial Mortgages

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, destructiveHint=false, so the description earns credit for adding substantive context: it works from approximate user-supplied values, captures no contact details or documents, and results include the assumptions and caveats behind them. One inconsistency undercuts this: it states it works on an 'Ontario residential property' while the schema accepts a full Canadian province enum.

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 scope and outputs are front-loaded, and the caveat sentence is short and purposeful. There is mild redundancy across 'Preliminary analysis,' 'A preliminary scenario only,' and 'not an eligibility decision... or an approval,' which restate the same disclaimer twice.

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 summarizes the return content (equity, LTVs, missing information, categories, assumptions), which is appropriate. But for a 12-parameter, fully-optional-input tool it supplies no guidance on which inputs matter or what happens when they are omitted, leaving a real gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across 12 parameters, 7 of them enums, so the description carries the full burden of explaining inputs and largely does not. It only says values are 'approximate' and that there are zero required fields, but never explains what timing, purpose, renewalMonth, credit range, or the mortgage balance array are used for or how they affect the result.

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 (preliminary analysis) and resource (mortgage/refinance/home-equity/debt-consolidation scenario) and enumerates what the output contains: equity, current and proposed CLTV, missing information, and unranked financing categories. That detail distinguishes it reasonably well from siblings like estimate_home_equity and get_financing_options, though it never names 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?

It gives an implied usage context — 'Useful as a first look at someone's situation' — and sets a clear boundary that this is not an eligibility decision, lender offer, or approval. However, it never says when to prefer a sibling such as estimate_home_equity or get_financing_options, so the agent must still infer routing from tool names alone.

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, openWorldHint=false, and destructiveHint=false. The description adds useful behavioral context beyond those annotations: Clara calculates in process, takes no contact details or documents, results include assumptions and caveats, and the output is explicitly a preliminary scenario rather than a decision or offer.

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 appropriately short and avoids filler, covering purpose, calculation context, privacy, and caveats in four sentences. The opening phrase 'The same preliminary analysis' is a vague back-reference, but overall the information is front-loaded and efficient.

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, read-only tool with no output schema and zero schema descriptions, the description covers privacy and caveats but leaves the entire input contract to the bare schema. It does not help an agent understand which optional fields matter or how province, property type, income, credit, mortgage balances, and requested amount are used.

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 12 parameters, and the description does not mention any parameter names, enum values, optionality, or formats. It vaguely signals approximate values and an Ontario residential property, but the schema's province enum includes all Canadian provinces, creating ambiguity, and the remaining inputs are undocumented in both schema and description.

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 that the tool estimates home equity and combined loan-to-value from approximate user-provided property values. It does not name or distinguish itself from the sibling tools, and the phrase 'The same preliminary analysis' has no clear antecedent, so it falls short of 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?

It provides an implied use case: when someone wants to know their estimated home equity and CLTV. It also warns that this is not an eligibility decision, lender offer, or approval, but it does not route the agent to alternatives such as analyze_mortgage_scenario or get_financing_options, and it gives no explicit exclusions.

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, non-destructive and closed-world behavior, and the description adds meaningful context on top: categories are unranked, results include assumptions and caveats, and Clara computes locally without collecting contact details or documents. It stops short of describing response shape, category cardinality, or any limits, so a 4 rather than 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 scope statement is reasonably front-loaded and the disclaimers are grouped at the end, but the opening 'The same preliminary analysis' is ambiguous without knowing the sibling, and the caveat 'not a lender offer' is stated twice along with repeated use of 'preliminary', which spends sentences on redundancy rather than missing parameter guidance.

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 12 optional parameters, no schema descriptions, and no output schema, the description should explain what inputs the agent must gather from the user and how they combine. Instead it only says inputs are 'approximate values' and that no documents are needed, leaving the agent unable to know which of the 12 fields matter or how to fill the enums.

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 12 parameters, and the description gives no per-parameter meaning for city, timing, purpose, property type, income range, credit range, renewal month, or requested amount. Worse, it says the tool 'works from approximate values the user gives for an Ontario residential property' while the province enum accepts all 13 provinces and territories, which is likely to mislead an agent about valid 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?

The description states a clear outcome: it returns unranked broad categories of financing a user could explore, based on approximate property inputs. It implicitly contrasts with the sibling analysis tool ('the same preliminary analysis, for when...') rather than naming it, and never concretely says what the categories are, which keeps it short of 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?

It gives a usage context ('for when someone wants to know which broad kinds of financing they could explore') and several when-nots around what the output is not (not an offer, not an eligibility decision). However, it never names analyze_mortgage_scenario or estimate_home_equity as alternatives or states the condition that selects between them, leaving routing to inference.

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. The description adds a genuinely useful behavioral fact beyond them: it collects and sends nothing, and the user enters their own details on openfinancial.ca — clarifying there is no data submission or privacy risk. It stops short of describing the shape of the returned contact details, but that is minor for a static-link 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 tight sentences with zero waste: what is returned comes first, then the no-data-collection caveat. 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?

No output schema exists, and the description covers the return value (link plus contact details) and the handoff mechanics, so an agent has everything needed to call it and set expectations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; the description correctly implies no input is required.

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 — returns the intake-form link and contact details for Open Financial. It is clearly distinguishable from the sibling analysis tools (analyze_mortgage_scenario, estimate_home_equity, etc.), which compute things rather than hand off to a human professional.

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 it when the user asks for help from a broker or licensed mortgage professional. It does not name alternative tools or state when NOT to use it, but the trigger is narrow enough that no ambiguity 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 read-only, idempotent, open-world and non-destructive behavior, and the description adds genuinely new context: the empty-filter clarification behavior, the shape of the return (lender's own rate wording, conditions, check date, source link, accompanying notice), and a non-advisory disclaimer. It adds no detail on result volume or how the max limit of 10 interacts with paging, 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 opening sentence is long and semicolon-chained, but every clause carries load-bearing information: filters, no-filter behavior, return contents and scope limits. Nothing is redundant, though the run-on construction makes it slightly harder to scan than a shorter front-loaded statement.

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 nine optional parameters, no output schema and annotations covering the safety profile, the description does the important work: it explains the empty-input path, summarizes the return payload, and prevents off-label use. The remaining gap is that fees and sort are left unexplained anywhere, so an agent must guess what ordering and fee-filter values do.

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 56%, and the description names six of the nine filters (mortgageType, term, position, minimumLtv, purpose, lender keyword) but never mentions fees, sort or limit, which have no schema descriptions at all. The facts it does add, such as keyword meaning a lender or directory term rather than a person, largely restate what the schema already says for those fields.

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 gives a specific verb and resource ('searches the Ontario mortgage rates lenders have published') plus the data source (Open Mortgage Rates) and the concrete filter dimensions available. It also bounds scope negatively ('takes filters only, not names, contact details or dollar amounts'), which cleanly separates it from sibling tools like analyze_mortgage_scenario or get_financing_options.

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 states the triggering user question ('useful when someone asks what rates lenders are publishing') and explains the no-filter fallback (it asks what to search for instead of dumping all records). It also rules out misuse as a quote or eligibility tool. It never names a sibling tool as an alternative, so it falls 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.