Skip to main content
Glama

Earnings Call Event

GetEarningsCallEvent
Read-only

Get the earnings-call event for a company's fiscal quarter: one record grouping the call's audio, transcript, slide deck and 8-K earnings release. Returns the event id, title, call date, status, each artefact's status (available, pending, notPublished, failed, notAttempted, noCallHeld) with its reason and capture times, the transcript and release document ids, and approved guidance rows from the 8-K. Omit the fiscal period for the latest call; read the transcript with GetEarningsCallTranscript.

Input Schema

NameRequiredDescriptionDefault
tickerYesCompany ticker symbol (e.g., AAPL, MSFT), or MIC:TICKER (e.g., XPAR:AIR) for a listing outside the US.
fiscalYearNoCompany fiscal year. Omit both period fields for the latest call; year alone selects the latest call in that fiscal year.
fiscalQuarterNoCompany fiscal quarter, 1-4. Quarter alone selects the latest matching quarter across fiscal years; provide both fields for an exact period.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / ticker / description
      Previous value: -"Company ticker symbol (e.g., AAPL, MSFT)"New value: +"Company ticker symbol (e.g., AAPL, MSFT), or MIC:TICKER (e.g., XPAR:AIR) for a listing outside the US."
  2. Changed2 schema fields changed
    • changedInput schema / properties / fiscalQuarter / description
      Previous value: -"Optional fiscal quarter, 1-4 (default: the company's latest call)"New value: +"Company fiscal quarter, 1-4. Quarter alone selects the latest matching quarter across fiscal years; provide both fields for an exact period."
    • changedInput schema / properties / fiscalYear / description
      Previous value: -"Optional fiscal year, in the company's own fiscal calendar — this can run ahead of the calendar year (e.g., NVDA's May 2025 call is FY2026 Q1). Omit the period for the company's latest call"New value: +"Company fiscal year. Omit both period fields for the latest call; year alone selects the latest call in that fiscal year."
  3. Changed7 schema fields changed
    • addedInput schema / properties / fiscalQuarter / default
      Added value: +null
    • changedInput schema / properties / fiscalQuarter / description
      Previous value: -"Fiscal quarter, 1-4"New value: +"Optional fiscal quarter, 1-4 (default: the company's latest call)"
    • changedInput schema / properties / fiscalQuarter / type
      Previous value: -"integer"New value: +[
      +  "integer",
      +  "null"
      +]
    • addedInput schema / properties / fiscalYear / default
      Added value: +null
    • changedInput schema / properties / fiscalYear / description
      Previous value: -"Fiscal year the quarter belongs to, in the company's own fiscal calendar — this can run ahead of the calendar year (e.g., NVDA's May 2025 call is FY2026 Q1)"New value: +"Optional fiscal year, in the company's own fiscal calendar — this can run ahead of the calendar year (e.g., NVDA's May 2025 call is FY2026 Q1). Omit the period for the company's latest call"
    • changedInput schema / properties / fiscalYear / type
      Previous value: -"integer"New value: +[
      +  "integer",
      +  "null"
      +]
    • changedInput schema / required
      Previous value: -[
      -  "ticker",
      -  "fiscalYear",
      -  "fiscalQuarter"
      -]New value: +[
      +  "ticker"
      +]
  4. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already establish the safe read-only, closed-world profile, so the description's job is to add context beyond that, and it does: it enumerates the artefact status vocabulary (available, pending, notPublished, failed, notAttempted, noCallHeld) with reasons and capture times. It doesn't discuss pagination, auth requirements, or rate limits, but for a read tool that is a minor omission.

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?

Front-loaded with purpose, then return contents, then usage notes; no filler sentences. The return-value enumeration is dense but earns its place because there is no output schema, and it is organized rather than rambling.

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?

With no output schema, the description carries the return-value burden itself and does so thoroughly, covering identifiers, dates, statuses, document ids, and guidance rows. Combined with the parameter rules and the cross-reference to GetEarningsCallTranscript, an agent has everything needed to call and interpret this tool.

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 description coverage is 100% and the schema already explains ticker format, the year/quarter combination rules, and the omit-both-for-latest behavior. The description's 'Omit the fiscal period for the latest call' largely restates the schema, adding little new parameter meaning, so the baseline 3 applies.

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?

States a specific verb and resource ('Get the earnings-call event for a company's fiscal quarter') and immediately clarifies what the record is: one grouping of audio, transcript, slide deck and 8-K. It names the sibling it is not (GetEarningsCallTranscript), so an agent can separate it from the other GetEarningsCall* 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 Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete operating guidance ('Omit the fiscal period for the latest call') and routes the agent to the correct follow-up tool for transcripts. It stops short of stating explicit when-not-to-use conditions versus the other earnings-call siblings (Questions, Tone and Themes, Theme History), but the context is clear.

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.

Directories

Listed in ChatGPT · Equibles

Last observed