Skip to main content
Glama

Run Report

run_report
Read-onlyIdempotent

Download any Rent Manager report.

Format selection rules — IMPORTANT: • PDF is the default for downloads. If the user says "download the report", "send me the report", "give me a copy of X", "I want X for my records", or any similar phrasing without naming a format → leave format unset (defaults to pdf). • For ANY Excel-related request, use xls (NOT xlsx). This includes: "Excel file", "spreadsheet", "in Excel", ".xls", "Microsoft Excel", "give me an XLS", "Excel version", and any similar phrasing. Rent Manager renders xls with much nicer formatting (column widths, headers, group totals) than xlsx, so xls is the preferred Excel format for this product. • Only use xlsx when the user explicitly types "xlsx" — e.g. "download the P&L as xlsx" or "give me the .xlsx file". Any other Excel phrasing → xls. • csv (or json / txt / html / xml) only when the user wants to see the data in chat — those small text formats are inlined into the response so the model can read them directly. Phrasings like "show me", "display", "what's in X", "summarize X" → csv.

Available formats: pdf (default), xls, xlsx, excel (alias → xls), spreadsheet (alias → xls), csv, json, txt, html, xml.

Output behavior by format: • csv / json / txt / html / xml — small files (≤1 MiB) are ALSO inlined in the response so the model can read the contents directly. • pdf / xlsx / xls — saved to the per-tenant file store and returned as a signed /files/<id>?sig=... URL the user can click directly in chat.

For analytical questions prefer the analyze_* wrappers — they're faster and return computed answers directly. For any P&L / Profit and Loss / T12 request use analyze_pl_trend (12-month recap report, the default P&L view).

Custom ReportWriter reports: set report_writer=True to download a custom report from RM's ReportWriter (the IDs shown as kind "rw" in list_reports(live=True)). These live in a separate ID namespace that collides with the canned reports, so the flag is required to disambiguate. They carry their own saved filters and run portfolio-wide; pass any ad-hoc parameters via extra_params. (The start_date/end_date/ property_id/portfolio scoping args do NOT apply to ReportWriter reports.)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
formatNopdf
combinedNo
end_dateNo
portfolioNo
report_idNo
start_dateNo
property_idNo
report_nameNo
extra_paramsNo
property_idsNo
report_writerNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: output behavior differs by format (small text formats inlined vs pdf/xls/xlsx saved to file store and returned as signed URLs), and the ReportWriter flag lives in a colliding ID namespace that requires disambiguation. These are exactly the behavioral facts an agent could not infer.

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?

Front-loaded with a one-line purpose, then well-organized bulleted sections. It is long, but the format-ambiguity rules earn their space; a few format-rule restatements could be tightened.

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?

No output schema exists, and the description compensates by explaining return behavior per format. For an 11-param, 0%-coverage tool it covers the highest-risk decisions well, but under-documents the remaining scoping params (combined, property_ids, report_name).

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 0%, so the description must carry parameter meaning. It fully explains format values and aliases, report_writer, and extra_params, and warns that start_date/end_date/property_id/portfolio do NOT apply to ReportWriter. However, it never explains combined, property_ids, report_name, or report_id outside the RW context, leaving several of the 11 params undocumented.

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?

Opens with a specific verb+resource ('Download any Rent Manager report') and explicitly differentiates itself from the many analyze_* siblings by routing analytical/P&L questions to analyze_pl_trend and the analyze_* wrappers. An agent can tell what this does and what it is not for without opening the schema.

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

Usage Guidelines5/5

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

Gives explicit when-to-use rules (download vs in-chat viewing), names alternatives (analyze_* wrappers, analyze_pl_trend for P&L/T12), and provides detailed format-decision rules including the crucial xls-vs-xlsx distinction. Leaves little 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.

Resources