Skip to main content
Glama

mtgmon Mortgage Analytics

Market rate snapshot

get_market_snapshot
Read-onlyIdempotent

Latest U.S. mortgage rates, TBA par coupons, Treasury and SOFR benchmarks, and mtgmon's fitted MBS basis in one call. No arguments.

Use for: "what are mortgage rates today", 30y vs 15y, current coupon, 2y/10y Treasury, SOFR swap levels, whether MBS spreads are rich or cheap versus the model. Do not use for: rate history (not exposed here) or GSE loan performance (get_loan_performance).

Returns data.rates, a list of up to 9 points {series, date, value, previous_value, change} for series MORTGAGE30US and MORTGAGE15US (Freddie Mac PMMS, weekly), tba_par_coupon_30y and tba_par_coupon_15y, 2Y and 10Y Treasury, and SOFR O/N, SOFR 2Y, SOFR 10Y; plus data.mbs_basis {model_version, latest_date, latest_basis_bps, latest_fair_bps, latest_gap_bps, latest_gap_zscore, r2_level_full_sample, ec_half_life_days, ...}. Rates are percent, basis is basis points. Series have different observation dates; quote each point's own date.

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, never report it as zero: retry after a few seconds only when meta.cache_status is 'miss' (warming); otherwise report the data as unavailable.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_market_snapshot"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
dataNo
metaYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedOutput schema / $defs / ResultMeta / properties / cache_status / description
      Added value: +"Server cache state: hit; stale (older than its TTL, still served); stale-refresh; miss (warming, retry after a few seconds); failed or required-miss (not available now, a retry soon will not help); none; unknown."
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations' readOnly/idempotent/openWorld hints, the description adds the concrete rate limits (about 60 requests/min and 250 tool calls/day per IP), no auth requirement, the {data, meta} envelope with named meta fields, and an explicit failure-mode rule: if meta.available is false, never report zero and only retry when meta.cache_status is 'miss'. That is genuinely operational context an agent could not infer.

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?

The description is long but tightly structured into purpose, use-for, do-not-use-for, return shape, and behavior sections, with the most decision-relevant content (what it is, when to call it) front-loaded. A few clauses restate annotation-declared traits ('read-only', 'safe to retry'), but the added specifics around them justify most of the length.

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?

Despite an output schema existing, the description still supplies what the schema cannot: units (percent vs basis points), the warning that series have different observation dates, and the semantics of meta.available/meta.cache_status including how to behave when data is missing. Nothing an agent needs to call and interpret this tool correctly appears to be missing.

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

Parameters4/5

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

There are zero parameters, so there is nothing to disambiguate; the description correctly states 'No arguments,' which matches the empty schema. No value is added beyond confirming the call is argument-free, so it sits at the zero-parameter baseline rather than above it.

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 first sentence names the specific resource set (mortgage rates, TBA par coupons, Treasury and SOFR benchmarks, fitted MBS basis) and states the scope in one call with no arguments. An agent can tell exactly what data comes back and that this is a snapshot rather than a history or analytics tool.

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?

An explicit 'Use for:' list gives concrete query shapes (today's rates, 30y vs 15y, current coupon, 2y/10y, SOFR levels, rich/cheap spreads), and a 'Do not use for:' line excludes rate history and routes loan performance to get_loan_performance. Both the selection condition and the alternative are stated.

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