The fast path is `get_latest_report([ticker])`: a symbol with a fresh saved report
plan comes back under `rendering` and is rendered into the user's template in
~10-20 s; any other symbol comes back with its cached PDF and a `stale` flag. This
tool re-runs the whole pipeline — brief, query planning, SQL, formatting — so it
is for rebuilds only, in one of two modes:

STANDARD (ticker only, ~10 min): rebuilds the symbol's report plan from its latest
event and SAVES it, so later `get_latest_report` calls render it in seconds. Call it
ONLY after `get_latest_report` returned the ticker with `stale: true` or in
`missing`, and the user wants the rebuilt report rather than the cached one — tell
them it takes ~10 minutes before you start it. NEVER for a symbol that came back in
`rendering` (that render already is the fresh report), and never fanned out across a
list of names.

CUSTOM (`user_override=true` + the shaping fields, ~10 minutes, NOT saved): a full
build from scratch around named line items, ratios, segments, indicators,
estimates, or holders. Bespoke asks usually do NOT belong here. The better route for
"a report on X covering Y":
  1. EXPLORE the items the user named — `list_saved_queries` first, then
     `explore_data_catalogue` (after `situate` when the ask is event-driven);
  2. IDEATE with the user over the result sets — what to keep, cut, add, compare;
  3. OVERLAY the agreed results into their template — `get_user_template` returns
     the markup to lay the content out in with your own document tooling (no
     template saved -> offer `draft_user_template`).
That is faster, iterative, and the user sees the data before it is set in a PDF.
Use CUSTOM mode only when the user explicitly wants the Flexreport pipeline's own
report rebuilt around those items and accepts the ~10 minute wait. Every parameter
after `user_override` shapes a custom report, and the backend rejects it (422)
without `user_override=true` — this tool sets the switch for you whenever any of
them is non-empty, so a shaped request is never silently served the standard
report. Each parameter's description names its vocabulary — never guess, look
each one up.

Event context is SERVER-owned: the backend reads the symbol's latest platform event
and frames the report around it. There is no thesis / change-summary / include_* /
price-date field any more — do not send editorial steer; unknown keys are ignored.

CHOOSING THE SHAPING FIELDS FROM THE ONTOLOGY (custom mode only — do not guess):
read get_company_event_web(ticker) for the latest node, then
get_event_ontology(event_type=node.type), and derive from the card's family and
`informs`:
  earnings family          -> financial_items + estimate_items from the fundamentals
                              and estimates families the card informs; add
                              include_as_report_financials when the user wants the
                              filed statement (a 10-Q / 10-K anchored event)
  institutional_ownership  -> institutional_ownership CIKs from the web node's
                              fetch.cik (a 13F node is FILER-scoped: one filer's
                              move across several names)
  market_movement / news   -> technical_analysis_items from the technical_indicators
                              family (validate names via list_options)
  analyst_activity         -> estimate_items + ratios
Omit anything the ontology gives no reason for.

Not `generate_research_report`: that answers an open-ended or multi-company
question (peer comps, a theme). This tool is one ticker — and in custom mode, a
very clear list of what to cover.

Asynchronous. Returns {"<TICKER>": {"task_id": "...", "status": "PENDING"}}: read
result[ticker]["task_id"] and poll it with `get_task_status` until SUCCESS; the
result carries the finished report as {"pdf": "<base64>", ...}. Requires auth
(your MCP client attaches the OAuth bearer automatically).