Skip to main content
Glama
Sign In
jbechtel-97

dealflowpro-mcp-server

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

Score Multifamily Deal (Quick)

score_deal
Read-onlyIdempotent

Quick-score a multifamily deal on the DFP 0-100 scale. Returns the DFP Score and key metrics. Faster than full analysis — use this for quick screening.

Instructions

Quick-score a multifamily deal on the DFP 0-100 scale. Returns the DFP Score and key metrics. Faster than full analysis — use this for quick screening.

Input Schema

NameRequiredDescriptionDefault
unitsNoNumber of apartment units
assumptionsNoOnly the interest basis can be overridden on a quick score (it feeds IRR and cash-on-cash); use analyze_deal for other 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
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. Changed1 schema field changedv1.3.0
    • addedInput schema / properties / assumptions
      Added value: +{
+  "description": "Only the interest basis can be overridden on a quick score (it feeds IRR and cash-on-cash); use analyze_deal for other assumptions",
+  "properties": {
+    "interest-basis": {
+      "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"
+    },
+    "second-mortgage-interest-basis": {
+      "description": "Second mortgage interest basis, same values",
+      "enum": [
+        "365-360",
+        "30-360"
+      ],
+      "type": "string"
+    }
+  },
+  "type": "object"
+}
  2. Changed3 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"New value: +"Full street address. Drives the market data behind the DFP Score; without it the market component is understated."
  3. First observedv0.1.0

TDQS

A3.7/5.0
Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds that it returns a DFP Score plus 'key metrics' and that it is faster, but says nothing about how the confidence rating is affected, what 'key metrics' includes, or how missing optional data degrades the score.

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 short sentences, zero padding, with the core purpose and scale front-loaded and the speed/screening guidance last. Every sentence carries distinct information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 8-parameter tool with a nested assumptions object and no output schema, the description covers the headline return value but leaves 'key metrics' undefined and does not warn that omitting property_address understates the market component — a caveat that only appears buried in the schema. Adequate against a fully documented schema, but not complete on its own.

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%, so every parameter including the nested `assumptions` object is documented in the schema itself. The description adds no parameter-level meaning of its own (no mention of the required purchase_price/monthly_income pair or that property_address drives the market component), so the baseline 3 applies.

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 ('Quick-score a multifamily deal') plus the output scale ('DFP 0-100'), which is concrete enough to distinguish it from generic analysis tools. It differentiates itself from full analysis by calling itself 'quick', but never names the sibling `analyze_deal` that is the actual alternative.

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?

'Faster than full analysis — use this for quick screening' gives a clear usage context and implicitly routes deep work elsewhere. It never states an explicit when-not-to-use condition (e.g. when assumptions other than interest basis are needed, which the schema hints at via `analyze_deal`).

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