Skip to main content
Glama

Spread an operating statement

doc_spread_statement
Read-onlyIdempotent

Spread a T-12, operating statement, budget or rent roll summary YOU read, onto FactLot's published chart of accounts (multifamily, commercial, or hotel after the USALI summary), deterministically; FactLot runs no model. Send the pages as text and one line per item: {label, amount, quote, page}, optionally your category, a period column, and for a subtotal the indexes of the lines it sums; give the statement's own totals (effective_gross_income, total_operating_expenses, net_operating_income, ebitda, ...) as lines with that total as category. Each line is checked: the quote is on the page (a quote under 12 characters, such as a short row, only where it stands as whole words), the amount (as a number, any common written form; (1,200) and -1,200 read as negative) and the label are written in it; a line that fails is excluded with the reason, and a stated total that does not foot names the lines left out. The label is mapped to the chart by keywords: your category is used when it is in the chart, and an exception flags it for review when the dictionary maps the label elsewhere; an ambiguous or unknown label without a category is excluded. Vacancy, concessions, credit loss and other contra lines are always subtracted. Returns per period the sections, the computed totals (EGI, operating expenses, NOI, capital items, net cash flow; for hotels departmental profit, GOP, EBITDA and NOI after the replacement reserve), whether each total and subtotal the statement states foots (within 0.5 per line added, or your tolerance), every line with its citation (document, page, quote, span) and status, statistics (units, occupancy, ADR), and exceptions to review. Not checked: whether the agent missed lines, and meaning beyond the written amount and label.

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": {
      "document": "<document>",
      "property_type": "<property_type>",
      "lines": "<lines>"
    },
    "name": "doc_spread_statement"
  }
}

Input Schema

NameRequiredDescriptionDefault
linesYesThe statement's lines as you read them: every income, expense and capital line, the statement's own subtotals (with sums) and totals (with a total category), and statistics such as units or occupancy.
periodNoDefault period label for lines that give none.
documentYesThe statement's pages.
toleranceNoLargest difference, in the statement's units, at which a subtotal or total still foots. Default: 0.5 for each line added (rounding).
property_typeYesWhich chart of accounts to use: multifamily, commercial (office, retail, industrial), or hotel (USALI summary).
statement_typeNoWhat the document is; echoed back.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / lines / items / properties / quote / description
      Previous value: -"Verbatim text from the page with the label and the amount, e.g. \"Real Estate Taxes 245,000\"."New value: +"Verbatim text from the page with the label and the amount, e.g. \"Real Estate Taxes 245,000\". A row shorter than 12 characters (\"R&M 310,411\") is accepted where it appears on the page as whole words."
  2. Added

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only declare read-only/idempotent; the description adds substantial behavior: per-line quote/amount/label verification, exclusion with reason, contra lines always subtracted, keyword mapping plus exception flagging for conflicting categories, footing checks with a 0.5-per-line tolerance, and the full return contents. It also states explicitly what is NOT verified.

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?

Front-loaded with the verb and the outcome, and nearly every clause carries real information, but it is delivered as one dense semicolon-chained paragraph of ~250 words. The validation, mapping, return-value and non-verification content would be far more usable split into short labelled sections.

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 nested-input tool with no output schema, the description covers the input authoring rules, mapping behavior, what is returned per period including hotel-specific totals, and the explicit non-guarantees. An agent has enough to call it correctly and interpret the result.

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 baseline is 3, but the description adds procedural meaning not in the schema: the one-line-per-item shape {label, amount, quote, page}, how to encode the statement's own totals as lines with a total category, the sub-12-character quote rule, and parenthesized negatives. Minor gap: tolerance and period precedence are only partly re-explained.

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 (spread), specific resources (T-12, operating statement, budget, rent roll summary) and a specific target (FactLot's published chart of accounts per property type). It also distinguishes itself from model-based siblings by stating 'FactLot runs no model' and 'deterministically'.

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?

Clear about the precondition — the agent must have read the document and supply lines with quotes — and about limits ('Not checked: whether the agent missed lines'). It gives no explicit when-not or named alternatives among the doc_* / fact_* siblings, so routing between it and, e.g., doc_verify_facts is left to inference.

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.