Skip to main content
Glama

Stocklake — AI Stock Intelligence

Get Earnings Calendar

get_earnings_calendar
Read-onlyIdempotent

Upcoming earnings dates for stocks in the Stocklake universe.

  • days: look-ahead window in days (default 7, max 30)

  • limit: max companies to return. Free and guest get at most 5, whatever limit says: the companies with the largest market cap, listed by date, each counted as one call toward your daily limit. Pro gets up to 500 companies per call (default 100) for one call. A window can hold 1,000+ reporters; page with offset, or narrow with symbols / min_market_cap / a smaller days.

  • offset: Pro only. Skips that many companies (sorted by date). Pass the response's next_offset to get the next page.

  • symbols: only these tickers (up to 50). Applied before limit.

  • min_market_cap: only companies with at least this market cap in USD.

  • Returns: { window_days, from_date, to_date, count, total_in_window, offset, next_offset, results[] }. total_in_window counts the companies that match your filters, before limit/offset; next_offset is null on the last page (Free and guest: always null).

  • Each result: symbol, name, sector, market_cap, price, rsi, earnings_date (ISO UTC), is_estimate, eps_trailing, eps_forward

  • Sorted by earnings_date ascending.

  • Dates sourced from market data - treat is_estimate=true dates as approximate. Available to all tiers.

Input Schema

NameRequiredDescriptionDefault
daysNoLook-ahead window in days (default 7, max 30).
limitNoMax companies to return. Free and guest: at most 5 (the largest by market cap), each counted as one call toward your daily limit. Pro: up to 500 per call (default 100), one call each.
offsetNoPro only: skip this many companies (by date) to page through a long window. Use next_offset from the previous response. Ignored for Free and guest.
symbolsNoOnly these tickers (up to 50), e.g. your holdings. Applied before limit.
min_market_capNoOnly companies with a market cap of at least this many US dollars (e.g. 10000000000 for $10B). Applied before limit.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / limit
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "integer"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Max companies to return. Free and guest: at most 5 (the largest by market cap), each counted as one call toward your daily limit. Pro: up to 500 per call (default 100), one call each."
      +}
    • addedInput schema / properties / min_market_cap
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "number"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Only companies with a market cap of at least this many US dollars (e.g. 10000000000 for $10B). Applied before limit."
      +}
    • addedInput schema / properties / offset
      Added value: +{
      +  "default": 0,
      +  "description": "Pro only: skip this many companies (by date) to page through a long window. Use next_offset from the previous response. Ignored for Free and guest.",
      +  "type": "integer"
      +}
    • addedInput schema / properties / symbols
      Added value: +{
      +  "anyOf": [
      +    {
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Only these tickers (up to 50), e.g. your holdings. Applied before limit."
      +}
  2. Changed1 schema field changed
    • addedInput schema / properties / days / description
      Added value: +"Look-ahead window in days (default 7, max 30)."
  3. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare read-only/idempotent/non-destructive, and the description layers on genuinely non-obvious behavior: Free and guest are capped at 5 companies 'whatever limit says', each call counts toward a daily quota, Pro allows 500/call, offset is ignored for Free/guest. It also flags that dates are market-data-sourced and is_estimate=true should be treated as approximate — a real caveat not captured by schema or annotations.

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

Conciseness5/5

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

Front-loaded one-line purpose followed by a per-parameter bullet list, then return shape and sort order. Every bullet carries decision-relevant information (tier caps, precedence, paging), and the redundancy with schema descriptions is small relative to the density of added semantics.

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?

Even though an output schema exists, the description's return-shape sketch adds the meaning of total_in_window vs count and the null-on-last-page rule for next_offset, plus sort order and Free-tier next_offset always being null. For a 5-param, tier-gated, paginated tool, nothing an agent needs to call it 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 the baseline is 3; the description exceeds it by explaining evaluation order ('applied before limit' for symbols and min_market_cap), tier-conditional enforcement of limit and offset, and the next_offset paging contract. Much of it restates the schema text verbatim, which caps it below a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource: 'Upcoming earnings dates for stocks in the Stocklake universe', which is clearly distinct from price/news/financials siblings. It does not, however, differentiate itself from the closest neighbors (get_earnings_intelligence, get_economic_calendar), so an agent must infer the boundary rather than read it.

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?

Strong operational guidance: it tells the agent to page with offset, or to narrow with symbols / min_market_cap / a smaller days when a window holds 1,000+ reporters, and warns that offset is Pro-only. Missing is explicit routing guidance vs. sibling tools such as get_earnings_intelligence, so the 'when to use this instead' half of the equation is absent.

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