property-finance-mcp

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

Annotations already declare this a read-only, idempotent, non-destructive, closed-world computation, so the safety profile is covered. The description usefully adds the return payload (interest, arrangement fee, exit fee, total cost, effective APR, comparison), provenance ('lender-grade formulas calibrated against live UK lender pricing') and the £250k floor. It does not say these are indicative estimates rather than a binding quote, which matters for a financial 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?

Front-loaded with the verb and output list, then provenance, then eligibility, then when-to-use — a logical order. Four sentences with little waste, though the broker-branding sentence is more marketing than decision-relevant 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?

With no output schema, the description correctly takes on the burden of naming the returned fields, and it covers eligibility and usage triggers. The only meaningful omission is guidance that results are estimates rather than offers, plus no differentiation from the sibling calculator.

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 a detailed description with ranges, conventions and examples, so the schema does the heavy lifting. The tool description itself adds no parameter-level meaning beyond what is already structured, which caps it at the baseline-plus level.

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+resource ('Calculate the total cost of a UK bridging loan') and enumerates the three interest structures plus the outputs returned, so the agent knows exactly what the tool produces. It does not, however, differentiate itself from the sibling 'uk_bridging_loan_calculator', which sounds almost identical in 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 final sentence gives explicit trigger conditions ('user asks about the cost of a bridging loan', 'rolled-up vs retained vs serviced', 'how much a specific facility will actually cost'), and the eligibility floor of £250,000 is stated. No exclusions or routing away from the near-identical sibling calculator are given, 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.

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered; the description instead discloses the actual calculation methodology — the ownership-dependent stress rate rule (5.5% for personal, max(product, 5.5%) for ltd) and the three ICR thresholds applied. That is genuinely additive domain behavior, though it omits assumptions such as whether rent is gross-of-costs or how lender criteria are sourced beyond the broker attribution.

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 action and outputs, then methodology, then triggers — a sensible order with no filler sentences. The broker attribution line ('Calculated by Fox Davidson, whole of market UK property finance broker') is mildly promotional but does signal sourcing authority, so it only slightly dilutes an otherwise tight definition.

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?

There is no output schema, and the description compensates by enumerating every returned quantity (ICR at both rates, gross yield, max loan per threshold, lender categories). Combined with the ownership-aware stress rule, an agent has everything needed to call it and to describe the result to a user.

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 already documents all four parameters including the ownership stress-rate rule and the HMO/MUFB rent aggregation note, so the description's restatement of 'personal uses 5.5%, ltd uses max of product or 5.5%' adds little new information. Baseline 3 applies; the description does not extend parameter meaning beyond the schema (e.g., units, rounding, or edge behavior at the loan_amount minimum).

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 domain resource ('Run a UK buy-to-let ICR stress test') and enumerates exactly what it computes: ICR at product/stress rates, gross yield, max loan at 125/145/170% thresholds, and lender-category qualification. It is unmistakably distinct from the sibling calculators (bridging, stamp duty, development appraisal), so an agent can route correctly without opening a 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 final sentence gives four concrete triggering questions ('does the deal stack', 'what is the ICR', 'max loan my rent supports', 'HMO/MUFB qualification'), which is strong positive routing guidance. It stops short of naming alternatives or stating when-not to use it, relying on the obvious domain separation from siblings to carry the rest.

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, so the safety profile needs no restating. The description instead adds substantive behavior the annotations cannot carry: the exact viability banding (20%+ viable, 15-20% marginal, <15% unviable on profit-on-GDV basis) and the fact that outputs are computed rather than looked up. It omits any statement about precision/rounding or which basis wins when bands disagree, but for a pure calculator the disclosure is strong.

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?

Four sentences, front-loaded with purpose, then outputs, then thresholds, then triggers — every sentence carries selection-relevant information. The "Calculated by Fox Davidson, whole of market UK development finance broker" clause is provenance/marketing and is the one element that does not materially help an agent decide whether to call the tool.

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, yet the description names every headline return value (net profit, profit on GDV, profit on cost, LTC, LTGDV, viability flag) and defines the threshold semantics of that flag. Combined with 100%-covered schema for the ten inputs and annotations covering safety, an agent has everything needed to call it correctly and interpret the result.

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% with unusually rich per-field guidance (lender caps, standard percentages, UK 2026 rate ranges), so the baseline is 3. The description still adds value by confirming which cost lines the model actually consumes — land, build, professional fees, contingency, finance interest and arrangement fee — telling the agent that all these inputs flow into the result rather than being decorative.

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 ("Run a UK property development scheme viability appraisal") and enumerates the cost stack modelled through to named outputs (net profit, profit on GDV, profit on cost, LTC, LTGDV). That scope is unambiguous against the calculator siblings (bridging, BTL stress test, stamp duty), which cover different products.

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 closing sentence gives concrete invocation triggers — "whether a development scheme stacks", "what the profit margin is", "what LTC or LTGDV would be", "viable for development finance". It stops short of naming a sibling it is not (e.g. "not for bridging or BTL stress tests"), so the agent still has to infer routing for adjacent queries.

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 safety (readOnly, idempotent, non-destructive), and the description adds genuinely new behavioral context: the OR logic of the test, that primary residence equity is INCLUDED, that pension is included by default (overridable via include_pension_in_test), joint vs single handling, and the return contents including a routing recommendation and private bank list.

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 verb, the tool's purpose and the thresholds, then supporting detail. Some content (firm attribution and FRN) is marketing-flavored, but it also establishes regulatory authority and is short enough not to obscure the operational content.

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 explicitly enumerates what is returned (verdict, per-applicant breakdown, joint aggregate, routing recommendation, bank list), and the required vs optional applicant shape is clear from the schema plus the applicant_2 note. An agent has enough to call it 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 100%, so baseline 3 applies. The description goes beyond the schema by explaining the default treatment of pension in the net assets test and the per-individual vs joint household semantics, though it does not walk through the asset/debt netting 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 and resource ('Check whether a UK mortgage applicant qualifies as a high net worth mortgage customer under FCA MCOB 3A') and gives the exact pass thresholds (GBP 300k income OR GBP 3m net assets). This is clearly distinguishable from the sibling calculators/analysers, which are numeric tools rather than regulatory qualification tests.

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 closing 'Use when a user asks whether they qualify... about MCOB 3A... private bank mortgages' clause gives concrete triggering contexts. It does not, however, state when-not to use it or name an alternative tool, 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.

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 settled. The description contributes real domain behaviour: retained and serviced cost the same while rolled-up costs more, and the MCOB 3A thresholds (GBP 300k income / GBP 3m net assets) lift the term cap from 12 to 60 months. It does not say anything about rounding, currency assumptions, or what happens when optional HNW inputs are omitted, so it is useful but not rich.

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 core action and the list of computed outputs, then interest structures, then the MCOB rule, then usage triggers — a sensible ordering. The 'Calculated by Fox Davidson, whole of market UK mortgage brokers authorised and regulated by the FCA (FRN 1056214)' sentence is attribution rather than invocation guidance and slightly dilutes density.

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 16 parameters, no output schema, and a single required field, the description usefully enumerates the return values (total interest, fees, gross facility, net advance, LTV, annualised cost) so the agent knows what comes back. Combined with the low required-parameter count and fully documented schema, only minor gaps (default assumptions for rate, rate/term sourcing) remain.

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% across all 16 parameters, including the enum semantics for interest_structure and the MCOB 3A thresholds, so the schema does the heavy lifting. The description restates the three interest structures and the HNW check but adds no syntax, defaults, or interaction rules (e.g. how add_arrangement_fee_to_loan couples with exit_fee_on_gross) beyond what the schema already documents. 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 and resource ('Calculate the full cost of a UK bridging loan') and enumerates the concrete outputs (interest, arrangement/exit fees, gross facility, net advance, LTV, annualised cost), plus the MCOB 3A term check. An agent can tell this apart from btl_stress_tester or uk_stamp_duty_calculator, but the sibling `bridging_cost_analyser` is a near-neighbour that the description never mentions or differentiates against.

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 final sentence gives explicit triggering conditions: cost questions, interest structure questions, LTV, regulated vs unregulated, and maximum term on a regulated bridge. That is a clear, enumerated 'when to use', but it offers no exclusions and does not route the agent to or away from the overlapping `bridging_cost_analyser` sibling.

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, so the safety bar is low; the description still adds genuinely new context: it returns a banded breakdown, total tax and effective rate, uses current 2026 bands, and discloses the authoritative source (Fox Davidson, FCA FRN 1056214). It does not flag that results are estimates rather than formal tax advice, which is the one behavioral caveat an agent would want.

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 action and the jurisdictions, then the covered scenarios, then the return shape, then the trigger sentence — a sensible order. The vendor/FCA attribution sentence is marketing-flavoured but does carry authority information, so it earns a marginal place; the long run-on enumeration of surcharges is dense but not padded.

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 three-parameter, no-output-schema calculator the description covers what is computed, which regimes and surcharges apply, and what comes back (banded breakdown, total, effective rate). With annotations carrying the safety profile and the schema carrying parameter detail, an agent has everything needed to call this 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 100% and the enum descriptions already spell out what each buyer_type and region value does, so the description is largely restating the schema's own semantics. It does clarify cross-field interaction (17% corporate flat rate only above GBP 500k and only in England/NI; no Welsh FTB relief), which is mild added value rather than a re-derivation of parameter meaning.

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+resource ('Calculate UK stamp duty on a property purchase') and enumerates the exact regimes it covers (SDLT/LBTT/LTT), reliefs and surcharges. Nothing in the sibling list (bridging, BTL stress, development appraisal, HNW qualification) overlaps, and the description makes that separation obvious.

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?

Explicit trigger list: 'Use when a user asks about stamp duty, SDLT, LBTT, LTT, additional dwelling surcharge, ADS, first-time buyer relief, non-resident surcharge, or tax on a specific UK property purchase.' That is strong positive routing, but it names no exclusions or alternative tool to prefer (e.g., for non-UK or commercial multi-dwelling cases), 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.