draft_custom_dataset
Read-only
EVENT/NEWS FEEDS (filings, decks, earnings, news) — RESEARCH FIRST, then draft: 1) situate(event_types=[the feed's event types]) — or situate(question=<the user's words>) — then get_event_ontology(event_type=...) for each to learn where it persists (persisted_in); 2) agree definitions with the user before drafting — universe, window, and what any loose term means (e.g. the proxy for "the AI trade"); 3) ONE SCOPED explore_data_catalogue census of company_event_node for the universe and window (tickers, dates, a row limit in the wording); 4) draft a request naming the table and column for each field, e.g. title from earnings figures, body from eight_k_timeseries_analysis.summary, link sec_link, guid company_event_node.node_id, pub_date occurred_at, ticker symbol_metadata.exchange || ':' || symbol; 5) refine with previous_draft_id + feedback, asking for ONE candidate when variants don't matter. PLAIN DATA FEEDS ("daily close and 20-day volume for AAPL, MSFT") skip all this and draft directly.
RESEARCH REPORTS ARE IN EVERY FEED BY DEFAULT: the build adds a `research_url` column to every row with a `symbol` or `ticker` column — a fixed, signed, sign-in-free link that serves the research report PDF behind that item (rss/atom items show it as a "Research" link). Don't put report links or /get-cached-reports in the request or in a column; just keep a bare `symbol` (or `ticker`) column in the draft (a company_symbol / EXCHANGE:TICKER column alone gets no research link). That link is ONLY for the feed's readers (redistribution): never call it, build one, or offer it as a way to download a report — the user gets reports through get_latest_report, and Flexreport's daily files through download_dataset.
Drafts the user's OWN dataset — a table built from Flexreport data on a schedule and published as a file (parquet, csv, tsv, json, jsonl, xlsx, xml, or an rss/atom feed) behind a fixed link — from a plain-English description. Step 1 of 2: draft (and refine) here, then save_user_dataset schedules it. Use when the user wants a custom data feed or a recurring file of their own ("build me a daily file of...", "an RSS feed of...", "a JSON feed I can poll"); for Flexreport's published feeds use download_dataset, and for a one-off look at the data use explore_data_catalogue. This is THE tool for any request worded as a "datafeed" or "feed" — never substitute schedule_task, an emailed workflow or a one-off file. Every column comes from stored data, and that includes the summaries and analysis Flexreport already stores (deck, press-release and 8-K summaries, key figures, flags, recommendations, research views), so a feed with summary columns is still a dataset; only new written analysis generated fresh each run is a schedule_task workflow (a transform step).
Asynchronous: returns {draft_id, task_id, status: "PENDING"}. Poll task_id with
get_task_status until SUCCESS — a draft takes about 45 s-4 min (validation, planning, a
sample run, finalize). On SUCCESS `result` is:
{draft_id, validation_status: "OK" | "REJECTED", reason?, suggested_alternative?,
user_request,
candidates: [{name, description, columns, row_count, sample_rows, query_token,
has_fixed_dates, suggested_date_mode}]}
REJECTED -> relay `reason` and `suggested_alternative`; don't retry blindly.
Show the user each candidate's description, columns, row_count and a few sample_rows
and let them pick one. NEVER show `query_token` — it is an opaque sealed query whose
only use is save_user_dataset — but keep the chosen candidate's for the save.
- Samples show datetime columns as dates only; the built file keeps the full
timestamp, so never tell the user a timestamp is missing from a sample.
- Candidates can be near-identical: compare their descriptions, not just the samples.
Pass `target_format` when the user has named one (always for rss/atom). A candidate
with a column named `published_at` can't be saved (that name is reserved for the
build time): refine it with feedback asking to rename the column.
To refine, call again with the SAME `request`, previous_draft_id=<draft_id> and
`feedback`; ask for "ONE candidate" when the variants don't matter. Each round is a
new draft with its own draft_id. Ask before saving: name,
schedule, and (if not the suggestion) date mode.
Rate-limited to 20 drafts per hour per user. Requires auth (your MCP client attaches
the OAuth bearer automatically).
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes | The dataset to build, in plain English — what rows, which columns, which names, what window (e.g. "daily close and 20-day average volume for AAPL, MSFT, NVDA over the last 3 months"). When refining, re-send the same request. | |
| feedback | No | What to change about the previous draft, e.g. "add the 50-day average", "weekly instead of daily". Only with previous_draft_id. | |
| sample_rows | No | Rows of each candidate returned as a sample (at most 5). | |
| target_format | No | The format the user plans to save in. rss/atom make the planner shape one row per feed item (title, link, description, pub_date, guid), newest first. Omit when unknown. | |
| previous_draft_id | No | draft_id of an earlier draft to refine (with `feedback`); the planner sees that draft's queries. |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
| queue | No | Worker queue the draft was routed to. | |
| status | Yes | PENDING on dispatch. | |
| task_id | Yes | Poll this with get_task_status until SUCCESS (same value as draft_id). | |
| draft_id | Yes | The draft's id: pass to save_user_dataset, or as previous_draft_id to refine it. |