Flexreport Finance

get_transcript_guidance

Read-only

One company's guidance label call by call (RAISED, INLINE, REVISED DOWNWARDS or NOT_PROVIDED) — the direct read for "did X cut guidance" and how its guidance posture has moved call over call.

===> Prefer this over explore_data_catalogue for one company's labels: it is synchronous
and returns the rows directly. It takes one symbol, so a market-wide question ("who
raised guidance this season") belongs in explore_data_catalogue.

LABELS:
  RAISED             management explicitly raised the outlook or signalled stronger
                     forward expectations
  INLINE             reaffirmed or maintained the prior outlook, or gave fresh guidance
                     consistent with consensus or the prior trajectory. Also the label
                     when signals truly balance out
  REVISED DOWNWARDS  cut, lowered, walked down to the low end, or signalled weaker
                     forward expectations
  NOT_PROVIDED       no forward guidance, withdrawn with no replacement, or the call's
                     analysis is silent on the outlook

A label is a model's judgment of the call's narrative analysis, not a comparison of
guidance numbers, and it is the DOMINANT signal when a company raised one metric and
cut another. Before you publish one, or to say what was actually guided, read the same
call's `get_transcript_analysis`.

Returns {"symbol": ..., "count": N, "rows": [{"symbol", "date", "guidance_outlook",
"last_updated"}]}, newest call first. `date` is the CALL date, not a fiscal period. The
newest row may be from last quarter if this quarter's call has not happened yet, so
check its date before calling it current. A re-analyzed call can rarely hold two labels
a few days apart: treat them as one call and say so if they differ. `note` is set only
on an empty result.

Errors: a 404 means the ticker is outside coverage.

Requires auth (your MCP client attaches the OAuth bearer automatically).
Rate-limited 500/min.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "symbol": "<symbol>"
    },
    "name": "get_transcript_guidance"
  }
}

Input Schema

Name	Required	Description	Default
`limit`	No	Most recent calls to return (1-20, default 4, about a year of calls).
`symbol`	Yes	Covered ticker, e.g. "AAPL".

Output Schema

Name	Required	Description
`note`	No	Set only when no rows came back: what an empty result can mean.
`rows`	Yes	Newest call first.
`count`	Yes	Rows returned: at most `limit` classified calls.
`symbol`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 6, 2026

TDQS

A4.6/5.0

Behavior5/5

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

The description goes well beyond the readOnlyHint annotation: it states the row shape, newest-first ordering, that date is call date not fiscal period, that the newest row may be from last quarter, that re-analyzed calls can yield duplicate labels a few days apart, that `note` appears only on empty results, that 404 means out of coverage, plus auth and a 500/min rate limit. For a read-only tool this is unusually complete operational context.

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 opening sentence front-loads the core purpose and the routing rule comes next, with a clearly delimited LABELS block and a returns/errors paragraph — structure is strong. It runs long and the "===>" emphasis is a little noisy, but every block carries information an agent needs to interpret the labels or avoid the stale-row mistake.

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 an output schema existing, the description still supplies what the schema cannot: label taxonomy, dominant-signal rule for mixed guidance, data-freshness caveat, duplicate-row handling, and error semantics. Nothing needed to call this correctly — auth, rate limits, symbol scope, interpretation of the label — is missing.

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% and both parameters are documented in the schema (including the 1-20 limit and its default of 4), so the schema does the heavy lifting. The description reinforces the single-symbol constraint and the newest-first ordering of returned rows, but adds no detail about how `limit` interacts with the duplicate-label or stale-newest-row caveats beyond what the schema states.

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 gives a concrete verb and resource — read one company's guidance label call by call — and immediately scopes it with a use-case example ("did X cut guidance") and a definition of what a label means. It differentiates itself from explore_data_catalogue (market-wide questions) and get_transcript_analysis (publishing/detail), so an agent can pick correctly without opening schemas.

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?

Explicit routing rules are given: prefer this over explore_data_catalogue for one company because it is synchronous and returns rows directly, and route market-wide questions to explore_data_catalogue instead. It also names a follow-up dependency (read get_transcript_analysis before publishing a label), which is a real workflow constraint rather than a vague suggestion.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Flexreport Finance tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?