AlphAI

Earnings reads for a ticker

alphai_earnings

Read-onlyIdempotent

Structured reads of a company's earnings reports, newest first, plus its next confirmed report date. Reads are generated from SEC filings: 8-K item 2.02 for US filers and 6-K earnings releases for foreign private issuers. Carries reported metrics with year-over-year and sequential comparisons, segments, guidance, drivers, concerns and management quotes; each key_metrics and segments row also carries numeric, unit and scale next to the printed value (scale is null when the filing does not say), and table_scale names the unit of the filing's tables, which is the unit of any figure the notes and analysis quote bare. Reports can be returned across share classes; each row identifies the filing's share class. Depth is shallow: AlphAI's reads begin with filings from late July 2026 and reports are quarterly, so most tickers carry one or two reads and an empty list is a normal answer, not an error. An LLM writes each read: every figure is checked against the filing text. A key_metrics or segments row with a figure the filing does not print, or a key_metrics row whose value, prior and change do not add up, is dropped, and numbers_verified_from_document is false when another figure could not be matched. A figure can still be misread, so cite the filing for decisions. Informational, not investment advice.

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": {
      "ticker": "<ticker>"
    },
    "name": "alphai_earnings"
  }
}

Input Schema

Name	Required	Description	Default
`ticker`	Yes	Ticker symbol, e.g. 'NVDA'.

Output Schema

Name	Required	Description	Default
`ticker`	Yes
`reports`	No
`unknown_ticker`	No
`next_report_date`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 9, 2026

changedOutput schema / description

Previous value: -"``alphai_earnings`` payload: the reads plus the next confirmed date.\n\nExists because the loop it closes could not be walked before: an agent that\nlearned a report date had no way to reach the read of that report. The feed\ntools never populate `earnings`, and `alphai_article` needs a uid the agent\nhad no way to obtain (docs/FEED_TRUST_AND_EARNINGS_LOOP.md §1.1)."New value: +"``alphai_earnings`` payload: the earnings reads plus the next confirmed\nreport date. This is the way from a report date to the read of that report:\nthe feed tools do not populate ``earnings``."

Changed2 schema fields changedSep 26, 2026
- addedInput schema / properties / ticker / maxLength
```
Added value: +16
```
- addedInput schema / properties / ticker / pattern
```
Added value: +"^[A-Za-z0-9.\\-]+$"
```

Changed1 schema field changedSep 13, 2026

changedOutput schema / properties / reports / items / description

Previous value: -"One published AlphaAI earnings read, as served by ``alphai_earnings``."New value: +"One published AlphAI earnings read, as served by ``alphai_earnings``."

AddedSep 6, 2026

TDQS

A4/5.0

Behavior5/5

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

Annotations already cover read-only, idempotent and non-destructive behavior, but the description goes well beyond them: SEC provenance (8-K item 2.02 for US filers, 6-K for foreign private issuers), the LLM-authoring and figure-verification process, the rule that non-matching rows are dropped, the numbers_verified_from_document flag, cross-share-class returns, and coverage starting late July 2026. It also discloses the key caveat that a figure can still be misread, which is exactly the residual risk an agent needs to know about.

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 text is long, roughly 200 words, but it is front-loaded with purpose and each sentence introduces a distinct constraint: provenance, verification, units and scale, share classes, depth, disclaimer. The unit and scale explanation is dense and partly overlaps the output schema, keeping it from a 5, but there is no filler or repetition.

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 single-parameter read tool with an output schema and full annotation coverage, the description supplies everything an agent needs to call it and interpret the result: what corpus backs it, how numbers are validated, when an empty result is expected, and how to treat cross-share-class rows. Output formatting is appropriately left to the output schema rather than restated.

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?

There is only one parameter and schema coverage is 100%, with the schema already supplying the pattern, max length and an example, so the description is not required to carry much. It reframes the input as 'a company's earnings reports' and notes that results may span share classes, but adds no ticker-specific resolution rules (e.g. exchange prefixes, ambiguity handling) beyond the schema — baseline 3.

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?

The description opens with a specific verb and resource ('Structured reads of a company's earnings reports... plus its next confirmed report date') scoped to a single ticker, and the newest-first ordering makes the shape concrete. It is clearly distinguishable from generic news tools, though it never names a sibling such as alphai_earnings_calendar even though it partly overlaps that tool's territory by returning the next report date.

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?

There is genuinely useful operational guidance — 'an empty list is a normal answer, not an error' and 'cite the filing for decisions' — which prevents an agent from misreading sparsity or over-trusting numbers. However, there is no explicit when-to-use versus when-not guidance and no named alternative for calendar-style date lookups or for broader news retrieval, so selection still requires inference.

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

All AlphAI 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.