Skip to main content
Glama

Run Report

run_report
Read-onlyIdempotent

Download any Rent Manager report.

format defaults to pdf. Available formats: pdf, xls, xlsx, excel (alias → xls), spreadsheet (alias → xls), csv, json, txt, html, xml. Rent Manager renders xls with better formatting (column widths, headers, group totals) than xlsx.

Output by format: • csv / json / txt / html / xml — small files (≤1 MiB) are inlined in the response in addition to being saved. • pdf / xlsx / xls — saved to the per-tenant file store and returned as a signed /files/<id>?sig=... URL.

The analyze_* wrappers return computed answers directly and are faster than raw reports; analyze_pl_trend runs the 12-month recap report, the default P&L / Profit and Loss / T12 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.)

``location`` (optional): a Rent Manager Location ID, a comma-separated
list, or ``"all"`` to run across every Location on this connection (see
``list_locations``). Blank = all Locations if the connection has several,
else its only Location. Output is labelled per Location; a Location that
can't be reached is listed as skipped. IDs (property, tenant, ...) belong
to one Location, so pass that Location when you filter by one.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "run_report"
  }
}

Input Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / location
      Added value: +{
      +  "default": "",
      +  "title": "Location",
      +  "type": "string"
      +}
  2. 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, so the bar is lower, yet the description still adds substantial behavior: per-format output routing (small csv/json/txt/html/xml inlined plus saved; pdf/xlsx/xls written to a per-tenant file store and returned as a signed /files/<id>?sig=... URL), that xls renders with better formatting than xlsx, and that unreachable Locations are reported as skipped. That is real operational context beyond the structured fields.

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?

Well front-loaded — purpose, then format defaults, then output routing, then ReportWriter caveats, then location — organized with bullets and bold labels. It is long and a few asides (the xls-vs-xlsx rendering rationale, the parenthetical 'the start_date/... args do NOT apply') could be tightened, but nearly every line carries decision-relevant information.

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?

For a 12-parameter tool with no output schema, the description covers the critical unknowns: what is returned per format, where files land, the two ID namespaces, and multi-location fan-out behavior. The remaining gap is only the handful of undocumented parameters and no mention of pagination or report size limits beyond the 1 MiB inline threshold.

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% across 12 parameters, so the description must carry the load, and it mostly does: format (with all aliases and default), report_writer, extra_params, start_date/end_date, property_id, portfolio, and location are all explained with semantics. However `combined`, `property_ids`, and `report_name` are never mentioned, leaving three of twelve parameters undocumented anywhere.

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.' It immediately distinguishes itself from the large analyze_* sibling family by explaining those return computed answers directly, and it names list_reports as the way to discover IDs. An agent can route to this tool without opening a 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?

Explicit when-to-use-this-vs-alternative guidance: prefer analyze_* wrappers for computed answers, with analyze_pl_trend named as the default P&L/T12 path. It also defines the exact condition that requires report_writer=True (IDs shown as kind 'rw' in list_reports(live=True)) and warns that start_date/end_date/property_id/portfolio do NOT apply to those reports.

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