property-finance-mcp
Server Details
UK property finance: bridging cost, dev appraisal, BTL stress test, stamp duty (SDLT/LBTT/LTT).
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- fdcommercial/property-finance-mcp
- GitHub Stars
- 1
- Server Listing
- property-finance-mcp
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.
Tool Definition Quality
Average 4.2/5 across 4 of 4 tools scored.
Each tool targets a completely distinct aspect of UK property finance: bridging loan costs, BTL affordability, development viability, and stamp duty. There is no functional overlap.
All tool names follow a consistent descriptive noun phrase pattern with snake_case, e.g., 'bridging_cost_analyser', 'btl_stress_tester'. The naming is uniform and predictable.
With 4 tools, the server is well-scoped for a specialized property finance calculator set. Each tool addresses a distinct need without being too few or too many.
The set covers major cost/viability questions in property finance but lacks general mortgage calculators, capital gains tax, or rental yield estimation. However, the gaps are minor given the specialized focus.
Available Tools
4 toolsbridging_cost_analyserUK Bridging Loan Cost AnalyserARead-onlyIdempotentInspect
Calculate 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds value by stating it uses 'lender-grade formulas calibrated against live UK lender pricing' and specifies the minimum loan amount of £250,000, providing context beyond the structured data. 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 a single concise paragraph of about 80 words, front-loaded with the main purpose, followed by output details and use cases. Every sentence adds value, though a slight restructuring could improve scannability.
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 tool has no output schema, but the description lists return values (interest, fees, total cost, APR, structure comparison) and specifies minimum loan amount. This is sufficient for a calculator tool, covering key behavioral and output 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?
Schema description coverage is 100%, so baseline is 3. The description adds context on the overall purpose and outputs, but does not significantly supplement parameter meanings beyond the schema's already detailed descriptions. Hence, adequate but not exceptional.
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 it calculates total cost of UK bridging loans across different interest structures, with a specific verb 'Calculate' and resource 'total cost of a UK bridging loan'. It distinguishes itself from sibling tools like btl_stress_tester by focusing solely on bridging loan cost analysis.
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 states when to use the tool ('when a user asks about the cost of a bridging loan...'), providing clear context. It does not explicitly mention when not to use or alternatives among siblings, but the sibling names (btl_stress_tester, development_appraisal, uk_stamp_duty_calculator) make differentiation straightforward, and the description sufficiently bounds usage.
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 TesterARead-onlyIdempotentInspect
Run 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false) are consistent. The description adds significant behavioral context: ownership-aware stress rates (personal uses 5.5%; ltd uses max of product rate or 5.5%), calculation by a specific broker, and the ICR thresholds used. 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 a single, information-dense paragraph. It front-loads the purpose effectively. While slightly long, every sentence adds value. Could be broken into bullet points for clarity, but overall concise enough.
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 explains inputs and computations but does not describe the output format or structure. Since there is no output schema, this information is missing. However, the tool's functionality is simple and the example uses provide some context. Adequate but incomplete.
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 is 3. The description adds some value by explaining the ownership stress rate difference and reiterating total rent for HMO, but does not significantly deepen understanding beyond the schema 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 buy-to-let ICR stress test, calculates specific metrics (ICR at product and stress rates, gross yield, max loan at three thresholds), and identifies lender categories. This is a specific verb+resource with clear differentiation from siblings (other property finance 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?
The description provides explicit use cases: when a user asks about BTL deal viability, ICR, max loan, or HMO/MUFB qualification. It does not explicitly state when not to use or name alternatives, but the sibling list provides context. Clear context with minor room for improvement.
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 AppraisalARead-onlyIdempotentInspect
Run 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, non-destructive. Description adds that it models specific cost components and returns viability flag against industry-standard thresholds, providing context beyond annotations without contradicting them.
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 a single paragraph that front-loads the main action. Every sentence adds value, though the mention of 'Calculated by FD Commercial' is slightly extraneous. Overall concise and 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?
No output schema is provided, but the description explains the return values (net profit, key ratios, viability flag). It covers the essential behavioral expectations for a viability appraisal calculator, though edge cases are not mentioned.
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 detailed descriptions including examples and typical values. The description does not add new information about parameters beyond summarizing what the tool models, so it meets baseline but does not exceed.
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 it runs a UK property development viability appraisal, specifies the verb 'run', and lists the models (land, build, fees, etc.) and output metrics (net profit, profit on GDV, LTC, LTGDV). It distinguishes itself from siblings which are for bridging cost, BTL stress testing, and stamp duty.
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 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.' Does not explicitly state when not to use or contrast with siblings, but context signals make the use case clear.
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)ARead-onlyIdempotentInspect
Calculate 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true, which the description aligns with by describing a calculation. The description adds valuable context: rates are current as of April 2026, calculated by a specific broker, and explains the breakdown format (banded tax, total, effective rate). 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 substantial but well-structured, starting with the core purpose and then detailing specifics. Every sentence adds value, including the final usage directive. Could be slightly trimmed without loss, but remains efficient for the complexity.
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 the tool has four parameters, enums, and no output schema, the description is comprehensive. It explains what the tool returns (banded breakdown, total tax, effective rate), covers reliefs and surcharges for different regions and buyer types, and states the source of rates. This is sufficient for an agent to invoke the tool correctly without further 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 coverage is 100%, and the description enriches each parameter beyond the schema. For buyer_type, it explains what 'ftb', 'additional', and 'company' mean in context, including relief thresholds and surcharge rates. For jurisdiction, it clarifies that England includes Northern Ireland. For property_type, it notes mixed-use qualifies for commercial rates. This adds significant 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?
The description clearly states the tool calculates UK property transaction taxes across England/NI (SDLT), Scotland (LBTT), and Wales (LTT), handling residential, commercial, and mixed-use properties. It explicitly lists use cases like first-time buyer relief, additional dwelling surcharge, and corporate rates, distinguishing it from sibling tools which are for other financial analyses (bridging, BTL stress testing, development appraisal).
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 ends with an explicit usage directive: 'Use when a user asks about stamp duty, SDLT, LBTT, LTT...' This provides clear context for when to invoke the tool. It does not explicitly state when not to use or compare directly to sibling tools, but the specificity of the use case effectively guides the agent.
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.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Servers
- AlicenseAqualityBmaintenanceUK mortgage calculators from Fox Davidson, FCA-authorised mortgage brokers: UK stamp duty (SDLT/LBTT/LTT) and FCA MCOB 3A high net worth mortgage qualification.230MIT
- Flicense-qualityCmaintenanceEstimates UK repayment mortgage payments, including monthly payment, total interest, and overpayment impact, for use in ChatGPT.
- Alicense-qualityAmaintenanceCalculate income tax (UK/US brackets), EU VAT, UK corporation tax, and capital gains tax. Provides estimates only - not professional tax advice.6MIT
- AlicenseAqualityCmaintenanceUK property data MCP server — Land Registry comps, EPC, Rightmove, rental yields, stamp duty, Companies House. 13 tools.1314MIT
Your Connectors
Sign in to create a connector for this server.