C4C: Mortgage Industry Regulations

Get playbook reference

get_playbook_reference

Read-onlyIdempotent

Returns one stage reference document of a playbook (e.g. the FNMA playbook's DISCOVERY, RECONCILE, SYNTHESIS, PP-UPDATE, CHANGELOG or UPDATING stage). Inputs: id, name (one of the playbook's references). Playbook tools accept only ids and reference names, no document text; the user's P&Ps and loan files stay in their own chat.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`id`	Yes	Playbook id: one of fnma-ai-lender-letter, fha-underwriting-qc, va-loan-qc, usda-loan-qc.
`name`	Yes	Reference name, one of the playbook's `references`.

Output Schema

TableJSON Schema

Name	Required	Description
`id`	No	The playbook id.
`hint`	No	On an error: the server's explanation.
`name`	No	The reference name.
`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).
`content`	No	The reference's content.
`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.
`valid_ids`	No	On unknown_playbook: the valid ids.
`valid_names`	No	On unknown_reference: the valid names.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 27, 2026

changedInput schema / properties / name / description

Previous value: -"Reference name, as listed by start_playbook's `references`."New value: +"Reference name, one of the playbook's `references`."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": {},
+  "description": "get_playbook_reference result.",
+  "properties": {
+    "content": {
+      "description": "The reference's content."
+    },
+    "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"
+    },
+    "id": {
+      "description": "The playbook id.",
+      "type": "string"
+    },
+    "name": {
+      "description": "The reference name.",
+      "type": "string"
+    },
+    "note": {
+      "description": "A note on this result.",
+      "type": "string"
+    },
+    "notice": {
+      "description": "Terms notice: research use only, not legal advice.",
+      "type": "string"
+    },
+    "resets": {
+      "description": "On daily_capacity_reached: when capacity resets (00:00 UTC).",
+      "type": "string"
+    },
+    "valid_ids": {
+      "description": "On unknown_playbook: the valid ids.",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "valid_names": {
+      "description": "On unknown_reference: the valid names.",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    }
+  },
+  "type": "object"
+}

First observedSep 26, 2026

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 and non-destructive behavior, so the safety bar is met structurally. The description adds genuine extra context: playbook tools accept only ids and reference names, no document text, and user P&Ps/loan files stay in their own chat — a useful data-boundary disclosure.

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?

Three front-loaded sentences: the return, then the inputs, then the boundary note. Each contributes, though the stage enumeration is slightly long and the input restatement partly duplicates the schema.

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 values need no explanation, and the description covers what is fetched, the required inputs, and a data-boundary caveat. The only gap is the missing routing guidance versus sibling playbook tools.

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% and both params are documented in the schema with patterns and id enumerations. The description reinforces that id/name are the inputs and that name maps to the playbook's `references`, but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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 ('Returns') and resource ('one stage reference document of a playbook') and pins it down with concrete stage examples (DISCOVERY, RECONCILE, etc.) plus the FNMA playbook. An agent can distinguish this single-stage fetch from get_playbook_kit or list_playbooks 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?

The description clarifies what `name` must be ('one of the playbook's `references`') and adds a privacy/origin constraint, which implicitly frames usage. However, it never states when to choose this over the sibling get_playbook_kit or list_playbooks, so selection guidance remains implicit.

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.