Flexreport Finance

get_document_section

Read-only

Open ONE numbered section of a source document — the exact earnings-call speaker turn a citation points at.

The other end of a `trace_data_sources` citation, and the finest grain the platform
serves: not the whole call, one turn of it. Use it to read the passage behind a
number before quoting it, and to quote a speaker verbatim with the citation intact.

Every argument comes off the citation you are following — a `transcript_section`
citation's URL is `/query-section?name=...&symbol=...&year=...&quarter=...&n=...`,
so read the four values out of it rather than deriving them. If you pulled the row
from `earnings_call_transcript_sections` yourself you already hold all four
(`symbol`, `year`, `quarter`, `section_no`); no text search is needed or wanted.

*** `year` and `quarter` are the FISCAL period of the CALL, never the calendar
quarter a report covers. *** For most covered companies those differ — the call
everyone calls "Q2 2026" is stored as FY2026 Q4 for one name and FY2027 Q1 for
another. Take the period from the citation, the transcript record, or `call_date`.
A 404 here ("no section N for SYM YEARqQ") is almost always this, not a missing
call: re-check the period before concluding the transcript is not covered.

Returns {"name", "symbol", "year", "quarter", "n", "format": "paragraph",
"count", "rows": [{symbol, year, quarter, call_date, section_no, speaker,
content}], "highlights": [...], "total_sections": N, "transcript_url": ...}.
`content` is the turn's text and `speaker` is who said it — attribute the quote to
that speaker, never to "the company". `total_sections` bounds `n`, so neighbouring
turns (n-1, n+1) are how you read a passage in context when it starts mid-answer.
`highlights` are quotes the platform's own analysis pipeline verified against this
section; they mark evidence inside it but are NOT necessarily the passage you are
citing — verify your own quote against `content`. `transcript_url` is frequently
null, so offer "view the full call" only when it is present.

Requires auth (your MCP client attaches the OAuth bearer automatically).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`n`	Yes	1-based section number (the speaker turn), e.g. the citation's `n` or `section_no`.
`name`	No	Whitelisted section source; "earnings_transcript" is the only one today.	earnings_transcript
`year`	Yes	FISCAL year of the call (never the calendar year a report covers), read off the citation URL or transcript record.
`symbol`	Yes	Ticker the cited call belongs to, read off the citation.
`quarter`	Yes	FISCAL quarter of the call, read off the citation URL or transcript record.

Output Schema

TableJSON Schema

Name	Required	Description
`n`	Yes	1-based section number.
`name`	Yes
`rows`	Yes
`year`	Yes	Fiscal year of the call.
`count`	No
`format`	No
`symbol`	Yes
`quarter`	Yes	Fiscal quarter of the call.
`highlights`	No	Quotes the platform verified against this section.
`total_sections`	No	Upper bound for n; read n-1 / n+1 for context.
`transcript_url`	No	Full call link; frequently null.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 15, 2026

TDQS

A4.8/5.0

Behavior5/5

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

With only readOnlyHint=true in annotations, the description carries real behavioral load: auth requirement, the common 404 cause and its remedy, that transcript_url is frequently null (so don't offer a link), that highlights are pipeline-verified but not necessarily your quote, and that total_sections bounds n. None of this contradicts the annotations and none of it is recoverable from structured fields.

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 lead sentence is front-loaded and the purpose is clear before any caveats. It is on the long side, and the bold fiscal-period warning partially duplicates the schema's own field note, but every remaining sentence (citation derivation, 404 remedy, highlights semantics, null transcript_url) earns its place.

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?

For a 5-parameter authenticated read tool with an output schema, the description covers the things the schema cannot: auth handling, error interpretation, how to read a mid-answer passage via adjacent sections, and caveats on two return fields. Nothing material an agent needs to call this correctly is missing.

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 a baseline of 3 applies, but the description goes beyond the schema by explaining where each value originates (the citation URL's name/symbol/year/quarter/n components, or the transcript row's section_no) and by stressing the fiscal-vs-calendar period trap. It doesn't add per-parameter syntax beyond that, so it stops short of 5.

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 opening line states a specific verb and resource with exact scope: 'Open ONE numbered section of a source document — the exact earnings-call speaker turn a citation points at.' It positions itself against siblings by naming trace_data_sources as the counterpart and clarifying the grain ('not the whole call, one turn of it'). An agent can distinguish this from transcript-listing tools 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?

It gives explicit when-to-use ('read the passage behind a number before quoting it... quote a speaker verbatim with the citation intact'), describes the alternative acquisition path ('if you pulled the row from earnings_call_transcript_sections yourself you already hold all four'), and instructs to derive args from the citation URL rather than guess. The 404 troubleshooting guidance is an unusually strong when-it-fails clause.

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?