Skip to main content
Glama

generate_report_for_stock

Write a NEW research note for ONE ticker, now (a few minutes). Never the first call.

The fast path is `get_latest_report([ticker])`: every material event already writes
the symbol's report as it happens, so it usually exists and comes back in seconds
with a `stale` flag. This tool writes a new one on demand: the platform's analyst
researches the symbol's latest episode with its own tools (event web, intraday
tape, technicals, situate, at most one data exploration), states the platform's
official stance, and writes the note. The note REPLACES the symbol's report: later
`get_latest_report` calls return it, and `report_plan` subscribers are notified when
it lands. Two modes:

STANDARD (ticker only): call it ONLY after `get_latest_report` returned the ticker
with `stale: true` or in `missing`, and the user wants a current report rather than
the cached one — tell them it takes a few minutes before you start it. If
`latest_event_at` is only minutes old, that event's own report is probably still
being written: wait for its `report_plan` frame (or call get_latest_report again in
a few minutes) instead. Never fan it out across a list of names.

CUSTOM (`user_override=true` + the shaping fields, a few minutes; like STANDARD it
replaces the symbol's report): the same note, told to cover 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 note written
around those items and accepts the few-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 (a few
minutes). The task result is the note's saved plan, NOT the PDF: on SUCCESS call
get_latest_report([ticker]) for the document (it comes back `stale: false`). With a
`report_plan` subscription open, the ticker's frame says the same without polling.
Requires auth (your MCP client attaches the OAuth bearer automatically).

Input Schema

NameRequiredDescriptionDefault
ratiosNoEDGAR ratios ("grossProfitMargin") from list_options("financial_ratios").
tickerYesThe ONE ticker to write a new note for, e.g. "SNOW".
user_overrideNoCUSTOM mode switch (steer the note toward the shaping fields; it still replaces the symbol's report). Set automatically whenever any shaping field is non-empty.
estimate_itemsNoEstimate line items to compare against actuals.
financial_itemsNoStandardized EDGAR line items ("revenue", "operatingIncome") from list_options("financial_items").
revenue_segmentNoThe filer's revenue segments ("Product revenue") from list_options("revenue_segments", ticker=...).
as_reported_periodsNoWindow(s) the as-reported section shows: "quarter" (discrete three months, the default), "ytd" (cumulative), "annual" (fiscal year, from the 10-K). Several render as adjacent columns. Not cosmetic: a filing states the same concept over more than one window at the SAME period end, so the basis must be explicit.
institutional_ownershipNoManagers to feature, by SEC CIK (any width; the backend pads to 10 digits). Get them from list_options("institutional_managers", q="berkshire") -> {cik, name, category, aum}; pass the `cik` values, never names.
technical_analysis_itemsNoIndicators to chart ("rsi", "macd") from list_options("technical_indicators").
as_reported_financial_itemsNoThe filer's OWN tagged XBRL concepts ("us-gaap_RevenueFromContractWithCustomer...", or a company extension such as "snow_...") from list_options("as_reported_items", ticker=...).
include_as_report_financialsNoAdd an AS-REPORTED statement section built from the SEC filing itself: every figure a tagged XBRL fact deep-linked to its location in the filed document (distinct from the standardized tables, whose derived figures no filer states). Line items come from `as_reported_financial_items` when given, else are chosen to match the narrative.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / ticker / description
      Previous value: -"The ONE ticker to rebuild, e.g. \"SNOW\"."New value: +"The ONE ticker to write a new note for, e.g. \"SNOW\"."
    • changedInput schema / properties / user_override / description
      Previous value: -"CUSTOM mode switch (build around the shaping fields, not saved). Set automatically whenever any shaping field is non-empty."New value: +"CUSTOM mode switch (steer the note toward the shaping fields; it still replaces the symbol's report). Set automatically whenever any shaping field is non-empty."
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=false / destructiveHint=false; the description carries the rest and then some — the note REPLACES the symbol's report and triggers `report_plan` subscriber notifications, the call is asynchronous returning a task_id that must be polled to SUCCESS, latency is minutes, a 422 is returned for shaped requests without user_override, unknown keys are ignored, and OAuth auth is required.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The two opening sentences are well front-loaded, but the body runs ~600 words with repetition: "a few minutes" appears three times, the report-replacement consequence is stated twice, and the explore/ideate/overlay detour is a full alternative workflow argued at length. Capped section headers help navigation but the definition is over-stuffed for an 11-param tool.

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?

Covers everything an agent needs for a complex async mutation: preconditions, the replacement side effect, the exact return shape and how to read it (result[ticker][task_id] → get_task_status → get_latest_report for the PDF, not the task result), the subscription shortcut, auth, and the fact that event context is server-owned with no editorial fields. The output schema is also present, so return values need no further prose.

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% and each parameter description already names its `list_options` vocabulary, so much of the parameter discussion restates structured data. The genuinely additive part is the ontology-driven derivation (earnings family → financial_items + estimate_items; institutional_ownership → CIK from fetch.cik; analyst_activity → estimate_items + ratios) and the auto-set user_override rule, which an agent could not infer from 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?

Opens with a specific verb+resource+scope: "Write a NEW research note for ONE ticker, now (a few minutes)." It explicitly distinguishes itself from both relevant siblings — `get_latest_report` (the cached fast path) and `generate_research_report` (open-ended/multi-company) — so an agent can route correctly without opening any 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?

Gives hard preconditions ("Never the first call", "call it ONLY after get_latest_report returned the ticker with `stale: true` or in `missing`") plus an exclusion ("Never fan it out across a list of names"). For custom mode it names the preferred alternative workflow (explore → ideate → overlay) and reserves CUSTOM for the case where the user explicitly wants the Flexreport note written.

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