Flexreport Finance

list_user_datasets

Read-only

List the user's own saved datasets (from save_user_dataset) with their build status and download links to the published files.

New items are reviewed before publishing, up to 40 per build (on a large first build
the rest publish as queried and are reviewed on later builds; a failed review publishes
the items as queried). The review can correct text from stored sources, add a one-line
caveat, or hold an item out; links, GUIDs, tickers and dates are never changed. So a
file can hold fewer rows than the query returns, and an item already published
unreviewed can later be corrected or withdrawn.

Returns {count, datasets: [{name, user_request, output_schema, file_format,
date_mode, cron, task_name, last_built_at, last_build_status, last_row_count,
latest_url, files: [{run_date, published_at, url}]}]}. `latest_url` is the fixed,
sign-in-free link to the newest file — the one to give for "what's my feed URL?" (an rss
file's items carry <company:symbol> and <category> for syndication partners). To read a
file's rows (a dashboard, a summary), call get_user_dataset_file. Rows with a symbol or
ticker carry `research_url`, the feed readers' sign-in-free research link — never call
it or offer it as a download (the user's own reports come from get_latest_report).
`last_build_status` is written,
unchanged (same rows as the last file, so no new file), empty, too_large (over 500k
rows), schema_drift (columns no longer match the saved schema — re-draft and re-save
under the same name) or failed.

Each file `url` is a presigned link valid 12 HOURS: hand it to the user as a link; never
fetch the file into the chat or store the link. Not rate-limited beyond the plan
quota. Requires auth (your MCP client attaches the OAuth bearer automatically).

Input Schema

Name	Required	Description
`end_date`	No	Last build date (YYYY-MM-DD, ET) of the files to list.
`start_date`	No	First build date (YYYY-MM-DD, ET) of the files to list.
`latest_only`	No	True (default) = newest file per build date; false = every version.
`dataset_name`	No	One dataset by name; all of the user's when omitted.

Output Schema

Name	Required	Description	Default
`count`	Yes
`datasets`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 20, 2026

addedOutput schema / $defs / UserDataset / properties / latest_url

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Fixed, sign-in-free link to the newest file; 404 until the first build.",
+  "title": "Latest Url"
+}

AddedOct 20, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond readOnlyHint=true, the description discloses substantial operational behavior: the review/publishing caveats, what each build status means, that file URLs are presigned and valid for 12 hours, that links must not be fetched into chat, auth requirements, and plan-quota-only rate limiting. This is exactly the kind of context annotations cannot carry.

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?

The purpose is front-loaded in the first sentence, and the remaining paragraphs are organized around output shape, link handling, and build statuses. It is longer than strictly necessary for a list tool and repeats the return shape even though an output schema exists, but the extra detail is largely substantive rather than rambling.

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 the tool's complexity, 4 fully documented parameters, existing annotations, output schema, and the unusual publishing-review behavior, the description covers everything an agent needs to call it correctly. No meaningful gaps remain for selection or 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?

Schema description coverage is 100%, so start_date, end_date, latest_only, and dataset_name are already fully explained in the input schema. The description does not add syntax or format details for these parameters beyond the schema, so the high-coverage baseline of 3 applies.

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 states a specific verb and resource: 'List the user's own saved datasets (from save_user_dataset) with their build status and download links.' It explicitly ties the tool to save_user_dataset and later names get_user_dataset_file as the tool for reading rows, so an agent can distinguish it from adjacent dataset siblings 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?

It provides explicit routing: use get_user_dataset_file to read a file's rows, give latest_url for 'what's my feed URL?', never call or offer research_url as a download, and use get_latest_report for the user's own reports. These are concrete when-to-use and when-not-to-use alternatives, not just implied context.

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

All Flexreport Finance 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?