Skip to main content
Glama

RentRollAPI

by io.github.ekvanauk

extract_operating_statement

Read-only

Extract structured, verified data from a commercial real estate T12 / operating statement (trailing-twelve-month income and expense report; PDF, Excel .xlsx, or CSV; native or scanned). Returns property info, reporting months, and categorized line items (income, expenses, subtotals) with monthly values and totals, plus a deterministic verification report that reconciles row totals against monthly values and Effective Gross Income, Total Operating Expenses, and Net Operating Income against the underlying rows. Every field carries a status and confidence; uncertain fields are flagged, never silently guessed. Anonymous use is limited to 3 documents/day; pass an API key from rentrollapi.com via the X-Api-Key header for more.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fileNameYesOriginal file name including extension, e.g. 't12.pdf' — the extension guides format detection.
documentBase64YesThe operating statement document encoded as base64 (PDF, XLSX, or CSV bytes). Max 25 MB decoded.

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses that the tool returns a verification report with reconciliation logic, flags uncertain fields, and never silently guesses. It also mentions per-field status/confidence, which adds significant behavioral detail not present in annotations.

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?

The description is three dense, information-rich sentences. It front-loads the core purpose, then details the output and verification behavior, and finally covers usage limits. Every sentence earns its place with no redundancy or filler.

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?

Given that there is no output schema, the description fully explains the return value (property info, reporting months, categorized line items, verification report) and key behavioral aspects (status/confidence flags, no silent guessing). It also covers limitations and authentication, making it complete for an agent to decide on invocation.

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?

The input schema already provides 100% coverage with descriptions for both parameters, including the max size and format detection via fileName. The tool description adds little beyond this, only noting supported formats (PDF, XLSX, CSV) which is already implied by the schema. Baseline 3 is appropriate.

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 uses a specific verb ('Extract') and resource ('commercial real estate T12 / operating statement'), clearly distinguishing it from sibling tool extract_rent_roll. It also lists supported formats and the nature of the output, leaving no ambiguity about what the tool does.

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?

The description states the tool is for T12/operating statements, giving clear context for when to use it. It does not explicitly name the sibling tool as an alternative, but the resource type makes the distinction obvious. It also provides usage limits (3 documents/day anonymous) and guidance on how to increase them.

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

All RentRollAPI toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation5/5

The two tools target distinct document types: one for T12/operating statements and one for rent rolls. There is no overlap in purpose; an agent can easily select the correct tool based on the document at hand.

Naming Consistency5/5

Both tool names follow a consistent 'extract_' prefix followed by the document type noun. The pattern is uniform and predictable, making it easy to infer the tool's function from its name.

Tool Count4/5

With only two tools, the server is minimal but well-scoped for its stated domain of extracting data from commercial real estate documents. It covers the two most common document types; a third tool might be plausible but the count is not excessive or insufficient for a focused utility.

Completeness4/5

The server covers the two core document types in commercial real estate analysis (T12/operating statement and rent roll). Minor gaps could include lease documents or property financial summaries, but for the apparent purpose, the surface is reasonably complete with no dead ends.

Resources