Skip to main content
Glama

Stocklake — AI Stock Intelligence

Get Earnings Intelligence

get_earnings_intelligence
Read-onlyIdempotent

Upcoming earnings with AI context - AI scores, verdicts, and risk factors per stock. Combines the earnings calendar with AI pipeline data to surface which upcoming earnings events are worth monitoring.

Parameters:

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

  • sector: filter to one sector (e.g. "Technology")

  • min_ai_score: only return stocks with AI score >= this value, 0-100 (optional). Gates on the same ai_score field the response returns. Applied server-side before limit truncates the result - a stock with a qualifying score always counts against limit ahead of one without, rather than being cut off first for reporting later in the earnings window.

  • limit: max results to return (default 25, max 25). Each returned ticker counts as one call toward your daily limit - see the docs' rate-limit section.

Returns per stock (sorted by earnings_date ascending):

  • earnings_date: ISO UTC timestamp · is_estimate: whether date is estimated

  • symbol, name, sector, price, rsi, market_cap

  • eps_trailing, eps_forward (earnings expectations context)

  • ai_verdict (positive/neutral/negative, from nightly AI pipeline)

  • ai_score (0-100) / ai_score_band (Weak/Moderate/Strong/Very Strong) - the AI research composite score, same 0-100 scale and bands as signal_score but a separate score; null if this stock has no AI summary yet.

  • ai_risks: top 2 AI-identified risk factors

  • analyst_rating, analyst_target

Pro tier only - AI pipeline cost attached. For informational purposes only. Not financial advice.

Input Schema

NameRequiredDescriptionDefault
limitNoMax results to return (default 25, max 25). Each returned ticker counts as one call toward your daily limit.
sectorNoFilter to one sector, e.g. "Technology".
days_aheadNoLook-ahead window in days (default 14, max 30).
min_ai_scoreNoOnly return stocks with AI score >= this value, 0-100 (optional). Gates on the same ai_score field the response returns. Applied server-side before limit truncates the result, so a qualifying stock always counts against limit ahead of one without.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / min_ai_score / description
      Previous value: -"Only return stocks with AI score >= this value, 0-100 (optional). Renamed 2026-08-24 from the retired 0-10 min_flag_score — gates on the same stock_ai_summary.py ai_score field the response already returns. Applied server-side before limit truncates the result, so a qualifying stock always counts against limit ahead of one without."New value: +"Only return stocks with AI score >= this value, 0-100 (optional). Gates on the same ai_score field the response returns. Applied server-side before limit truncates the result, so a qualifying stock always counts against limit ahead of one without."
  2. Changed4 schema fields changed
    • addedInput schema / properties / days_ahead / description
      Added value: +"Look-ahead window in days (default 14, max 30)."
    • addedInput schema / properties / limit / description
      Added value: +"Max results to return (default 25, max 25). Each returned ticker counts as one call toward your daily limit."
    • addedInput schema / properties / min_ai_score / description
      Added value: +"Only return stocks with AI score >= this value, 0-100 (optional). Renamed 2026-08-24 from the retired 0-10 min_flag_score — gates on the same stock_ai_summary.py ai_score field the response already returns. Applied server-side before limit truncates the result, so a qualifying stock always counts against limit ahead of one without."
    • addedInput schema / properties / sector / description
      Added value: +"Filter to one sector, e.g. \"Technology\"."
  3. Changed2 schema fields changed
    • addedInput schema / properties / min_ai_score
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "integer"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null
      +}
    • removedInput schema / properties / min_flag_score
      Removed value: -{
      -  "anyOf": [
      -    {
      -      "type": "integer"
      -    },
      -    {
      -      "type": "null"
      -    }
      -  ],
      -  "default": null
      -}
  4. Changed1 schema field changed
    • addedInput schema / properties / limit
      Added value: +{
      +  "default": 25,
      +  "type": "integer"
      +}
  5. Added

TDQS

A4.1/5.0
Behavior5/5

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

Goes well beyond the annotations (which only cover the read-only/idempotent safety profile) by disclosing tier gating ('Pro tier only'), cost implications ('AI pipeline cost attached'), and a rate-limit interaction ('each returned ticker counts as one call toward your daily limit'). It also explains the server-side ordering of min_ai_score vs limit truncation, which is genuinely non-obvious behavior.

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?

Front-loaded with a clear purpose statement, but the parameter and return-value lists duplicate the input schema and the existing output schema, making the description longer than necessary. The structure is readable but not economical.

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 four-parameter read tool with an output schema, the description supplies everything an agent needs: tier restriction, cost, rate-limit accounting, filtering semantics, and sort order. The return-field enumeration is redundant given the output schema but not harmful.

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%, so all four parameters are already documented in the schema and the description largely restates them (days_ahead, sector, min_ai_score, limit). It adds only marginal nuance about ai_score gating and limit interaction, which the schema also captures, so 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 resource and differentiator: 'Upcoming earnings with AI context - AI scores, verdicts, and risk factors per stock.' The second sentence explicitly says it 'combines the earnings calendar with AI pipeline data,' which lets an agent distinguish it from the plain get_earnings_calendar sibling 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 Guidelines3/5

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

Implies when to use it ('surface which upcoming earnings events are worth monitoring') but never names an alternative or exclusion, even though get_earnings_calendar is an obvious sibling. An agent must infer that this tool is the AI-enriched superset rather than being told directly.

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