Dominick Prevete: Instant Term Sheet
Server Details
Written term sheets for 1–4 unit DSCR investment property loans, by email. Business-purpose only.
- Status
- Healthy
- Uptime
- 100.0% over the last 24 hours
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- ChatGPT
- –
- Claude
- –
TDQS
Scored across 2 tools
The two tools have clearly distinct purposes: one reads requirements and the other submits a request. The descriptions reinforce this by explicitly telling the agent to read the requirements tool first before using the request tool. There is no meaningful overlap that would cause misselection.
Both names use snake_case and share the instant_term_sheet domain, but one is a noun phrase while the other uses a verb_noun pattern. The deviation is minor and still readable, so the convention is mostly consistent.
Two tools are borderline for a server surface, even for a narrow workflow. The server is tightly scoped to requirements lookup and request submission, but the small count feels thin and leaves little room for supporting operations.
The core workflow is covered: discover required fields and submit a term sheet request. Minor gaps exist around status checking or retrieving the resulting term sheet via MCP, though the request returns a download link and email path that mitigate this.
Available Tools
2 toolsinstant_term_sheet_requirementsInstant Term Sheet: what to have readyARead-onlyIdempotentInspect
What an Instant Term Sheet request needs, before you make one: every field, which are required, and the accepted values; the scope (a business-purpose loan on a non-owner-occupied 1–4 unit investment property); and what the investor gets back. Read-only: nothing is priced, stored or sent. Every request, purchase or refinance, needs the property's full street address: number, street, city, state and ZIP. Reviewer mode: a request whose email address is at example.com, example.org or example.net, or at a .test or .invalid domain, is priced and answered in full with a download link, but nothing is emailed and no lead is recorded.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, but the description adds meaningful context beyond that: 'nothing is priced, stored or sent' and a detailed reviewer mode exception where .test/.invalid or example.com emails are priced and answered without being emailed or recorded. These details help the agent understand the tool's behavior and scope.
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?
The description is front-loaded with purpose and packs scope, required fields, and reviewer mode into a dense paragraph with little waste. It could be slightly easier to scan with bullet points or line breaks, but it remains appropriately sized for a reference-style tool.
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 reference tool, the description covers the required request fields, the business scope (business-purpose loan on non-owner-occupied 1–4 unit property), and what the investor receives. Annotations already cover safety and idempotency, so the definition is 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?
The tool has zero parameters, so the baseline is 4. The description does not need to explain parameter semantics, and it correctly avoids inventing any. The listed request fields pertain to the sibling request tool rather than this tool's own parameters.
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 opens with a clear verb-resource statement: what an Instant Term Sheet request needs, including required fields and accepted values. It explicitly distinguishes this reference tool from the request action by saying 'before you make one,' and the sibling request_instant_term_sheet is implied. An agent can immediately tell this is a read-only requirements lookup, not the submission tool.
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?
The phrase 'before you make one' clearly signals the intended timing and relationship to the sibling request tool. However, it does not explicitly name request_instant_term_sheet or state when-not-to-use, so the agent must infer the routing. This is clear context but short of explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_instant_term_sheetRequest an Instant Term SheetAInspect
Request a written term sheet for a business-purpose loan on a non-owner-occupied 1–4 unit investment property, emailed to the investor with a private download link. Instant where the deal fits the programs; otherwise an answer within 24 hours. A term sheet is indicative and not a commitment to lend. Every request, purchase or refinance, needs the property's full street address: number, street, city, state and ZIP. Each pricing option in the answer carries the label the term sheet prints for it (for example "Option A: lowest rate"); refer to options by that label. Read instant_term_sheet_requirements first for the fields. The request is shared with participating lenders to price it.
| Name | Required | Description | Default |
|---|---|---|---|
| loan | Yes | The loan. | |
| contact | Yes | The investor: who the term sheet is for and where it is emailed. | |
| borrower | Yes | The borrower. | |
| property | Yes | The property. | |
| dscrInputs | Yes | Rent and carrying costs: the debt service coverage ratio (DSCR) is computed from these. | |
| attestations | Yes | The investor's three representations. A request that does not make all three is answered as out of scope and not priced. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, it discloses that the term sheet is indicative and not a lending commitment, that it arrives by email with a private download link, that turnaround falls back to 24 hours when the deal does not fit, and — importantly — that the request is shared with participating lenders to price it. That data-sharing disclosure and the fallback behavior are exactly the kind of context annotations cannot convey.
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?
Every sentence carries a distinct fact: scope, delivery mechanism, timing, the indicative caveat, the address requirement, the label convention, the prerequisite tool, and the lender-sharing notice. The most load-bearing items (what it produces and the address rule) are front-loaded, with no filler or repetition.
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 complex six-required-parameter request tool with nested objects and no output schema, the description covers scope, delivery, timing, caveats, prerequisites and the critical input constraint. It could say slightly more about what the returned answer contains besides labeled pricing options, but nothing essential for correct invocation is missing.
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 schema already documents every field and the baseline would be 3. The description still adds value by insisting every request, purchase or refinance, carries the full street address (number, street, city, state, ZIP) and by establishing the option-label convention for referring to priced options in later calls — guidance that is not derivable from the schema.
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 specific verb and resource ("Request a written term sheet") and narrows the scope precisely: business-purpose loan, non-owner-occupied 1–4 unit investment property, emailed to the investor with a private download link. It also names the sibling instant_term_sheet_requirements, so an agent can distinguish the two tools without opening either schema.
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 gives a clear routing instruction ("Read instant_term_sheet_requirements first for the fields") and sets expectations about timing (instant where the deal fits, otherwise an answer within 24 hours). It stops short of explicit when-not-to-use exclusions in the description itself — the >4 unit hand-pricing rule lives only in the schema — so it is strong but not fully self-contained on alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
- Changed
request_instant_term_sheet1 field changed- changed
Input schema / properties / property / properties / acres / descriptionPrevious value: -"Optional: the lot size, in acres. Left out, the deal cannot be priced instantly."New value: +"Optional: the lot size, in acres. Left out, the property is taken to be on 10 acres or less, and the term sheet says so. Give it where the property is on more than 10 acres, or where the borrower is a foreign national, since some programs for foreign nationals cap the lot at 2 acres."
1 tool update
- Changed
request_instant_term_sheet1 field changed- changed
Input schema / properties / loan / properties / prepayStructure / descriptionPrevious value: -"Optional: the prepayment penalty's structure: fixed_5 (5% for the full term), fixed_3 (3% for the full term), declining (steps down over the term) or six_months_interest (six months' interest on the amount prepaid). Left out, the deal cannot be priced instantly."New value: +"Optional: the prepayment penalty's structure: fixed_5 (5% for the full term), fixed_3 (3% for the full term), declining (a penalty that declines over the term; the term sheet states how the lender that prices it calculates it) or six_months_interest (six months' interest on the amount prepaid). Left out, the deal cannot be priced instantly."
1 tool update
- Changed
request_instant_term_sheet3 fields changed- changed
Input schema / properties / loan / properties / prepayStructure / descriptionPrevious value: -"Optional: the prepayment penalty's structure: fixed_5 (5% for the full term), fixed_3 (3% for the full term), declining (steps down over the term) or six_months_interest (six months' interest on the amount prepaid). Ask the investor. Left out, the deal cannot be priced instantly."New value: +"Optional: the prepayment penalty's structure: fixed_5 (5% for the full term), fixed_3 (3% for the full term), declining (steps down over the term) or six_months_interest (six months' interest on the amount prepaid). Left out, the deal cannot be priced instantly." - changed
Input schema / properties / loan / properties / prepayTermMonths / descriptionPrevious value: -"Optional: the prepayment penalty term the investor wants, in months; 0 for none. One of 0, 6, 12, 24, 36, 48, 60. Ask the investor. Left out, the deal cannot be priced instantly."New value: +"Optional: the prepayment penalty term the investor wants, in months; 0 for none. One of 0, 6, 12, 24, 36, 48, 60. Left out, the deal cannot be priced instantly." - changed
Input schema / properties / property / properties / acres / descriptionPrevious value: -"Optional: the lot size, in acres. Ask the investor. Left out, the deal cannot be priced instantly."New value: +"Optional: the lot size, in acres. Left out, the deal cannot be priced instantly."
1 tool update
- Changed
request_instant_term_sheet1 field changed- changed
Input schema / properties / property / properties / county / descriptionPrevious value: -"Optional: the county's five-digit FIPS code. Where a program restricts counties or cities, a request without it is confirmed by hand."New value: +"Optional: the county's five-digit FIPS code. A county you give is the one used. Left out, it is read from the ZIP code in the address; where a program restricts counties and the ZIP code does not settle which county, a request without it is confirmed by hand."
1 tool update
- Changed
request_instant_term_sheet3 fields changed- changed
Input schema / properties / loan / properties / prepayStructure / descriptionPrevious value: -"Optional: the prepayment penalty's structure: fixed_5 (5% for the full term), fixed_3 (3% for the full term), declining (steps down over the term) or six_months_interest (six months' interest on the amount prepaid)."New value: +"Optional: the prepayment penalty's structure: fixed_5 (5% for the full term), fixed_3 (3% for the full term), declining (steps down over the term) or six_months_interest (six months' interest on the amount prepaid). Ask the investor. Left out, the deal cannot be priced instantly." - changed
Input schema / properties / loan / properties / prepayTermMonths / descriptionPrevious value: -"Optional: the prepayment penalty term the investor wants, in months; 0 for none. One of 0, 6, 12, 24, 36, 48, 60."New value: +"Optional: the prepayment penalty term the investor wants, in months; 0 for none. One of 0, 6, 12, 24, 36, 48, 60. Ask the investor. Left out, the deal cannot be priced instantly." - changed
Input schema / properties / property / properties / acres / descriptionPrevious value: -"Optional: the lot size, in acres."New value: +"Optional: the lot size, in acres. Ask the investor. Left out, the deal cannot be priced instantly."
1 tool update
- Changed
request_instant_term_sheet4 fields changed- added
Input schema / properties / borrower / properties / firstTimeHomebuyerAdded value: +{ + "description": "Optional: true where the borrower is a first-time homebuyer. Left out, the borrower is taken not to be one, and a term sheet that relies on that says so.", + "type": "boolean" +} - changed
Input schema / properties / dscrInputs / properties / monthlyRent / descriptionPrevious value: -"The property's gross monthly rent, in dollars: the lease, or the market rent."New value: +"The property's gross monthly rent, in dollars: the lease, or the market rent. For a short-term rental, the 12-month average gross monthly rent." - added
Input schema / properties / loan / properties / ownershipMonthsAdded value: +{ + "description": "Refinances only, optional: how many months the borrower has owned the property. Left out, it is taken as at least 6 months, and a term sheet that relies on that says so.", + "minimum": 0, + "type": "number" +} - changed
Input schema / properties / property / properties / rentalType / descriptionPrevious value: -"Optional: long_term for a lease, short_term for nightly or weekly rentals. Left out, the rent is read as long-term."New value: +"Optional: long_term for a lease, short_term for nightly or weekly rentals. Left out, the rent is read as long-term. For a short-term rental, give dscrInputs.monthlyRent as the 12-month average gross monthly rent."
1 tool update
- Changed
request_instant_term_sheet1 field changed- added
Input schema / properties / property / properties / vacantAdded value: +{ + "description": "Refinances only, optional: true where the property has no lease and no tenant. Left out, it is taken as rented, and a term sheet that relies on that says so.", + "type": "boolean" +}
2 tool updates
- First observed
instant_term_sheet_requirements - First observed
request_instant_term_sheet
Related MCP Connectors
Written fix-and-flip term sheets for 1–4 unit investment purchases, by email. Business-purpose only.
HMDA investor-lender data, DSCR glossary, loan programs and indicative rates. Business-purpose only.
Published terms of 13 investor lenders for 1-4 unit rentals, flips and builds, with a deal match.
Size and compare financing for 5+ unit apartment buildings: DSCR, LTV, cash-out, bridge takeout.
Related MCP Servers
- AlicenseAqualityCmaintenanceEnables AI assistants to calculate exact debt service coverage ratios, maximum loan amounts, required rent, scenario comparisons, and amortization schedules for rental property loans, returning structured results with sources and dates.5304 npmMIT
- AlicenseAqualityBmaintenanceMultifamily real estate deal analysis — analyze deals, score properties, calculate max offer prices, and look up market data. Four tools for underwriting 2-200 unit apartment properties.4144 npm4MIT
- AlicenseNot gradedqualityDmaintenanceBroker-only credit/lending discovery shim for AI agents, surfacing real lending markets from licensed/established third-party protocols and routing applications.MIT
- FlicenseAqualityCmaintenanceEnables mortgage risk assessment and underwriting by calculating DTI, LTV, credit risk, income stability, and asset sufficiency, and by aggregating these factors into a loan recommendation with conditions and compensating factors.6-
Glama MCP Gateway
Add one secure layer between your agents and this server.