C4C: Mortgage Industry Regulations

Search regulations

search_regs

Read-onlyIdempotent

Search US mortgage regulator text. Prefer the regulator's vocabulary ("debt-to-income ratio"); common abbreviations (DTI, LTV, RSU, IRRRL, W-2, VOE, PITI, BK ...) are expanded for you. Each result gives the section title and a verbatim excerpt; match "partial" means the section lacks the words in missing_terms -- if a missing word is the point of the question, that section does not answer it. ORDER: results are sorted by rank_score, highest first, with no separate tiers: score (text match, title-weighted) x term coverage x title fit (a section or document whose title names the whole query ranks higher), with superseded, pending, incorporated or expired text x0.2 and a special program's section (special_program: Home Possible, HomeReady, 203(k), HECM...) x0.5 unless the query names the program. canonical_citation is the section's citation in the regulator's own style (null when it cannot be derived): cite it rather than a cite from memory. currency_kind filters to sections with that currency signal (e.g. "dual-version" for FHA sections Update 18 revises, "pending", "revision-pending", "expired"; "any" = any signal). If the titles don't fit the question, search again with other terms. A special program's section (HomeStyle, 203(k), IRRRL...) applies only to that program. Excerpts are not the full rule: answer by quoting the regulator's text verbatim with its section citation -- find_in_section returns just the paragraphs with your terms (fastest), get_obligation the whole section. A non-null currency is a warning (two versions / revision pending / pending / superseded / predates the statute / incorporated into the handbook / expires / source relocated): tell the user. version "update-18-optional" marks HUD's Update 18 revision of an FHA section (optional now, mandatory on mandatory_date), "in-force" the text that governs by default; other_version is the other text's obligation_id. An empty result: search once more in the regulator's own terms (guidance names any shorthand to spell out). If that is also empty, THE CORPUS DOES NOT ADDRESS THIS: say so; do not supply the answer from your own knowledge.

Input Schema

TableJSON Schema

Name	Required	Description
`limit`	No
`query`	Yes
`family`	No
`currency_kind`	No	Only sections carrying this currency signal, e.g. "dual-version", "pending", "revision-pending"; "any" for any signal.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 26, 2026

addedInput schema / properties / currency_kind

Added value: +{
+  "description": "Only sections carrying this currency signal, e.g. \"dual-version\", \"pending\", \"revision-pending\"; \"any\" for any signal.",
+  "enum": [
+    "any",
+    "dual-version",
+    "revision-pending",
+    "pending",
+    "expires",
+    "expired",
+    "superseded",
+    "predates-statute",
+    "incorporated",
+    "incorporated-update-18",
+    "revised",
+    "revised-this-update",
+    "source-relocated",
+    "proposed",
+    "directive-watch",
+    "vacated-watch"
+  ],
+  "type": "string"
+}

First observedSep 26, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare the tool read-only and idempotent, and the description goes well beyond that by disclosing sorting logic, abbreviation expansion, partial-match semantics, currency warnings, version states, and the exact empty-result protocol. There is no contradiction with the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

The description is information-dense and every sentence adds value, but it is a single long run-on block with complex formula-like ordering details that are hard to parse quickly. It could benefit from structured bullets or shorter sentences for better scannability, though it is not bloated with filler.

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?

There is no output schema, so the description must carry the full burden of explaining result fields and interpretation, and it does so thoroughly: rank_score, missing_terms, canonical_citation, currency, version, other_version, special_program, and guidance are all explained or referenced. An agent has enough context to invoke, interpret, and follow up correctly.

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?

Schema description coverage is only 25%, but the description compensates strongly for the crucial query parameter by explaining vocabulary preference and abbreviation expansion, and for currency_kind by explaining the filter and examples. The family and limit parameters are not explicitly described, but their enum values and schema constraints are self-explanatory.

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 ('Search US mortgage regulator text') and clearly differentiates itself from siblings by positioning find_in_section as returning just paragraphs and get_obligation as returning the whole section. The description makes it obvious that search_regs is the corpus-wide search entry point and not a retrieval tool for full text.

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?

Provides explicit guidance on when and how to search: prefer regulator vocabulary, search again if titles don't fit, and what to do on empty results ('search once more... say so; do not supply the answer from your own knowledge'). It also names the alternative tools and when to use them, so an agent can route correctly without guessing.

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

All C4C: Mortgage Industry Regulations tools Inspect

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

Need Help?