Skip to main content
Glama

get_user_dataset_file

Read-only

Read the rows of one of the user's saved datasets AS PUBLISHED — the file behind its latest_url, or a dated version. THIS is how a dashboard or an answer reads a dataset: the published file is reviewed at publish, point-in-time, and the same bytes every consumer gets. Never replay the dataset's saved query instead (run_saved_query re-runs live SQL: different rows, no review). A claude.ai artifact can't reach flexreportfinapi.com itself, so its page calls this tool.

Fetches the file server-side and parses json, jsonl, csv, tsv, xml, rss and atom files
into rows; rss/atom come back one row per item {title, link, description, pub_date,
guid, categories, company_symbols, research_url}. `research_url` (every format, rows
with a ticker) is the feed readers' research link: show it as part of the item, but
never fetch it or offer it as a way to download a report (get_latest_report is the
user's route). parquet and xlsx files can't be parsed here: give the user latest_url
instead.

Returns {dataset_name, format, version, published_at, row_count, rows}. Quote
`published_at` as the data's as-of. A file over the server's size cap errors instead
of returning — use the user's own reader on latest_url for that one.

Requires auth (your MCP client attaches the OAuth bearer automatically).

Input Schema

NameRequiredDescriptionDefault
versionNoOmit for the newest file. Else a build date (YYYY-MM-DD, its newest file) or a file's exact `published_at` from list_user_datasets.
dataset_nameYesThe dataset's `name`, as list_user_datasets shows it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Beyond readOnlyHint, the description discloses parsing behavior for json/jsonl/csv/tsv/xml/rss/atom, rss/atom row shape, research_url handling, unsupported parquet/xlsx behavior, size-cap errors, return fields, and auth requirements. These are meaningful operational details an agent needs before invoking the tool.

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 description is front-loaded with its core purpose and alternative, then layers in format and error behavior. It is longer than a simple read tool needs, but the added detail is mostly functional rather than redundant.

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?

There is no output schema, but the description compensates by listing the return fields and explaining special cases such as rss/atom rows, unsupported formats, and oversized files. Given the tool's complexity and read-only annotation, the definition is complete enough for correct agent use.

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 coverage is 100%, so both parameters are already documented in the input schema. The description reinforces version behavior and dataset-name usage but does not add substantial syntax or format details beyond the schema.

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: reading the rows of a saved dataset as published, including latest_url or a dated version. It explicitly distinguishes this from run_saved_query, which re-runs live SQL and produces different rows without review.

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 gives explicit routing guidance: use this tool to read the published file, never replay the saved query instead, give latest_url for parquet/xlsx, and use get_latest_report as the user's route for reports. The alternatives and exclusions are unambiguous.

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