Skip to main content
Glama

Homesage.ai MCP

Get Mortgage & Lien Analysis

get_mortgage_lien_analysis
Read-only

What it returns

Mortgage and lien records for a US property — current and historical mortgages, lien summary, involuntary liens, pre-foreclosure status, and data quality metadata. Sourced from a county-records aggregator and cached for 7 days; cached responses cost 0 credits.

Performance

Fresh lookups are slow — use a 60-second client timeout and cache responses (we cache for 7 days; cached reads are fast and free).

When to use it

  • Identify distressed properties (high lien-to-value ratio, pre-foreclosure).

  • Pre-screen wholesale outreach lists for owner-equity position.

  • Disclose lien position to a buyer or lender.

Pricing

5 credits per fresh request. Cached responses (within 7 days of the prior fetch for the same address) cost 0 credits.

FAQ

Is this real-time?

No — mortgage recordings post to county records with days-to-weeks lag. The 7-day cache reflects that natural cadence.

What do equity and LTV mean?

lien_summary.estimated_equity is our current estimate minus the open mortgage balance, and is negative when the balance exceeds the estimate. estimated_ltv is a percent: 64.77 means 64.77%. When equity cannot be computed it is null, and data_quality.coverage_notes says why.

What if the property has no mortgage?

If the address matched but nothing is recorded, the mortgage arrays are empty and data_quality.coverage_notes says so. Still counts as 5 credits (the call ran).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "address": "<address>"
    },
    "name": "get_mortgage_lien_analysis"
  }
}

Input Schema

NameRequiredDescriptionDefault
addressYesFull property address.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, openWorldHint, and destructiveHint=false, but the description adds substantial undisclosed behavior: a 60-second client timeout requirement, 7-day caching with free cached reads, 5-credit cost per fresh call including empty-result calls, and county-recording lag. It also explains null/empty-array semantics and points to data_quality.coverage_notes for the why.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with 'What it returns' and clear headers, so an agent can scan quickly. The 7-day cache is restated three times (Performance, Pricing, FAQ 'Is this real-time?'), which is mild redundancy in an otherwise information-dense description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return shapes needn't be spelled out, yet the FAQ still clarifies the two most misinterpretable fields (estimated_equity negativity, estimated_ltv as a percent). Latency, cost, caching, and no-data behavior are all covered — nothing needed to call this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With a single parameter at 100% schema description coverage and an example address in the schema, the schema carries the load. The description adds only indirect semantics — that matching is address-based and can succeed while returning no records — but gives no input format, geocoding, or validation guidance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Mortgage and lien records for a US property') and enumerates the exact contents: current/historical mortgages, lien summary, involuntary liens, pre-foreclosure status, and data-quality metadata. No sibling (get_comps, get_property_info, get_full_report) covers mortgage/lien data, so an agent can route here without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'When to use it' section gives three concrete scenarios (distressed-property screening, wholesale list pre-screening, lien disclosure to buyer/lender). It does not name when NOT to use it or which sibling to pick for overlapping needs (e.g. get_full_report bundling), so it stops short of explicit alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources