Skip to main content
Glama
Sign In
jbechtel-97

dealflowpro-mcp-server

by jbechtel-97
OverviewSchemaSourceRelated ServersDiscussions(1)Admin
JavaScript
Remote

Reverse-Calculate Max Offer Price

reverse_calc
Read-onlyIdempotent

Calculate the maximum offer price for a multifamily property by back-solving from target cap rate, cash-on-cash, DSCR, or IRR. Use when asked what to offer or what the max price is.

Instructions

Calculate the maximum offer price for a multifamily deal based on target return metrics. Back-solves from your desired cap rate, cash-on-cash, DSCR, and/or IRR to find what you should pay. Use this when someone asks 'what should I offer?' or 'what's the max price?'

Input Schema

NameRequiredDescriptionDefault
unitsNoNumber of apartment units
targetsYesTarget return metrics — provide at least one
scenarioNoDefaults to current: in-place numbers with DFP's default 7% vacancy. proforma applies forward-looking defaults (5% vacancy) and returns more favorable figures for the same deal. Pass it explicitly when comparing results.
assumptionsNoOverride default underwriting assumptions
monthly_incomeYesTotal monthly rental income in dollars
monthly_expensesNoTotal monthly operating expenses in dollars

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.4.0
    • addedInput schema / properties / targets / properties / price_per_unit
      Added value: +{
+  "description": "Maximum price per unit in dollars (e.g., 120000). Requires units.",
+  "type": "number"
+}
  2. Changed2 schema fields changedv1.3.0
    • addedInput schema / properties / assumptions / properties / interest-basis
      Added value: +{
+  "description": "First mortgage interest basis. 365-360: interest accrues at rate x 365/360 (commercial / agency convention); 30-360: every month counts as 30 days. Omitted: the account's Settings default",
+  "enum": [
+    "365-360",
+    "30-360"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / assumptions / properties / second-mortgage-interest-basis
      Added value: +{
+  "description": "Second mortgage interest basis, same values",
+  "enum": [
+    "365-360",
+    "30-360"
+  ],
+  "type": "string"
+}
  3. Changed1 schema field changedv1.2.9
    • addedInput schema / properties / scenario
      Added value: +{
+  "description": "Defaults to current: in-place numbers with DFP's default 7% vacancy. proforma applies forward-looking defaults (5% vacancy) and returns more favorable figures for the same deal. Pass it explicitly when comparing results.",
+  "enum": [
+    "current",
+    "proforma"
+  ],
+  "type": "string"
+}
  4. First observedv0.1.0

TDQS

A4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true and closed-world, so the safety profile needs no restating. The description adds only the general 'back-solves' framing; it does not disclose output shape, what happens when no target is reachable, or how conflicts among multiple targets are resolved — notable for a nested, constraint-solving tool.

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 sentences, front-loaded with the core purpose, then the mechanism, then the trigger phrasing. No filler and no repetition of the title.

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?

For a 6-param tool with a nested targets object, the description gives enough intent-level framing and the schema covers semantics in full. With no output schema, the description could say more about what comes back (e.g., a max price plus the binding constraint), which is the only real gap.

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%, including the nuanced 'at least one' constraint on targets and the scenario defaults, so the schema carries the parameter burden. The description repeats the target metric names but adds nothing about scenario, price_per_unit, or assumption overrides, so 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 and resource ('calculate the maximum offer price for a multifamily deal') and names the mechanism ('back-solves from your desired cap rate, cash-on-cash, DSCR, and/or IRR'). This cleanly separates it from sibling tools analyze_deal and score_deal, which read as forward analyses rather than a price solve.

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?

Gives concrete trigger phrases ('what should I offer?' / 'what's the max price?') that map an intent directly onto the tool. It stops short of naming alternatives or stating exclusions — e.g., when to prefer analyze_deal or score_deal instead — so it lands at 4 rather than 5.

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

Deploy Server

Other Tools