SBA Express program rules, live maximum rates, FY2027 guaranty fees, payments, and lender and state.
Scored across 9 tools
Most tools have clearly distinct purposes (calculators vs. lookups vs. reference). Some overlap exists: get_program_terms also states rate caps and FY2027 guaranty fees, which are computed by estimate_guaranty_fee and get_max_rates_today, and estimate_payment also surfaces today's rate cap. The descriptions do enough to steer an agent (rules reference vs. computed estimate vs. live rate), so boundaries are mostly clear.
Consistent snake_case verb_noun pattern throughout: estimate_*, get_*, and list_* with singular/plural nouns matching cardinality (get_lender vs. list_lenders). No mixing of conventions.
Nine tools is well within the sweet spot and each maps to a distinct informational or calculation need in the SBA Express domain. Nothing feels redundant or trivially thin.
The surface covers the domain well: fees, payments, live rate caps, program terms, lender records, lender rankings, state and national statistics, plus a financing request link. Minor gaps remain, e.g. no explicit eligibility/pre-qualification check or lender-to-borrower matching detail, but agents can work around these with existing tools.
SBA upfront guaranty fee for an SBA Express or standard 7(a) loan under the FY2027 schedule, with exceptions.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | Gross loan amount in dollars | |
| program | No | Default express | |
| exception | No | Default none | |
| maturity_months | No | Loan maturity in months. Default 120 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered without the description. The description adds the FY2027-schedule scoping and the existence of exception handling, but says nothing about how the fee is computed (e.g. percentage of the guaranteed portion) or that defaults are applied silently for omitted parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One compact sentence with the key qualifiers (fee type, program scope, schedule year) front-loaded and no filler. It is a noun phrase rather than a full statement of action, but nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
All four parameters are covered by the schema and the tool is read-only, so little behavioral disclosure is needed. However, with no output schema, the description never indicates what is returned (a dollar fee amount, a rate, a breakdown), leaving a real gap for a calculator tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and every parameter, including the two enums, is documented inline, so the baseline of 3 applies. The description contributes only the schedule year and the vague 'with exceptions', which does not explain what each exception enum value changes about the result.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the specific resource (SBA upfront guaranty fee) and constrains it to the FY2027 schedule for Express or standard 7(a) loans, which matches the program enum in the schema. It does not explicitly contrast itself with siblings such as estimate_payment or get_max_rates_today, so the agent must infer the boundary itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this tool versus the other estimators, nor any prerequisite or exclusion guidance. The phrase 'with exceptions' hints that an exception path exists but does not tell the agent when to reach for it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Level monthly payment and total interest for a fully amortizing loan. Also returns today's SBA Express rate cap for the amount.
| Name | Required | Description | Default |
|---|---|---|---|
| rate | Yes | Annual interest rate in percent, e.g. 10.5 | |
| years | Yes | Term in years, e.g. 10 | |
| amount | Yes | Loan amount in dollars |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnly/idempotent annotations already establish this as a safe, repeatable calculation, so the description's bar is lower. It usefully discloses a non-obvious side output (today's SBA Express rate cap), but says nothing about the amortization formula, rounding, currency, or whether the rate cap is always returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences, front-loaded with the primary computation. The second sentence is a slight non sequitur relative to the main purpose but each sentence does carry information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does name both return values (monthly payment and total interest) and mentions an extra rate-cap value. What remains missing (payment frequency is only implied by 'monthly', no formula or rounding detail) is minor for a three-number calculator.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so percent-vs-decimal rate, years and dollar amount are already documented. The description adds nothing beyond the schema about the three parameters, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific computation (level monthly payment and total interest for a fully amortizing loan) with a clear resource and named outputs. Slightly muddied by the second sentence, which adds a rate-cap lookup that overlaps with the sibling get_max_rates_today, so the tool's boundary with that sibling is not clean.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: you call it when you need a payment estimate. There is no explicit statement of when to prefer get_max_rates_today or get_program_terms instead, and no mention that the rate must be supplied by the caller rather than fetched.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Link where a small business owner can request SBA Express financing options; the request is routed to lending partners. Free, no obligation.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 description only needs to add what they cannot. It does add real context — requests are routed to third-party lending partners and carry no cost or obligation — but leaves unresolved whether the link is static or tracked, whether it expires, and whether any user data must be supplied beforehand.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short clauses, front-loaded with what the link is for and backed by the relevant qualifier about cost and obligation. Nothing is padded, though the phrasing is closer to marketing copy than operational guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool whose annotations already declare read-only safety, the description supplies enough to call it correctly. The only mild gap is not stating explicitly that the return value is a URL.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the schema carries no semantic burden and the baseline applies. The description correctly implies no inputs are needed, though it does not state that outright.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource concretely — a link for requesting SBA Express financing options routed to lending partners — which is distinguishable from siblings like list_lenders or get_program_terms. It stops short of an explicit verb such as 'returns a URL', but the noun phrase 'Link where...' makes the output type clear enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: an agent can infer this is the referral/application path rather than a rate or fee lookup, and 'Free, no obligation' reassures the end user. There is no explicit when-to-use, when-not-to-use, or named alternative (e.g., use get_program_terms first to check eligibility).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A lender's SBA Express lending record: loan count, sizes, line of credit share, top states. Matches on lender name.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Lender name, e.g. 'TD Bank' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered without the description. The description adds the return-field inventory and the name-matching basis, but stays silent on match strictness (exact vs partial) and no-result behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One tight sentence with the resource and its contents front-loaded before the matching rule. Slightly telegraphic phrasing ('sizes', 'share') but no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully doubles as a return-field summary, which is the key thing an agent needs for a simple one-parameter read. The only real gap is the absence of no-match/ambiguity behavior, which matters more here because the lookup is name-based.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter already carries an example ('TD Bank'). The description adds only the fact that 'name' is the match key, which is marginal value over the schema; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource (one lender's SBA Express lending record) and enumerates the contents: loan count, sizes, line of credit share, top states. The singular 'a lender's ... record' implicitly separates it from list_lenders, though it never names that sibling, so an agent must infer the distinction rather than being told.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: 'Matches on lender name' signals this is a lookup by known name, which contrasts with list_lenders for enumeration. There is no explicit when-to-use, no guidance on resolving an unknown or ambiguous lender name, and no statement of what happens when no lender matches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Today's maximum variable interest rate for SBA Express (and 7(a)) loans by loan size: live WSJ Prime plus SBA's capped spread. Optionally pass an amount to get the cap for that loan.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | No | Gross loan amount in dollars (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive, closed-world behavior. The description adds meaningful domain behavior: the rate is today's live WSJ Prime plus SBA's capped spread and can be narrowed by loan amount. It does not discuss caching/freshness or output shape, but with annotations present this is solid added context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with the core rate definition front-loaded and the optional parameter second. No redundant or filler wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-optional-parameter rate lookup with full schema coverage and no output schema, the description supplies the source, scope, and parameter effect. It could be slightly more explicit about the return structure (e.g., rate tiers by loan size), but it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameter's type and 'gross loan amount in dollars' meaning are already documented. The description adds that supplying it returns the cap for that loan, but does not explain tier boundaries or how the cap changes by amount beyond that. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource—today's maximum variable SBA Express/7(a) rate—and explains it is broken down by loan size and derived from WSJ Prime plus a capped spread. It is distinguishable from estimator/listing siblings, though it does not explicitly name an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies usage for current rate lookup and explains the optional amount, but gives no explicit when-to-use/when-not guidance or point to sibling tools such as get_program_terms or estimate_payment. An agent must infer the selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
SBA Express loans by fiscal year, loan sizes, borrower types, industries, rates at approval and charge-offs, from SBA's loan-level file.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds useful provenance ('from SBA's loan-level file'), implying this is derived/aggregated data rather than live records, but says nothing about aggregation granularity, time coverage, or how results are grouped.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence with no wasted words, front-loading the subject (SBA Express loans) and the breakdown dimensions. It is efficient, though it reads as a content inventory rather than a lead statement of what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no input parameters and no output schema, the description carries most of the burden and does list the dimensions of the returned data. However, it omits the shape of the response (aggregated table vs. raw loan rows), the fiscal years covered, and any granularity caveat, leaving an agent guessing about the result structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4; there is no parameter meaning for the description to add. Schema coverage is nominally 100% because the schema is empty, so no compensation is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource (SBA Express loans) and enumerates the breakdown dimensions returned — fiscal year, loan size, borrower type, industry, approval rates, charge-offs — which tells an agent concretely what the tool produces and separates it from siblings like get_program_terms or get_max_rates_today. It lacks an explicit verb ('returns statistics for...'), but the content enumeration effectively supplies the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance and no alternatives named; the agent must infer that this is the program-wide statistical view rather than the per-lender or per-state tools. Nothing says when this data is preferable to get_program_terms or estimate_guaranty_fee, and there are no prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
SBA Express program rules: maximum loan, SBA guaranty, rate caps by loan size, line of credit rules, FY2027 guaranty fees and exceptions, with sources.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered by structured data. The description adds that results are sourced ('with sources') and scopes the content to FY2027 fees plus exceptions, which is useful. It does not describe return format, currency/percentage conventions, or how the source citations appear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that leads with the resource and then enumerates contents; every clause maps to a distinct piece of returned information and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of conveying what comes back, and the enumerated content areas do that reasonably well for a zero-parameter reference tool. Missing only the shape of the answer (structured fields vs. prose) and whether figures are dated or jurisdiction-scoped.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters, so the baseline is 4. The description correctly implies a parameterless reference lookup and gives no misleading hints about filtering or selectivity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the specific resource (SBA Express program rules) and enumerates the covered content: maximum loan, guaranty, rate caps by loan size, line of credit rules, FY2027 guaranty fees and exceptions. That is clearly distinct from sibling calculators like estimate_guaranty_fee and from the live-data tool get_max_rates_today, though it never explicitly states that contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: an agent can infer this is the static policy reference to consult before or after calling estimate_guaranty_fee or estimate_payment. There is no explicit when-to-use, when-not-to-use, or prerequisite guidance, and no routing away from get_max_rates_today (live rates) versus the rate-cap rules described here.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
SBA Express loan count, dollars, median loan, top lenders and top industries for one state.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | Two-letter code or state name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered without the description. The description's contribution is the returned metric set (count, dollars, median loan, top lenders, top industries), which is real added context given there is no output schema. It says nothing about the aggregation time window or data vintage, which are the behaviors an agent would still need to know.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One compact sentence listing exactly the measures returned, with the scoping constraint ('one state') placed at the end. Nothing is redundant. The only flaw is that it is a noun phrase without a verb, so it reads as a label rather than an instruction.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read tool, the definition covers what dimensions come back and the annotations cover safety, so an agent can call it correctly. It omits the reporting period and data source, however, which matters for a statistics tool where 'dollars' could be fiscal-year, calendar-year, or cumulative. That gap is the main thing keeping this from being complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single 'state' parameter documents that a two-letter code or full state name is accepted. The phrase 'for one state' in the description reinforces the single-state granularity but adds no syntax or format detail beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the specific resource (SBA Express lending in a single state) and enumerates the returned measures: loan count, dollars, median loan, top lenders, top industries. That is far more informative than the ambiguous tool name 'get_state'. It stops short of a leading verb and never distinguishes itself from sibling get_program_statistics, which an agent could easily mistake for this.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use guidance, no exclusions, and no mention of alternatives such as get_program_statistics, get_lender, or list_lenders. The agent must infer from the tool name and the metric list whether this is the right call for a given question.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lenders ranked by number of SBA Express loans in the most recent fiscal years. Pass a state to get the most active lenders there.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Default 10, max 100 | |
| state | No | Two-letter code or state name (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered. The description adds the ranking criterion and the state-scoping behavior, which is useful, but says nothing about ordering of results, whether output is truncated, or how 'most recent fiscal years' is defined.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the resource and ranking basis front-loaded, followed by the optional filter. No filler, though the second sentence could be trimmed or merged since the schema already marks state as optional.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-optional-parameter read tool with full schema coverage, rich annotations, and no output schema, the description covers what the tool returns conceptually and how state affects it. The only gap is the unspecified meaning of 'most recent fiscal years' and any cap on returned rows.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented, establishing a baseline of 3. The description adds only that 'state' scopes the ranking geographically; it adds nothing about how 'limit' interacts with the ranking cutoff.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a concrete resource (SBA Express lenders) and the ranking basis (number of loans in the most recent fiscal years), plus the optional state filter. It does not explicitly distinguish itself from the sibling get_lender, which is a single-lender lookup, so the agent must infer the list-vs-lookup distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the ranking framing and the 'pass a state' sentence suggest this is the tool for finding top lenders nationally or within a state. There is no explicit when-not-to-use guidance or reference to get_lender for single-lender details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
estimate_guaranty_feeestimate_paymentget_financing_linkget_lenderget_max_rates_todayget_program_statisticsget_program_termsget_statelist_lendersMatch deals to commercial mortgage programs; program rules, live rates, loan sizing, prepayment.
Hotel and motel loan sizer, franchise fees for 48 brands from filed FDDs, SBA hotel terms.
2025 HMDA FHA denial statistics and dated US mortgage rule tables, with verifiable receipts.
HMDA investor-lender data, DSCR glossary, loan programs and indicative rates. Business-purpose only.
Add one secure layer between your agents and this server.
