Skip to main content
Glama

download_dataset

Read-only

Read one of Flexreport's versioned daily data feeds by date — the feeds and what each holds come from list_options("data_feeds"). Use it over explore_data_catalogue when one of those feeds answers the ask for a date or date range. RATE-LIMITED TO 3 CALLS PER WEEK per user (all datasets together, failed calls included): make ONE call with the narrowest dates, never test-fire it, never re-call because a result was trimmed, and never poll it from a dashboard — fetch once and embed the rows.

list_options("data_feeds") lists the feeds — free, no rate limit — each as
{dataset, description, returns, date_field, event_types}: `returns` is "rows" or
"download_links" (presigned URLs), `date_field` is the column the dates filter on,
and `event_types` the valid filter values (null = unsupported). This tool checks
`dataset` and `event_types` against that list before spending a download call. For
open-ended analysis ("why did X move") keep to explore_data_catalogue.

Sizing — always pass explicit ET dates, the narrowest that answer the request, and
widen only when the user asks ("this month", "since launch"): the week ahead for
forward-looking predictions; the most recent completed date for "how did it do"; one
business day for documents (nightly files land after the 22:00 ET build, so before
then the latest complete day is the previous business day). A range with nothing
published returns no rows, not an error.

Shaping, applied here to the one response:
- Every row carries `published_at`, the UTC time its file version was published —
  quote the result's `published_at` as the data's as-of.
- Document feeds (rows with `document_url` + `page_number`) come back ONE ROW PER
  DOCUMENT (page columns dropped, `pages_with_text` added); include_page_text=true
  returns the page rows with their full `content`.
- `download_links` feeds return links valid 12 HOURS: hand each `url` to the user as
  a link, never store it or inline the file.

Returns {dataset, start_date, end_date, bulk_download, latest_file_version, shape,
rows, row_count, truncated, published_at, notes}. `notes` lists what was left out
(pages collapsed, symbols filtered, rows truncated) — tell the user in one line.

Requires auth (your MCP client attaches the OAuth bearer automatically). Also counts
once against the plan's daily request quota.

Input Schema

NameRequiredDescriptionDefault
datasetYesA `dataset` from list_options("data_feeds") (free, no rate limit).
symbolsNoKeep only these tickers, e.g. ["SNOW"]. Applied to the response here (the feed itself has no symbol filter); not possible for `download_links` feeds.
end_dateNoLast date, inclusive, YYYY-MM-DD. Omit for start_date alone (one day).
max_rowsNoCap on rows returned (after filtering and collapsing); the result then carries row_count and truncated: true.
start_dateYesFirst date, inclusive, YYYY-MM-DD, on the feed's `date_field` (ET). Pick the narrowest window that answers the request.
event_typesNoNarrow to these event types, from the feed's `event_types` in list_options("data_feeds"). Omit for all; ignored by feeds whose `event_types` is null.
bulk_downloadNoTrue ignores the dates and returns EVERY published date. Only when the user explicitly asks for full history.
document_urlsNoDocument feeds only: keep only these documents (their `document_url`), e.g. to read one deck's pages.
include_page_textNoDocument feeds (one row per page) only. False (default) = one row per document, no text. True = one row per page with its full `content` — only when the user wants the text, and narrowed with symbols / document_urls.
latest_file_versionNoTrue (default) = newest file version per date. False = every version ever published — only for point-in-time / backtest questions ("what did the model say Monday morning?").

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=true, so the description carries most of the burden and does so richly: a hard rate limit of 3 calls/week including failed calls, 12-hour presigned link validity, document feeds collapsing to one row per document, published_at as-of semantics, `notes` reporting omissions, and OAuth/quota side effects. This is far beyond what structured fields 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?

The text is long, but it is front-loaded with purpose and the critical rate limit, then organized into labeled sections (Sizing, Shaping, Returns) with a bulleted constraint list. For a 10-parameter tool with a hard weekly quota, nearly every sentence earns its place; the density is justified rather than padded.

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?

Despite no output schema, the description spells out the return shape ({dataset, start_date, end_date, bulk_download, latest_file_version, shape, rows, row_count, truncated, published_at, notes}), what `notes` contains, and how to surface it. Auth requirements, rate limits, and quota accounting are all covered, leaving nothing an agent needs to invoke the tool correctly.

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 the schema already documents all 10 parameters. The description still adds meaning the schema doesn't: `date_field` determines what dates filter on, include_page_text is only for page-level reads narrowed by symbols/document_urls, bulk_download is full-history only, and symbols is impossible for download_links feeds. It goes beyond the baseline 3 without fully compensating for anything missing, since the schema already covers syntax.

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 opens with a specific verb+resource: 'Read one of Flexreport's versioned daily data feeds by date.' It immediately names list_options("data_feeds") as the source of valid feeds and explicitly contrasts itself with explore_data_catalogue, so an agent can distinguish it from siblings 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?

Usage is fully routed: use this over explore_data_catalogue when a feed answers a date/date-range ask, and keep to explore_data_catalogue for open-ended analysis ('why did X move'). It also gives sizing heuristics (week ahead for predictions, latest completed date for 'how did it do', one business day for documents) and explicit anti-patterns (never test-fire, never poll).

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