Skip to main content
Glama

Zeitro: Mortgage Guidelines

Calculate FHA mortgage insurance premium

calculate_fha_mip
Read-onlyIdempotent

Calculates the FHA upfront and annual mortgage insurance premium (rates, dollar amounts, first-year monthly premium and how long the annual premium lasts) from the base loan amount, loan-to-value ratio, term and the case number date, using the HUD rate schedule in force for that date. Cites the Mortgagee Letter and HUD Handbook 4000.1 Appendix 1.0. Pure calculation: an estimate, not a loan approval.

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": {
      "base_loan_amount": "<base_loan_amount>",
      "ltv": "<ltv>"
    },
    "name": "calculate_fha_mip"
  }
}

Input Schema

NameRequiredDescriptionDefault
ltvYesLoan-to-value ratio as a percent, e.g. 96.5: base loan amount divided by the lesser of price and appraised value.
term_monthsNoLoan term in months, e.g. 360 for 30 years or 180 for 15 years. Default 360.
interest_rateNoNote rate as an annual percent, e.g. 6.25; gives the first-year premium on the average scheduled balance.
base_loan_amountYesBase loan amount in dollars, before any financed upfront premium.
case_number_dateNoDate the FHA case number was assigned, YYYY-MM-DD. Default today (UTC).
endorsement_dateNoDate FHA endorsed (or will endorse) the loan, YYYY-MM-DD, when known; it selects the 2023 rates for case numbers assigned before 2023-03-20.
refinances_loan_endorsed_before_june_2009NoTrue for a Streamline or Simple Refinance of an FHA loan endorsed on or before May 31, 2009. Default false.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world behavior, so the safety profile is covered. The description adds meaningful context beyond them: it discloses the authority being applied (HUD rate schedule in force for the case number date, Mortgagee Letter and Handbook 4000.1 Appendix 1.0) and that the result is an estimate rather than an approval. It does not describe failure modes or how stale/out-of-range dates are handled.

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 the calculation and its outputs, followed by a short sourcing sentence and a one-clause disclaimer. The opening sentence is dense with parenthetical output lists, but virtually every phrase carries information and nothing is wasted.

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?

An output schema exists, so return-value explanation is optional, and annotations cover the safety semantics; the description still supplies sourcing authority and the estimate disclaimer. The only real gap is routing guidance relative to sibling tools, which leaves an agent to infer when this calculator is the right call.

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 description coverage is 100%, so the baseline is 3. The description reinforces that base loan amount, LTV, term and case number date are the drivers and that the date selects the applicable HUD rate schedule, but this largely restates what the schema fields already say (endorsement_date even documents the 2023 rate cutoff explicitly).

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?

Names a specific verb and resource (FHA upfront and annual mortgage insurance premium) and enumerates exactly what the calculation returns: rates, dollar amounts, first-year monthly premium and duration of the annual premium. It also states the inputs that drive it and the rate schedule used, so an agent can distinguish it from siblings like calculate_dti or search_guidelines without opening the 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?

Usage is implied rather than stated: the tool is a pure calculator and the closing clause 'an estimate, not a loan approval' sets a scope boundary. However, there is no explicit when-to-use guidance against the sibling tools (e.g., use search_guidelines for policy interpretation) and no stated prerequisites or error conditions.

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