Skip to main content
Glama
Sign In
jbechtel-97

dealflowpro-mcp-server

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

Analyze Multifamily Deal

analyze_deal
Read-onlyIdempotent

Analyze a multifamily real estate deal. Returns cap rate, cash-on-cash, DSCR, IRR, DFP Score (0-100), max offer price, and full financial projections.

Instructions

Analyze a multifamily real estate deal. Returns cap rate, cash-on-cash, DSCR, IRR, DFP Score (0-100), max offer price, and full financial projections. Use this when someone asks about analyzing a property, evaluating a deal, or running the numbers on a multifamily investment.

Input Schema

NameRequiredDescriptionDefault
unitsNoNumber of apartment units
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.
year_builtNoYear the property was built
assumptionsNoOverride default underwriting assumptions
income_sourceNoWhere monthly_income came from, e.g. RentRoll, T12, OM, Screen. Raises the confidence rating on the result.
expense_sourceNoWhere monthly_expenses came from, e.g. T12, OperatingStatement, OM, Screen. Raises the confidence rating on the result.
monthly_incomeYesTotal monthly rental income in dollars
purchase_priceYesAsking/purchase price in dollars
monthly_expensesNoTotal monthly operating expenses in dollars (if omitted, 50% of income is assumed)
property_addressNoFull street address. Drives the market data behind the DFP Score; without it the market component is understated.

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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"
+}
  2. Changed4 schema fields changedv1.2.9
    • addedInput schema / properties / expense_source
      Added value: +{
+  "description": "Where monthly_expenses came from, e.g. T12, OperatingStatement, OM, Screen. Raises the confidence rating on the result.",
+  "type": "string"
+}
    • addedInput schema / properties / income_source
      Added value: +{
+  "description": "Where monthly_income came from, e.g. RentRoll, T12, OM, Screen. Raises the confidence rating on the result.",
+  "type": "string"
+}
    • changedInput schema / properties / property_address / description
      Previous value: -"Property location (city, state)"New value: +"Full street address. Drives the market data behind the DFP Score; without it the market component is understated."
    • 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"
+}
  3. First observedv0.1.0

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so side-effect concerns are covered. The description adds the return payload contents, which annotations cannot express, but says nothing about computation caveats (defaults applied silently, confidence rating, market data dependency) that a caller should know.

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

Conciseness4/5

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

Two compact sentences, front-loaded with purpose and outputs before the usage hint; there is no filler. The only marginal waste is the usage clause, which largely repeats the name.

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?

With 10 parameters, a nested assumptions object, and no output schema, the description does the important work of listing return values and framing the tool as a full underwriting run. It stops short of noting required inputs (purchase_price, monthly_income) or the confidence-rating mechanics, but an agent has enough to call it correctly.

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 nuanced documentation for scenario, interest-basis, and the expense default, so the schema carries the parameter burden. The description adds no parameter guidance of its own (e.g., which fields are required or how source fields affect confidence), making the baseline 3 appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Analyze a multifamily real estate deal') and enumerates the concrete outputs (cap rate, cash-on-cash, DSCR, IRR, DFP Score, max offer price, projections), which tells an agent what it gets back. It does not, however, differentiate itself from the sibling score_deal, which presumably also produces the DFP Score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The usage sentence gives trigger phrasings ('analyzing a property, evaluating a deal, running the numbers'), but those are essentially restatements of the tool name rather than real selection criteria. With siblings reverse_calc, market_data, and score_deal present, no exclusion or alternative routing is offered, so the agent must infer boundaries.

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