Skip to main content
Glama

mtgmon Mortgage Analytics

HMDA lender profile

get_lender_profile
Read-onlyIdempotent

HMDA profile for one lender group: annual origination volume, loan counts, denial rate, national rank and market share, top states with market-share multiples, and loan type / purpose / occupancy / loan-size mix.

Requires a canonical key: call search_lenders and pass the exact name (e.g. 'Rocket/Quicken'). Any other spelling returns meta.available=false with empty lists. Use compare_lenders for two lenders side by side.

Returns data.lender_key, data.name, data.leis, data.current_year, data.previous_year, data.yearly (one row per HMDA year: originated_volume, originated_loans, purchased_volume, purchased_loans, denied_loans, applications_loans, total_funded_volume, avg_loan_size, denial_rate_pct, denial_rate_count_pct, rank, national_volume, market_share_pct), data.top_states {state, volume, loans, previous_volume, previous_loans} and data.state_market_multiples {state, lender_share_pct, market_share_pct, multiple, ...} (top_n rows each), data.loan_type_mix, data.loan_purpose_mix, data.occupancy_mix ({code, label, loans, volume}), and data.loan_size_histogram. Volumes are USD; shares and rates are percent.

Behavior: read-only, no auth or API key, no PII, idempotent and safe to retry. The public endpoint https://mtgmon.com/mcp allows about 60 requests/min and 250 tool calls/day per client IP. Result shape is {data, meta}; meta carries available, as_of, source_scope, weighting, units, cache_status, caveats, and truncated. If meta.available is false the data is unavailable or the cache is still warming (retry after a few seconds); never report it as zero.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
top_nNoMaximum rows in top_states and state_market_multiples, 1-50 (default 10).
lenderYesCanonical HMDA lender key: the exact `name` value from a search_lenders result, e.g. 'Rocket/Quicken' or 'United Wholesale Mortgage'. Legal names such as 'Rocket Mortgage, LLC' do not match and return meta.available=false.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataNo
metaYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / lender / description
      Added value: +"Canonical HMDA lender key: the exact `name` value from a search_lenders result, e.g. 'Rocket/Quicken' or 'United Wholesale Mortgage'. Legal names such as 'Rocket Mortgage, LLC' do not match and return meta.available=false."
    • addedInput schema / properties / top_n / description
      Added value: +"Maximum rows in top_states and state_market_multiples, 1-50 (default 10)."
  2. First observed

TDQS

A5/5.0
Behavior5/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description goes further by stating there is no auth or API key, no PII, and it is safe to retry. It also details the public endpoint rate limits (60 req/min, 250 calls/day) and explains the meta.available false case, adding substantial behavioral context 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.

Conciseness5/5

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

The description is lengthy but every sentence earns its place: it front-loads the tool's output, then addresses key requirements, behavior, and result shape. It is well-structured, with clear paragraphs for output, canonical key, behavior, and meta handling, without redundancy.

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?

Given the tool's complexity, the description is exceptionally complete. It covers all essential aspects: return data fields, required canonical key acquisition, alternative tools, rate limits, error/retry semantics, and result shape. The output schema exists, but the description further explains the meaning of meta.available and units, making it fully self-sufficient for an agent to call correctly.

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

Parameters5/5

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

Although schema description coverage is 100%, the description enhances both parameters. For lender, it clarifies it must be the exact `name` from search_lenders and provides examples and pitfalls (legal names fail). For top_n, the schema already defines it, but the description contextually ties it to the return structure (top_states and state_market_multiples). This adds meaning beyond the schema alone.

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?

The description clearly states the tool retrieves an HMDA profile for one lender group and enumerates the specific metrics returned (volume, counts, denial rate, rank, market share, mixes). It distinguishes itself from siblings by explicitly naming search_lenders for canonical keys and compare_lenders for side-by-side comparisons, so an agent can easily differentiate it.

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

Usage Guidelines5/5

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

The description provides explicit when-to-use guidance: it requires a canonical key obtained via search_lenders, warns that alternative spellings fail, and directs to compare_lenders for two-lender comparisons. It also discloses rate limits and retry behavior, leaving no ambiguity about appropriate invocation context.

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