Skip to main content
Glama

Run report

run_report
Read-only

Preview an ANALYSIS or dashboard and return its rows or grouped aggregates: counts, sums, averages, grouping, trends, charts, or a multi-column table the user may want to keep as a View. For a plain LIST of records (open tasks, deals in a stage) call search_records with filters instead — lighter, exact-value, and it never refuses a spec. Pass report_id for a saved analysis/dashboard, or definition for an inline ReportSpec (object + columns + filters + group_by + aggregations; omit viz and the best fit is derived) or a composition (kind:"composition" — each panel has EITHER an inline spec OR source_view_id). A living window is an in_period filter from the closed set (today … this_quarter, overdue, upcoming) — never an invented period name; a fixed window uses gte/lt on the date field. Money comes back in minor units with no manual FX applied; never label a raw or mixed-currency aggregate as a converted total. run_report only PREVIEWS — it never saves. To keep one, the user clicks "Save as view" on the card, or you call create_record with object_type:"report" and data:{name,definition}; never tell the user a View is saved until a save has succeeded. Zero rows is an empty result — say so. When the user is REFINING an analysis or dashboard they already saved, pass its id as source_view_id with the refined definition so the save lands OVER the existing item instead of a twin. E.g. touches by type: {object:"touch",group_by:{ref:{kind:"field",field:"type"}},aggregations:[{fn:"count",alias:"n"}]}. For the full authoring guide (viz recipes, filter logic, related_filters, matrices, rates, dashboards, dashboard filters) read capable://guide/reports.

When to use: Counts, sums, grouping, trends, charts or a keepable table over workspace data; a plain list of records (open tasks, deals in a stage) is search_records. It previews only — nothing is saved until the user saves it or you create_record(report).

Example: Report total ARR by industry for current customers.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
report_idNoA saved analysis or dashboard's id (uuid), run with its stored definition; give this or definition — report_id wins when both are passed.
definitionNoAn inline ReportSpec (object, columns, filters, group_by, aggregations, viz) or a composition (dashboard) to preview; omit when passing report_id.
source_view_idNoId (uuid) of the saved View this inline definition refines, so a save updates it in place instead of creating a twin; ignored with report_id.
suggested_nameNoA name to seed the card's "Save as view" button, echoed as suggested_name; only meaningful with an inline definition (this call saves nothing).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
vizNo
kindNo
modeNo
noteNo
rowsNo
specNo
emptyNo
titleNo
deltasNo
layoutNo
objectNo
periodNo
columnsNo
widgetsNo
group_refNo
row_countNo
truncatedNo
board_groupNo
aggregationsNo
group_bucketNo
source_view_idNo
suggested_nameNo
group_ref_secondaryNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Adds substantial context beyond annotations: it only PREVIEWS and never saves, zero rows is an empty result, money returns in minor units with no FX applied, and the save-over-twin behavior with source_view_id. These are behavioral traits the readOnlyHint annotation does not convey.

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?

Dense but front-loaded: purpose and the search_records alternative come first, then parameter guidance, then the save caveat. Some sentences (e.g. the money/FX and the create_record save recipe) are long, but each earns its place by preventing a specific failure mode.

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 a 4-param, 0-required, deeply nested schema and an output schema, the description covers the selection decision, both input modes, the preview-only contract, the save path, refining-saved-items, and points to a guide URI for the rest. Nothing an agent needs to call it correctly is missing.

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 real meaning: report_id vs definition precedence, the inline ReportSpec shape (object+columns+filters+group_by+aggregations, viz optional), the in_period closed period set, and source_view_id refinement semantics. Goes beyond the schema text.

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 (Preview) and resource (analysis/dashboard, rows or grouped aggregates), and explicitly distinguishes itself from search_records by routing plain lists there. An agent can tell this apart from search_records and create_record without opening either 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 vs the sibling: 'For a plain LIST of records ... call search_records with filters instead — lighter, exact-value, and it never refuses a spec.' Also covers refinement flow via source_view_id and the save path. Alternatives and exclusions are named.

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