Azquo

Run report

get_report_data

Fetch the full data for a report, including all regions and current choice values.

Reports in Azquo are Excel-based templates with named data regions. Each region contains row/column headings and a 2D array of values. Reports also support 'choices' — named parameters that filter the data (e.g. selecting a business unit, time period, etc).

Use it to see what a report shows a user - the figures as laid out in the report. For an ad-hoc question that no report answers, use query_aql; to see a report's formulas and layout rather than its data, use read_workbook. Find reports with list_reports (or list_database_sheets for one database).

Pass reportId as either a numeric ID or the report name. The database parameter is required. Any additional choices can be passed as key/value pairs. Choices are SAVED as this user's selections, as when they are picked in the report in a browser, so they also apply to the next run of any report using the same choice. A choice passed as "" clears the saved selection; leave a choice out to keep it as it is.

Example choices: { "Month": "Jan-24", "Department": "Sales" }

The result includes browserLink: a one-use link (10 minutes) that opens this report in the person's browser ALREADY SIGNED IN as this same user, with the choices just made, where they can change them. Give it to the person when they want to see the report; run again for a fresh one. Do not give any other address for the report - a plain address makes them sign in again, and they may land as another login of theirs, whose saved choices differ.

A library report (library: true in list_reports) runs read-only on its azquo_library database: pass that database's name; nothing is saved. open_in_browser shows it read-only. Its result carries libraryCopy: offer the person early to copy the database (copy_from_library) so it is theirs on admin.azquo.ai.

A choice value must be one of the options the report offers for it (choices in the result; run once without choices to see them): any other value is refused with invalid_choice, listing the options, and the saved choices are put back as they were. When a data region could not be filled the result STARTS with a warning and lists errors: the figures are blank or incomplete - do not present them as the report; tell the person what went wrong.

Errors report_not_found when the report does not exist or is not one this user may run, and report_render_failed when the report cannot be calculated.

Input Schema

Name	Required	Description
`choices`	No	Optional choice parameters to filter report data, e.g. { Month: 'Jan-24' }. Saved as the user's selections; "" clears one
`business`	No	Optional. The business this call is for, by name, e.g. "azquo" - it then runs there whatever business the session is in. Worth giving on writes when you work in more than one business: a new MCP session starts in the login's own business. list_businesses shows the names.
`database`	Yes	Database name to run the report against - usually the database list_reports shows for it
`reportId`	Yes	Report ID (number) or exact report name (string), from list_reports, e.g. 17 or "Monthly Sales"

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 21, 2026

addedInput schema / properties / business

Added value: +{
+  "description": "Optional. The business this call is for, by name, e.g. \"azquo\" - it then runs there whatever business the session is in. Worth giving on writes when you work in more than one business: a new MCP session starts in the login's own business. list_businesses shows the names.",
+  "type": "string"
+}

Changed3 schema fields changedOct 20, 2026

changedInput schema / properties / choices / description

Previous value: -"Optional choice parameters to filter report data, e.g. { Month: 'Jan-24' }"New value: +"Optional choice parameters to filter report data, e.g. { Month: 'Jan-24' }. Saved as the user's selections; \"\" clears one"

changedInput schema / properties / database / description

Previous value: -"Database name to use for this report"New value: +"Database name to run the report against - usually the database list_reports shows for it"

changedInput schema / properties / reportId / description

Previous value: -"Report ID (number) or report name (string)"New value: +"Report ID (number) or exact report name (string), from list_reports, e.g. 17 or \"Monthly Sales\""

First observedOct 19, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations mark the tool as non-read-only and non-idempotent, but the description adds crucial side-effect details: choices are saved as the user's selections and affect future runs, empty string clears a saved choice, omitted choices persist, and invalid values restore saved choices. It also discloses one-use browserLink behavior, library read-only behavior, warnings for incomplete data, and specific error outcomes.

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 long but front-loaded and well structured: purpose first, then sibling alternatives, then parameter semantics, then behavioral caveats. Every section adds operational value for a complex report-runner, with no wasted 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 no output schema and a complex tool that mutates saved choices, returns a browserLink, and has library and error behaviors, the description is complete enough for correct invocation. It covers return-adjacent context like browserLink, libraryCopy, validation failure, and render errors.

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?

Schema description coverage is 100%, so the schema documents all four parameters in detail. The description reinforces required database, reportId as numeric ID or name, and choice key/value semantics, especially save/clear/omit behavior, but much of this is also present in the schema. Baseline 3 is appropriate because the schema does most of the heavy lifting.

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 and resource: fetches full report data including regions and current choices. It explicitly distinguishes this from sibling tools such as query_aql, read_workbook, list_reports, and open_in_browser, so an agent can select it without opening schemas.

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 guidance and names alternatives with selection conditions: query_aql for ad-hoc questions, read_workbook for formulas/layout, list_reports to find reports. It also explains the special library-report path and read-only behavior.

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

All Azquo tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?