C4C: Mortgage Industry Regulations

Get regulation

get_reg

Read-onlyIdempotent

Returns a manifest of one register (source document): its provenance, currency (null or a version/status signal: dual-version, pending revision, superseded, expired...) and its obligations (sections), each with obligation_id, section, canonical_citation, chars_total and will_truncate (true when the section exceeds one 24,000-char page). The manifest contains no regulator text. A dual-version section lists both obligations, each with version ("in-force" or "update-18-optional") and other_version.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`register_id`	Yes

Output Schema

TableJSON Schema

Name	Required	Description
`hint`	No	On an error: the server's explanation.
`kind`	No	"renumbered": the regulator gave this section a new number; no text is given under the old one.
`note`	No	A note on this result.
`error`	No	Present only on an error or refusal: not_found, ambiguous, unparsed, empty_terms, unknown_playbook, unknown_reference, offset_out_of_range, daily_capacity_reached.
`notice`	No	Terms notice: research use only, not legal advice.
`resets`	No	On daily_capacity_reached: when capacity resets (00:00 UTC).
`status`	No	E.g. current, superseded, unknown.
`also_at`	No	Same-text copies of this register.
`currency`	No	null, or a version/status signal {kind, headline, detail, effective_date, mandatory_date, expires_on, as_of, links}; kind e.g. dual-version, pending, revision-pending, superseded, superseded-in-part, modified-by, expired.
`fallback`	No	On daily_capacity_reached: where the full corpus can be downloaded.
`guidance`	No	On a refusal or empty search: the server's explanation.
`page_url`	No	The section's page on claudeforcompliance.com (verbatim text, currency notices, link to the regulator).
`authority`	No	The document title.
`source_url`	No	The regulator's URL for the document.
`obligations`	No	The register's obligations (a manifest, not regulator text).
`register_id`	No	The register id.
`canonical_id`	No	Set when this register is a same-text copy of that register.
`requested_id`	No	On kind renumbered: the old id asked for.
`text_changed`	No	On kind renumbered: false when the text moved word for word.
`coverage_tier`	No	How completely the corpus holds the document.
`obligation_id`	No	Echoed on error.
`renumbered_in`	No	On kind renumbered: the regulator's posting that renumbered it.
`renumbered_on`	No	On kind renumbered: when (YYYY-MM).
`superseded_by`	No	The replacing register, or null.
`effective_date`	No	Effective date, or null.
`renumbered_from`	No	The old register, when the section was renumbered.
`canonical_citation`	No	The citation in the regulator's style (e.g. "4000.1 II.A.5.d", "B3-3.3-07"), or null.
`renumbered_from_citation`	No	On kind renumbered: the section's old citation.

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedOct 16, 2026

addedOutput schema / properties / kind

Added value: +{
+  "description": "\"renumbered\": the regulator gave this section a new number; no text is given under the old one.",
+  "type": "string"
+}

addedOutput schema / properties / renumbered_from

Added value: +{
+  "description": "The old register, when the section was renumbered.",
+  "type": "string"
+}

addedOutput schema / properties / renumbered_from_citation

Added value: +{
+  "description": "On kind renumbered: the section's old citation.",
+  "type": "string"
+}

addedOutput schema / properties / renumbered_in

Added value: +{
+  "description": "On kind renumbered: the regulator's posting that renumbered it.",
+  "type": "string"
+}

addedOutput schema / properties / renumbered_on

Added value: +{
+  "description": "On kind renumbered: when (YYYY-MM).",
+  "type": "string"
+}

addedOutput schema / properties / requested_id

Added value: +{
+  "description": "On kind renumbered: the old id asked for.",
+  "type": "string"
+}

addedOutput schema / properties / text_changed

Added value: +{
+  "description": "On kind renumbered: false when the text moved word for word.",
+  "type": "boolean"
+}

Changed2 schema fields changedOct 8, 2026

addedOutput schema / properties / page_url

Added value: +{
+  "description": "The section's page on claudeforcompliance.com (verbatim text, currency notices, link to the regulator).",
+  "type": "string"
+}

addedOutput schema / properties / source_url

Added value: +{
+  "description": "The regulator's URL for the document.",
+  "type": "string"
+}

Changed1 schema field changedSep 27, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": {},
+  "description": "get_reg result.",
+  "properties": {
+    "also_at": {
+      "description": "Same-text copies of this register.",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "authority": {
+      "description": "The document title.",
+      "type": "string"
+    },
+    "canonical_citation": {
+      "description": "The citation in the regulator's style (e.g. \"4000.1 II.A.5.d\", \"B3-3.3-07\"), or null.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "canonical_id": {
+      "description": "Set when this register is a same-text copy of that register.",
+      "type": "string"
+    },
+    "coverage_tier": {
+      "description": "How completely the corpus holds the document.",
+      "type": "string"
+    },
+    "currency": {
+      "description": "null, or a version/status signal {kind, headline, detail, effective_date, mandatory_date, expires_on, as_of, links}; kind e.g. dual-version, pending, revision-pending, superseded, superseded-in-part, modified-by, expired."
+    },
+    "effective_date": {
+      "description": "Effective date, or null.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "error": {
+      "description": "Present only on an error or refusal: not_found, ambiguous, unparsed, empty_terms, unknown_playbook, unknown_reference, offset_out_of_range, daily_capacity_reached.",
+      "type": "string"
+    },
+    "fallback": {
+      "description": "On daily_capacity_reached: where the full corpus can be downloaded.",
+      "type": "string"
+    },
+    "guidance": {
+      "description": "On a refusal or empty search: the server's explanation.",
+      "type": "string"
+    },
+    "hint": {
+      "description": "On an error: the server's explanation.",
+      "type": "string"
+    },
+    "note": {
+      "description": "A note on this result.",
+      "type": "string"
+    },
+    "notice": {
+      "description": "Terms notice: research use only, not legal advice.",
+      "type": "string"
+    },
+    "obligation_id": {
+      "description": "Echoed on error.",
+      "type": "string"
+    },
+    "obligations": {
+      "description": "The register's obligations (a manifest, not regulator text).",
+      "items": {
+        "additionalProperties": {},
+        "properties": {
+          "canonical_citation": {
+            "description": "The citation in the regulator's style (e.g. \"4000.1 II.A.5.d\", \"B3-3.3-07\"), or null.",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "chars_total": {
+            "description": "Length of the section's text in characters.",
+            "type": "number"
+          },
+          "currency": {
+            "description": "null, or a version/status signal {kind, headline, detail, effective_date, mandatory_date, expires_on, as_of, links}; kind e.g. dual-version, pending, revision-pending, superseded, superseded-in-part, modified-by, expired."
+          },
+          "mandatory_date": {
+            "description": "On an Update 18 revision: when it becomes mandatory.",
+            "type": "string"
+          },
+          "obligation_id": {
+            "description": "The obligation (section) id.",
+            "type": "string"
+          },
+          "other_version": {
+            "description": "On a dual-version section: the other version's obligation_id.",
+            "type": "string"
+          },
+          "section": {
+            "description": "The section designation or title.",
+            "type": "string"
+          },
+          "version": {
+            "description": "On a dual-version FHA section: \"in-force\" or \"update-18-optional\".",
+            "type": "string"
+          },
+          "will_truncate": {
+            "description": "The section exceeds one 24,000-char page.",
+            "type": "boolean"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "register_id": {
+      "description": "The register id.",
+      "type": "string"
+    },
+    "resets": {
+      "description": "On daily_capacity_reached: when capacity resets (00:00 UTC).",
+      "type": "string"
+    },
+    "status": {
+      "description": "E.g. current, superseded, unknown.",
+      "type": "string"
+    },
+    "superseded_by": {
+      "description": "The replacing register, or null.",
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "type": "object"
+}

First observedSep 26, 2026

TDQS

B3.4/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds genuinely useful behavior: the manifest contains no regulator text, `will_truncate` flags sections exceeding one 24,000-char page, and dual-version sections expose version/other_version semantics.

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?

Effectively one dense, front-loaded sentence with the purpose first and the manifest structure after. It is well-organized, though a portion of the output-field enumeration overlaps with the existing output schema.

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?

Since an output schema exists, the lengthy return-value explanation is partly redundant, and the description omits the input semantics and any usage routing an agent would need. It is adequate for calling the tool but incomplete on selection and parameter sourcing.

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 0% for the single `register_id` parameter, so the description carries the burden. It implies the parameter identifies one register/source document but gives no format, source, or how to obtain a valid id, leaving a real gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/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: it returns the manifest of one register (source document). It clearly conveys what the tool fetches, though it never differentiates this from siblings like get_obligation or search_regs, and much of the text describes output shape rather than the action itself.

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

Usage Guidelines2/5

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

There is no when-to-use guidance, no conditions for selecting this over get_obligation, search_regs, or find_in_section, and no prerequisites. The agent is left to infer the routing entirely from the name and sibling list.

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.