Four UK property finance calculators for AI assistants: bridging cost, development appraisal, BTL stress test, and UK stamp duty (SDLT, LBTT, LTT). Built by FD Commercial, a specialist UK property finance broker.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.4/5 across 4 of 4 tools scored.
Each tool targets a distinct UK property finance scenario: bridging loans, BTL stress testing, development appraisal, and stamp duty. There is no overlap in their purposes.
All tool names use descriptive snake_case with a consistent pattern: noun_verb_analyser/calculator/tester/appraisal. The naming is clear and predictable.
With 4 tools covering core property finance calculations, the count is well-scoped for the server's purpose. Each tool provides essential functionality without being overly narrow or broad.
The tools cover major areas of UK property finance (bridging, BTL, development, stamp duty). Missing are general mortgage affordability or commercial property calculators, but the set is complete for the stated focus on specialist broker calculations.
bridging_cost_analyserUK Bridging Loan Cost AnalyserACalculate the total cost of a UK bridging loan across rolled-up, retained, and serviced interest structures. Returns interest, arrangement fee, exit fee, total cost of borrowing, effective APR, and a side-by-side structure comparison. Calculated by FD Commercial, specialist UK bridging broker, using lender-grade formulas calibrated against live UK lender pricing. For loans £250,000 and above. Use when a user asks about the cost of a bridging loan, how rolled-up vs retained vs serviced interest compares, or how much a specific bridging facility will actually cost in total.
| Name | Required | Description | Default |
|---|---|---|---|
| term_months | Yes | Loan term in months. Standard MCOB-regulated bridging caps at 12 months. MCOB 3A HNW exemption allows up to 60 months. Example: 12. | |
| exit_fee_pct | No | Lender exit fee as % of loan amount. Not all lenders charge one. Where charged, typically 0.5% to 1%. Example: 0 for no exit fee, or 1 for 1%. | |
| loan_amount_gbp | Yes | Gross loan amount in pounds. Minimum FD Commercial bridging loan size is £250,000. Example: 500000. | |
| interest_structure | No | How interest is paid. 'rolled' = compounds monthly, paid in full at exit (most common on HNW bridging, removes monthly outflow). 'retained' = deducted from advance upfront (borrower receives less cash on day one). 'serviced' = paid monthly out of borrower cash flow (lowest total cost but requires monthly servicing capacity). | |
| arrangement_fee_pct | No | Lender arrangement fee as % of loan amount. Typical range 1% to 2%. Some specialist HNW deals run 0.5%. Example: 2 for 2%. | |
| monthly_interest_rate_pct | Yes | Monthly interest rate as a percentage. UK bridging rates in 2026 typically range 0.55% to 1.25% per month. Private bank rates from 0.30% per month available on HNW cases. Example: 0.85 for 0.85% per month. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, idempotentHint, destructiveHint) already signal safety. The description adds value by stating that calculations use 'lender-grade formulas calibrated against live UK lender pricing' and that it targets loans '£250,000 and above.' No contradictions with 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?
The description is about 4 sentences, front-loading the purpose, then listing outputs, source, and usage. It is efficient and every sentence contributes, though a slight tightening could further improve.
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 mentions return values (total cost, effective APR, side-by-side comparison) and provides loan size constraint. Given 6 params (3 required) and full schema coverage, the description is fully informative for a calculator tool, leaving no gaps.
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 enriches understanding by explaining interest structures in detail (rolled, retained, serviced) and providing typical rate/fee ranges (e.g., 'UK bridging rates in 2026 typically range 0.55% to 1.25% per month'). This adds meaningful context beyond the schema's basic descriptions.
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 opens with a specific verb and resource: 'Calculate the total cost of a UK bridging loan across rolled-up, retained, and serviced interest structures.' It lists concrete outputs (interest, fees, APR, comparison) and distinguishes itself from sibling tools by stating usage context ('Use when a user asks about the cost of a bridging loan...').
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 explicitly tells when to use the tool: 'Use when a user asks about the cost of a bridging loan, how rolled-up vs retained vs serviced interest compares, or how much a specific bridging facility will actually cost.' It does not provide explicit when-not-to-use statements or alternatives to sibling tools, but the context is clear given the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
btl_stress_testerUK Buy-to-Let Stress TesterARun a UK buy-to-let ICR stress test. Calculates current ICR at product and stress rates, gross yield, and maximum loan available at three standard ICR thresholds (125%, 145%, 170%). Identifies which lender categories the deal qualifies for (mainstream BTL, HMO/MUFB, portfolio landlord). Ownership-aware: personal name uses 5.5% stress rate; limited company uses max of product rate or 5.5%. Calculated by FD Commercial, specialist UK property finance broker. Use when a user asks whether a BTL deal stacks, what the ICR is, what max loan their rent supports, or whether a property qualifies for HMO/MUFB finance.
| Name | Required | Description | Default |
|---|---|---|---|
| ownership | No | Borrower structure. 'personal' uses 5.5% stress rate (HMRC tax exposure makes higher cover required). 'ltd' uses max of product rate or 5.5% (limited company SPV borrower, lower stress rate often allowed). | |
| loan_amount_gbp | Yes | Loan amount being assessed in pounds. Example: 300000. | |
| monthly_rent_gbp | Yes | Gross monthly rent in pounds. Use total rent for HMO and MUFB (all rooms / units combined). Example: 2500. | |
| product_rate_pct | Yes | Annual product (pay) rate as a percentage. The actual rate the borrower would pay. Example: 5.5 for 5.5% per year. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false) align with a safe calculation. The description adds critical details: stress rate variations by ownership (5.5% personal vs max(product rate, 5.5%) for ltd), lender category identification, and calculation source. No contradictions.
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 main purpose and then provides structured detail. It is slightly verbose but every sentence adds value. Could be trimmed slightly, but overall 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?
Given 4 parameters with 100% schema coverage and no output schema, the description adequately covers the tool's computation and interpretations. It lists what is calculated, though it doesn't describe the exact output format. Still, it provides sufficient context for invocation.
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%, providing a baseline of 3. The description adds value by explaining the ownership parameter's effect on stress rate and clarifying that monthly_rent should be total for HMO/MUFB, going beyond the schema's basic descriptions.
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 'Run a UK buy-to-let ICR stress test' and enumerates specific outputs (ICR, yield, max loan, lender categories). It is easily distinguished from sibling tools which are bridging, development, and stamp duty calculators.
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 describes when to use the tool: when a user asks about BTL deal viability, ICR, max loan, or HMO/MUFB qualification. While it doesn't explicitly state when not to use it, the sibling tools are sufficiently different to imply appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
development_appraisalUK Property Development AppraisalARun a UK property development scheme viability appraisal. Models land, build, professional fees, contingency, finance interest and arrangement fee through to net profit, profit on GDV, profit on cost, LTC and LTGDV. Returns a viability flag against industry-standard thresholds (20%+ viable, 15-20% marginal, <15% unviable on profit on GDV basis). Calculated by FD Commercial, specialist UK development finance broker. Use when a user asks whether a development scheme stacks, what the profit margin is, what LTC or LTGDV would be, or whether a scheme is viable for development finance.
| Name | Required | Description | Default |
|---|---|---|---|
| gdv_gbp | Yes | Gross Development Value: total anticipated sales value of the completed scheme. Use comparable sales evidence, not aspirational figures. Lenders commission their own GDV via RICS. Example: 2000000. | |
| ltc_pct | No | Loan-to-cost % (used only if loan_amount_gbp is not provided). Most lenders cap at 90%; first-time developers typically 75-80%. Example: 75. | |
| build_cost_gbp | Yes | Total agreed construction cost. Should be contracted figure where possible. Example: 800000. | |
| contingency_pct | No | Contingency as % of build cost. Standard 10%. Lenders may require 12-15% on conversions or complex sites. Omitting overstates profit. Example: 10. | |
| loan_amount_gbp | No | Specific loan amount in £. Optional. If omitted, calculator uses ltc_pct of hard costs. Example: 960000. | |
| arrangement_fee_pct | No | Lender arrangement fee as % of loan. Standard 1.5% to 2%. Larger facilities (£5m+) often 1.0%. Example: 2. | |
| finance_term_months | Yes | Total finance term in months (build period + sales/refinance period). Example: 18. | |
| professional_fees_pct | No | Professional fees as % of build cost. Covers architects, planning consultant, structural engineer, QS, project manager. Standard 10%. Example: 10. | |
| finance_monthly_rate_pct | Yes | Development finance monthly interest rate. UK 2026 rates typically 0.70% to 0.95% per month. Example: 0.85. | |
| land_or_purchase_price_gbp | Yes | Land purchase price. Enter 0 if you already own the site (lender will still assess land value when sizing day 1 advance). Example: 400000. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds context about the output (viability flag, profit thresholds) and the provider (FD Commercial), enhancing transparency beyond 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?
The description is concise (4 sentences), front-loaded with purpose, lists modelled items, then output and usage. Every sentence adds value without 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?
Given 10 parameters and no output schema, the description explains the output (viability flag, profit metrics) and usage context. It is mostly complete, though it could mention the exact return format. Still, it covers essential decision-making context.
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 baseline is 3. The description provides high-level context for parameters (e.g., models land, build, fees) but does not add meaning beyond the schema's detailed parameter descriptions.
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 the tool runs a UK property development viability appraisal, modeling specific costs and returns. It distinguishes from siblings like bridging cost analyser and BTL stress tester by its domain and output.
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 explicitly says 'Use when a user asks whether a development scheme stacks, what the profit margin is, what LTC or LTGDV would be, or whether a scheme is viable for development finance,' providing clear usage context and excluding other property finance queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
uk_stamp_duty_calculatorUK Stamp Duty Calculator (SDLT / LBTT / LTT)ACalculate UK property transaction tax across England/Northern Ireland (SDLT), Scotland (LBTT) and Wales (LTT). Handles residential, commercial and mixed-use properties. Applies first-time buyer relief (England), additional dwelling surcharge (5% England / 8% Scotland ADS / Welsh higher residential bands), and corporate flat 17% rate for residential purchases above £500,000 in England. Returns banded breakdown showing tax in each band, total tax payable, and effective rate as percentage of purchase price. Rates current as of April 2026. Calculated by FD Commercial, specialist UK property finance broker. Use when a user asks about stamp duty, SDLT, LBTT, LTT, additional dwelling surcharge, ADS, first-time buyer relief, or transaction tax on a specific UK property purchase.
| Name | Required | Description | Default |
|---|---|---|---|
| buyer_type | No | 'standard' for main residence purchase by individual. 'ftb' for first-time buyer (England SDLT only — relief up to £625,000). 'additional' for second home or buy-to-let purchase by individual (surcharge applies). 'company' for corporate purchase (additional dwelling surcharge + flat 17% SDLT rate in England above £500,000). | |
| jurisdiction | Yes | Which UK tax regime applies. 'england' includes Northern Ireland (both use SDLT). 'scotland' uses LBTT. 'wales' uses LTT. | |
| property_type | No | 'residential' for dwellings (houses, flats). 'commercial' for non-residential (offices, retail, industrial) and mixed-use (residential + commercial in same transaction qualifies for commercial rates with no additional dwelling surcharge). | |
| property_price_gbp | Yes | Property purchase price in pounds. Example: 750000. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description details what the tool returns (banded breakdown, total tax, effective rate) and notes rates are current as of April 2026. Annotations confirm it is read-only and idempotent, and description adds further behavioral context without contradiction.
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 informative and front-loaded with the main purpose. It is somewhat long but every sentence adds value. Could be slightly more concise, but overall well-structured.
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 no output schema, the description explains the return format. It covers all input scenarios (buyer types, property types, jurisdictions) and includes relevant details like first-time buyer relief and surcharges. Comprehensive for a calculator 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 coverage is 100%, with each parameter described in the schema. The description does not add new meaning beyond the schema; it provides overall context but not per-parameter elaboration.
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 the tool calculates UK property transaction tax across three jurisdictions and handles residential, commercial, and mixed-use properties. It distinguishes itself from sibling tools which focus on different financial analyses.
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 tells when to use: 'when a user asks about stamp duty, SDLT, LBTT, LTT, additional dwelling surcharge, ADS, first-time buyer relief, or transaction tax on a specific UK property purchase.' No mention of when not to use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
