Skip to main content
Glama

Tie out a DCF against another system's annual lines

calc_reconcile_dcf
Read-onlyIdempotent

Reconcile FactLot's DCF with another system's export (ARGUS or any other model; parity is not claimed and is untested against real ARGUS output): give the calc_dcf_pro_forma input plus the other system's annual lines {label, values: [year 1, …]}, optionally its value, unlevered IRR and sale price, a tolerance (absolute and relative) and your label mapping. Labels map to FactLot lines by your mapping, else by common CRE line names (Potential Base Rent, Absorption & Turnover Vacancy, Free Rent, Expense Reimbursements, General Vacancy, Credit Loss, Effective Gross Revenue, Operating Expenses, Net Operating Income, Tenant Improvements, Leasing Commissions, Capital Reserves, Cash Flow Before Debt Service); positive deductions are negated (sign_convention). Returns per line and year FactLot's amount, the other amount, the difference and whether it is within tolerance; unmapped labels; and for each differing line a likely_cause from FactLot's documented conventions, worded as a hypothesis to check: differences only in rollover years (fractional downtime and free rent), a rate on a different base (general vacancy), only the exit year, a one-year shift, management fee inside operating expenses, a growth rate, a constant factor or amount, rounding; and for the value FactLot rerun with mid-year or end-of-year discounting, the other exit NOI basis, or no selling costs. Deterministic: use this instead of doing the math yourself; cite formula calc.reconcile_dcf@1 and the returned steps, and surface any warnings.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "dcf": "<dcf>",
      "other": "<other>"
    },
    "name": "calc_reconcile_dcf"
  }
}

Input Schema

NameRequiredDescriptionDefault
dcfYesThe FactLot DCF input, exactly as calc_dcf_pro_forma takes it (the same rent roll and assumptions you entered in the other system).
otherYesWhat the other system reported for the same property.
mappingNoYour label mappings; they override the defaults (common CRE line names such as Potential Base Rent, General Vacancy, Net Operating Income, Cash Flow Before Debt Service).
toleranceNoWhen two amounts agree: |FactLot − other| ≤ max(absolute, relative × |other|); the IRR within irr. Default: 1.00 USD, 0, and one basis point.
sign_conventionNoFactLot reports deductions (free rent, vacancy, credit loss, expenses, fees, TI, commissions, reserves) as negative amounts. "auto": a deduction line whose amounts are all zero or positive is read as positive deductions and negated; "as_reported": compare as given; "deductions_positive": negate every deduction line.auto

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.5/5.0
Behavior5/5

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

With readOnlyHint, idempotentHint, and destructiveHint=false already supplied, the description adds substantial behavior: deterministic output, per-line/per-year comparison, unmapped-label reporting, hypothesis-style likely_cause values, value reruns with alternate discounting or exit NOI basis, and surfaced warnings. It also candidly states that parity is not claimed and is untested against real ARGUS output.

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

Conciseness3/5

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

The description is front-loaded with the core reconcile purpose, but it becomes a dense, run-on paragraph enumerating many line names and likely-cause categories. The information is useful, yet the wall-of-text format makes it harder to scan and some enumeration could be tighter.

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

Completeness5/5

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

For a complex reconciliation tool with no output schema, the description explains the expected return shape (per line and year, differences, tolerance status, unmapped labels, likely causes, value reruns, warnings). It gives enough context for an agent to call the tool correctly and interpret the result without needing an output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning about parameter interactions: label mappings override common CRE names, positive deductions are negated according to sign_convention, and optional value, IRR, and sale price are compared when supplied. It also clarifies that tolerance uses absolute and relative thresholds.

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?

The description opens with a specific verb and resource — reconciling FactLot's DCF against another system's annual lines — and names the exact input shape (calc_dcf_pro_forma input plus the other system's lines). It is clearly distinguishable from calc_dcf_pro_forma itself and from calc_reconcile_cam.

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?

It explicitly directs the agent to use this instead of doing the math manually and explains the conditions for using the mapping and sign conventions. It does not fully contrast itself with sibling comparison tools such as calc_compare_proposals, but the intended context is clear from the reference to calc_dcf_pro_forma.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.