property-finance-mcp-hosted
Server Details
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.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.5/5 across 4 of 4 tools scored.
Each tool addresses a distinct financial calculation (bridging loan cost, BTL stress test, development appraisal, stamp duty) with no overlapping purposes. Agents can clearly differentiate based on the provided descriptions.
Tools use snake_case, but naming patterns vary: 'bridging_cost_analyser' uses 'analyser', 'btl_stress_tester' and 'development_appraisal' use nouns, and 'uk_stamp_duty_calculator' uses 'calculator'. While readable, the verb/noun usage is not fully uniform.
Four tools is well-scoped for a specialized property finance calculator server. Each tool provides a distinct, valuable calculation without unnecessary bloat or missing essential functionality.
The set covers major property finance calculations (bridging, BTL, development, stamp duty), but is missing some common ones like mortgage affordability or remortgage analysis. However, the domain is clearly defined and the tools cover core needs for a broker-focused utility.
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=true, idempotentHint=true, destructiveHint=false. The description adds value by stating it uses 'lender-grade formulas calibrated against live UK lender pricing' and is provided by 'FD Commercial, specialist UK bridging broker', providing credibility and context beyond annotations. 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: first states the core purpose, second lists outputs, third provides usage guidance and source. It is well-structured and front-loaded, though slightly verbose with the broker mention. 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?
Given the complexity (6 parameters, no output schema), the description lists all key outputs (total cost, APR, comparison) and explains the three interest structures. It does not detail return format but is sufficient for a cost calculator. Some missing details like data source accuracy assurance, but adequate.
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 description adds typical ranges (e.g., monthly rate 0.55%-1.25%) and examples for each parameter. It also explains the interest_structure enum values in detail, adding meaning beyond the enum labels.
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 explicitly states the tool calculates total cost of UK bridging loans across three interest structures (rolled-up, retained, serviced) and lists specific outputs like interest, fees, APR, and comparison. It clearly distinguishes from sibling tools (btl_stress_tester, development_appraisal, uk_stamp_duty_calculator) by focusing on bridging costs.
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 about the cost of a bridging loan...' and specifies the loan minimum (£250,000). It does not explicitly state when not to use or mention alternatives to this tool, but the context is clear from sibling names.
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 read-only and idempotent. Description adds ownership-aware stress rate logic (5.5% for personal, max of rate or 5.5% for ltd) and outputs like ICR thresholds. 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?
Single paragraph of ~100 words. Front-loaded with action and outputs. Every sentence adds value. No 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?
Despite no output schema, description fully explains return values (ICR at two rates, yield, max loan at three thresholds, lender categories). Covers ownership logic. Complete for a calculation 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 description coverage is 100%. Description adds context beyond schema (e.g., explains why personal uses 5.5% stress rate due to HMRC tax exposure). Provides meaningful interpretation of parameters.
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 (ICR, yield, max loan, lender categories). It distinguishes itself from siblings (bridging, development, stamp duty) by being BTL-specific.
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 BTL deal stacks, what the ICR is, what max loan their rent supports, or whether a property qualifies for HMO/MUFB finance.' Could mention disuse cases but is clear for its domain.
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, non-destructive, idempotent. The description adds context by specifying the calculation source (FD Commercial) and viability thresholds, which helps the agent understand behavior 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?
Two concise paragraphs: first defines tool and outputs, second gives use cases. Every sentence adds value with no fluff, front-loaded with purpose.
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 lists all major outputs (net profit, profit on GDV, etc.) but lacks a formal output schema. However, it compensates by describing the return values in the first paragraph, making it fairly complete 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 description coverage is 100%, and the description adds meaning beyond schema (e.g., 'Use comparable sales evidence' for GDV, 'Standard 10%' for contingency), providing practical guidance for parameter values.
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, listing specific outputs (net profit, profit on GDV, etc.) and distinguishing it from sibling tools like bridging_cost_analyser.
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 (e.g., 'when a user asks whether a development scheme stacks, what the profit margin is...'), but lacks explicit exclusions or alternatives, though sibling tools are clearly different.
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 declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, which the description does not contradict. The description adds valuable behavioral context beyond annotations: it notes rates are current as of April 2026, states the calculator is by FD Commercial, and describes the output as a banded breakdown with total tax and effective rate. This fully informs the agent of the tool's behavior and limitations.
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 thorough but slightly verbose (multiple sentences covering specifics). However, every sentence contributes necessary information for a complex tool with multiple jurisdictions and reliefs. It is front-loaded with the core purpose. A minor trim could improve conciseness without losing clarity, hence a 4.
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's complexity (multiple tax regimes, buyer types, property types, reliefs) and absence of an output schema, the description fully covers what the tool returns: banded breakdown, total tax, and effective rate. It also provides context like rate currency (April 2026) and source (FD Commercial). No gaps remain for an agent to understand the tool's capabilities.
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 input schema has 100% description coverage with clear parameter descriptions (e.g., buyer_type explains each option, jurisdiction maps to tax regimes, property_type covers mixed-use). The description further enriches meaning by detailing how each parameter affects calculations, such as first-time buyer relief limits (£625k), surcharge percentages (5% England, 8% Scotland), and corporate flat rate (17% above £500k). This adds significant value beyond the schema.
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 (England/NI, Scotland, Wales) for residential, commercial, and mixed-use properties. It specifies the tax types (SDLT, LBTT, LTT) and handles special cases like first-time buyer relief, additional dwelling surcharge, and corporate rates. This distinguishes it from siblings like bridging_cost_analyser or btl_stress_tester, which address different financial calculations.
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 about stamp duty, SDLT, LBTT, LTT, additional dwelling surcharge, ADS, first-time buyer relief, or transaction tax on a specific UK property purchase.' This provides clear, actionable guidance on when to invoke the tool, leaving no ambiguity about its purpose relative to other tools.
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!