bluerate: Find a Mortgage Loan Officer

Request a call back from a loan officer

request_callback

Creates a one-time bluerate.ai link (confirmationUrl, valid for 24 hours) for asking a loan officer listed on bluerate.ai to call back. The person who wants the call opens the link, enters their own phone number and email, agrees to be contacted and submits; only then is the loan officer notified. Phone numbers and email addresses are not accepted here. Takes the loan officer's NMLS ID and, optionally, the person's name, state and loan purpose to prefill the page.

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": {
      "nmls": "<nmls>"
    },
    "name": "request_callback"
  }
}

Input Schema

Name	Required	Description
`nmls`	Yes	The loan officer's NMLS ID, digits only: the nmls field of a search result or profile.
`state`	No	The US state of the property, two-letter code, for example CA.
`loanPurpose`	No	What the loan is for.
`borrowerName`	No	The user's name, if they gave it, to prefill the page. They can change it there.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 10, 2026

changedInput schema / properties / nmls / description

Previous value: -"The loan officer's NMLS ID, digits only, as search_loan_officers or get_loan_officer returned it."New value: +"The loan officer's NMLS ID, digits only: the nmls field of a search result or profile."

First observedNov 10, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Beyond the annotations (openWorldHint=false, destructiveHint=false), the description discloses real mechanics: the link expires in 24 hours, the loan officer is notified only after the person submits consent, and no contact data is collected at this call. The agent knows the side-effect timing and the human-in-the-loop requirement.

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

Conciseness5/5

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

Three tight sentences, front-loaded with what is produced (the one-time link), followed by the consent flow and then the inputs. No filler, and the parenthetical validity window is placed where it matters.

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?

With no output schema, the description still tells the agent what comes back (confirmationUrl, 24-hour validity) and what happens downstream (notification only after submission). For a four-parameter, low-complexity tool this leaves nothing essential unanswered.

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%, so every parameter already carries its own description and the baseline is 3. The description adds only modest context that state, borrowerName and loanPurpose are prefills the person can change on the page, and it reconfirms that nmls is the loan officer's ID.

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?

The description names a concrete verb-object pair: it creates a one-time bluerate.ai confirmation link for requesting a callback, and labels the required identifier (the loan officer's NMLS ID). It is unmistakable against the sibling get_loan_officer/search_loan_officers tools, which read data rather than generate a link.

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?

It sets a clear boundary: phone numbers and email addresses are not accepted here, because the person opens the link and enters their own details. That effectively says when-not to use another channel, but no sibling alternative is named for the read-only lookups an agent might chain before calling this.

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

All bluerate: Find a Mortgage Loan Officer 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?