RateAPI — live US mortgage, auto, HELOC, personal & deposit rates

check_competitive_position

Read-only

LENDER-side 'is my offer competitive' check — input your OWN published rate for a state+product, get the market percentile, bps vs the state median, and a leading/competitive/overpriced verdict. This is for a loan officer or credit union benchmarking their published pricing against the live market distribution. Do NOT use this for a consumer's quote: if the user is a BORROWER asking whether a rate they were offered is fair, use rate_sanity_check instead.

Input Schema

TableJSON Schema

Name	Required	Description
`apr`	No	The lender's published APR. Optional — falls back to rate.
`rate`	Yes	The lender's OWN published note rate as a percentage (e.g. 6.49). Required.
`state`	Yes	US state code (2-letter, e.g. CA, TX). Required.
`product`	Yes	Mortgage product the lender publishes. Required.

Output Schema

TableJSON Schema

Name	Required	Description
`note`	No	Ready-to-quote sentence stating how this offer ranks against live offers and by how many basis points.
`state`	No	Two-letter US state code the result is scoped to (e.g. 'CA'). Null means the result was not filtered by state.
`market`	No	Distribution of live offers this position was measured against.
`product`	No	Product key the offer was compared against, e.g. '30yr_fixed'.
`verdict`	No	Qualitative placement of the offer against the market, e.g. 'competitive', 'above_market', 'market_leading'.
`percentile`	No	Where this offer sits in the market distribution, 0-100, lower being cheaper. 43 means about 43% of live offers are cheaper than it.
`your_offer`	No	The rate and APR the caller supplied for comparison.
`bps_vs_median`	No	Distance from the market median in basis points (-4 = 4 basis points below, i.e. better than median).

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful context: it operates on the lender's OWN rate, benchmarks against the live market distribution, and produces a verdict. It does not contradict annotations and complements them with audience and data-source context.

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?

Two sentences carry the essential information with no filler, front-loading the key distinction (lender-side) and ending with a clear exclusion. Every clause earns its place, including the concrete output list and the sibling pointer.

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?

The description fully equips an agent to select and invoke the tool correctly: audience, input requirements, output types, and when-not-to-use are all stated. With an output schema present and safety annotations covering read-only behavior, nothing critical is missing.

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 the schema already documents all parameters including the APR fallback and required properties. The description reinforces 'OWN published rate' and 'state+product' but does not add substantial meaning beyond the schema, which is acceptable at baseline 3.

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 uses a specific verb and resource: 'LENDER-side is my offer competitive check' with concrete outputs (market percentile, bps vs state median, verdict). It clearly identifies the audience (loan officer/credit union) and distinguishes itself from rate_sanity_check, which is named as the alternative.

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?

Explicit guidance is provided: use this when benchmarking the lender's own published pricing, and explicitly avoid it for borrower quote fairness checks, directing to rate_sanity_check instead. This is unambiguous and actionable.

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

All RateAPI — live US mortgage, auto, HELOC, personal & deposit rates tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.6/5.0

Disambiguation3/5

Many tools occupy closely related decision and rate-lookup spaces—get_financing_decision, rate_sanity_check, compare_products, batch_decisions, and simulate_decision can all appear relevant to a shopping question. The descriptions work hard to disambiguate them, and some pairs are explicitly cross-referenced, but the boundary between tools like create_monitor and create_competitor_monitor or rate_sanity_check and check_competitive_position still requires careful reading.

Naming Consistency4/5

The set mostly follows a clear snake_case verb_noun pattern: create_*, update_*, delete_*, get_*, list_*, scan_*, simulate_*, send_*. Minor deviations like max_loan, rate_sanity_check, and refinance_break_even break the verb-led convention, and get_ vs list_ is used somewhat loosely, but the overall pattern remains predictable.

Tool Count1/5

At 80 tools, this is an extremely large surface for a rates API. Even though the server spans rate data, financing decisions, membership eligibility, email campaigns, monitors, digests, and documentation, 80 tools is excessive and will overwhelm agents with selection overhead.

Completeness4/5

The core domain is covered thoroughly: raw rate lookup, benchmarks, history, financing decisions, affordability, refinance analysis, eligibility, campaigns, monitors, cohorts, scenarios, and shares all have lifecycle support. Minor gaps exist—there is no update_cohort or update_scenario, and raw deposit-rate listing is less explicit than mortgage/auto rate listing—but agents can work around these.

Resources

Need Help?