Skip to main content
Glama
Sign In

Movable Capital: verified cash rates

by com.movablecapital.www
OverviewDiscussionsAdmin

Check a mortgage escrow payment

check_escrow
Read-only

Check whether a mortgage escrow payment is right under the federal escrow rules (RESPA, Regulation X): 1/12 of the yearly property tax and insurance bills, plus any shortage spread over 12 months, with a cushion of at most 1/6 of the bills. Compares with the servicer's new amount if given. Use for "my escrow went up", "is my escrow payment too high".

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": {
      "property_tax_yearly": "<property_tax_yearly>",
      "insurance_yearly": "<insurance_yearly>",
      "escrow_balance": "<escrow_balance>"
    },
    "name": "check_escrow"
  }
}

Input Schema

NameRequiredDescriptionDefault
tax_monthsNoMonths (1-12) the tax installments are paid, e.g. [6, 12]. Default [12].
other_monthlyNoMortgage insurance or flood insurance paid monthly from escrow. Default 0.
escrow_balanceYesEscrow balance now, from the latest statement.
insurance_monthNoMonth (1-12) the insurance renews. Default 1.
insurance_yearlyYesYearly homeowners insurance paid from escrow.
next_payment_monthNoMonth (1-12) of the next mortgage payment. Default next month.
property_tax_yearlyYesYearly property tax paid from escrow, in dollars.
servicer_new_escrowNoThe new monthly escrow amount the servicer quoted (escrow only), to compare. Optional.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4/5.0
Behavior4/5

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

Annotations already establish readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds substantive context on how the answer is derived (cushion cap of 1/6, shortage amortization) and that it will compare against the servicer's quoted figure when supplied. What is missing is any indication of the shape of the answer — a dollar variance, a boolean verdict, or a breakdown.

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 purpose leads, the rule formula follows, and the use-case phrases close — a sensible front-loaded order with no filler. It is dense in a single block, and the embedded statutory formula is long, but every clause carries information an agent would otherwise have to guess.

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

Completeness3/5

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

For an 8-parameter tool with no output schema, the description covers inputs and methodology well but says nothing about what is returned or how to interpret a mismatch with the servicer's amount. An agent knows when and how to call it, but not what to expect back.

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?

Schema coverage is 100% and each of the 8 parameters carries its own description, so the schema does the heavy lifting and a baseline of 3 applies. The description adds conceptual linkage — how the yearly figures, balance, and cushion feed the calculation — but does not clarify the effect of timing inputs like tax_months, insurance_month, or next_payment_month.

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 and resource ('Check whether a mortgage escrow payment is right') and grounds it in a named rule set (RESPA, Regulation X). The formula (1/12 of yearly tax and insurance, shortage over 12 months, cushion capped at 1/6) makes the operation unambiguous and easily separable from the rate/yield siblings.

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?

Gives concrete user-intent triggers ('my escrow went up', 'is my escrow payment too high'), which tells an agent exactly what kind of question routes here. It stops short of naming when-not-to-use conditions or alternative tools, but the sibling set is entirely unrelated, so the practical risk of misrouting is low.

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

All Movable Capital: verified cash rates toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources