Skip to main content
Glama

Mortgage Rate

MortgageRate
Read-only

Mortgage Rate: Mortgage Rate reports weekly US fixed mortgage rates for 15-year and 30-year terms. Pass the loan term to get the latest percentage rate, survey date, and direction of weekly change, while paid plans add 4-week and 52-week changes, the 52-week high, low and average, and the last 52 weekly rates. (Cost: 2 credits)

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": {
      "type": "<type>"
    },
    "name": "MortgageRate"
  }
}

Input Schema

NameRequiredDescriptionDefault
typeYesThe mortgage type
yearNoYear to retrieve rates for (1971-present). Requires month parameter.
monthNoMonth to retrieve rates for (1-12). Required when year is specified.
changesNoInclude the 4-week and 52-week changes and the 52-week high, low and average (current rate only)
historyNoInclude the weekly rates for the 52 weeks ending at the latest survey (current rate only)

Output Schema

NameRequiredDescriptionDefault
dataNo
errorNoError message, null on success
statusNo"ok" on success

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already establish readOnly, openWorld, non-destructive, so the bar is lower; the description adds genuinely useful context beyond them: a 2-credit cost, the fact that paid plans gate the 4-week/52-week change fields and the 52-week high/low/average and history data, and the direction-of-change field. It does not discuss rate limiting or caching, but the plan-gating disclosure is the key behavioral fact an agent needs.

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?

A single tight paragraph that front-loads what the tool reports, then how to call it, then what extras are available. The only waste is the redundant 'Mortgage Rate: Mortgage Rate reports' opening that restates the name.

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

Completeness4/5

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

Output schema exists, so return values need not be spelled out, yet the description usefully summarizes them anyway. For a 5-parameter tool it covers the main path, cost, and plan gating well; the one omission is the historical year/month retrieval capability, which an agent would only discover from the schema.

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?

With 100% schema coverage the baseline is 3, and the description adds meaning the schema lacks: the accepted term values (15-year and 30-year) since the 'type' property has no enum, and the linkage that the 'changes' and 'history' flags are paid-plan features returning specific aggregates. It omits any mention of the year/month historical parameters, which is a real gap.

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 states a specific verb and resource — reporting weekly US fixed mortgage rates for 15-year and 30-year terms — with clear scope boundaries. An agent can distinguish it from the mortgage/loan calculators and generic rate siblings in the list without opening any schema.

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

Usage Guidelines3/5

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

It tells the agent to 'pass the loan term to get the latest percentage rate', which implies the primary usage pattern, and the cost note gives a reason to avoid over-calling. However, it never states when to prefer this over MortgageCalculator, InterestRate, or BenchmarkRate, nor when to use historical (year/month) retrieval versus the current rate.

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.