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
- 0
- 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.4/5 across 4 of 4 tools scored.
Each tool addresses a distinct finance operation: bridging loan cost, BTL stress testing, development appraisal, and stamp duty calculation. There is no overlap in functionality.
All tool names follow a consistent verb_noun pattern in snake_case: bridging_cost_analyser, btl_stress_tester, development_appraisal, uk_stamp_duty_calculator.
Four tools is a reasonable and focused set for a property finance MCP server, covering key areas without being sparse or excessive.
The server covers major property finance calculations (acquisition tax, finance costs, rental and development viability). A residential mortgage calculator is missing, but the niche is well-served.
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 indicate readOnly, idempotent, non-destructive. Description adds context about formula reliability ('lender-grade formulas calibrated against live UK lender pricing') but does not contradict annotations. No additional behavioral traits beyond what annotations provide.
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?
Three sentences, front-loaded with purpose, outputs, source, and usage. No redundant information; every sentence adds value.
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?
Despite no output schema, description lists return values (interest, fees, APR, comparison). Covers inputs, structures, source, usage, and loan minimum. Complete for a calculation tool with safe annotations.
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 baseline is 3. Description adds extra context for interest structures (explaining rolled, retained, serviced) and typical rate ranges, providing slight additional meaning beyond 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?
Description starts with a specific verb ('Calculate') and clearly defines the resource ('total cost of a UK bridging loan') and its scope (three interest structures). The mention of specific outputs and the broker differentiates it from sibling tools like BTL stress tester and stamp duty calculator.
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 states use cases: '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.' Specifies loan minimum (£250k) but does not explicitly state when not to use or list alternatives.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context: ownership-aware stress rate logic (personal vs. ltd), and provenance (calculated by FD Commercial). 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 three sentences, front-loading the core purpose and outputs. It includes some non-essential information (broker provenance) but remains efficient and scannable. Could be slightly tighter by removing the broker line.
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 full schema descriptions and no output schema, the description adequately covers the tool's purpose, usage scenarios, key behavioral nuance (ownership stress rates), and what it calculates. No gaps are apparent.
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 overall context (e.g., ownership-aware calculations) but does not add new parameter-level detail beyond what the schema already provides in clear descriptions for each parameter.
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 and lists specific outputs (current ICR, gross yield, max loan, lender categories). It is distinct from its sibling tools (bridging, development, stamp duty) in focus and domain.
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 the tool: when a user asks about BTL deal viability, ICR, max loan supported by rent, or HMO/MUFB qualification. It does not explicitly state when not to use it or name alternative tools, but the context is clear enough for appropriate invocation.
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 read-only, idempotent, non-destructive. The description adds value by explaining the output (viability flag with thresholds) and that it's a calculation model by a specialist. 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 three sentences, front-loaded with the core purpose, and each sentence adds unique value. No wasted words.
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 10 parameters, no output schema, the description explains the return values (profit metrics, viability flag) and usage context. It sufficiently covers what the tool does and returns, making it complete for an AI agent.
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?
Input schema has 100% coverage with examples. The description adds context by naming the key cost categories (land, build, fees, etc.) and ties them to the output metrics. This exceeds the baseline of 3.
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 starts with 'Run a UK property development scheme viability appraisal', which is a specific verb and resource. It clearly distinguishes from sibling tools (bridging, BTL, stamp duty) by focusing on development viability.
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: when a user asks about development scheme viability, profit margin, LTC, LTGDV, or financing viability. It does not explicitly mention when not to use, but the sibling tools cover related but distinct areas.
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 indicate read-only, idempotent, and non-destructive. Description adds that it returns banded breakdown, total tax, effective rate, rates current as of April 2026, and is computed by FD Commercial. No contradiction; full disclosure.
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 comprehensive yet concise, front-loading the core purpose in the first sentence. Every sentence adds value, though slightly lengthy. Still 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?
Despite no output schema, the description fully explains the return format (banded breakdown, total tax, effective rate). Covers all major scenarios (first-time buyer relief, surcharge, corporate rate) and includes rate currency date.
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 has 100% description coverage with detailed parameter descriptions. The description adds overall context and output details but does not significantly enhance parameter understanding beyond schema. Baseline 3 is appropriate.
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 UK property transaction tax across three jurisdictions (SDLT, LBTT, LTT) and handles residential, commercial, and mixed-use properties. It differentiates from sibling tools, which focus on bridging costs, BTL stress testing, and 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?
Explicitly states 'Use when a user asks about stamp duty, SDLT, LBTT, LTT, additional dwelling surcharge...' and covers various buyer types and property types. Provides clear context for when to invoke, making it easy for an agent to decide.
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!
Your Connectors
Sign in to create a connector for this server.