AlphAI

Earnings calendar

alphai_earnings_calendar

Read-onlyIdempotent

Who reports when and who just reported: companies with a report date the source marks as confirmed, by day, in New York market days. Use it for 'who reports today, tomorrow or this week', and with days_back for 'who reported this week': past days list the companies whose filing we have read, up to 7 days back. Estimated dates are left out, so later days fill in as companies announce, and a company missing here may still report. Covers large and actively followed names, not every listing. Days are in order, and within a day the companies with the most recent news come first. session is the expected session (before_open, after_close, or null when unknown), never an exact time. status turns to reported once the SEC filing lands. detail='full' adds previous_read: guidance and what_to_watch from our read of the company's previous report, AI-generated, not an analyst estimate, and report_read: the uid, listing, period and verdict of our read of the report the row is about. For the reads themselves use alphai_earnings; for macro releases, alphai_calendar. total counts every match; page with limit and offset. Informational, not investment advice.

Input Schema

Name	Required	Description	Default
`limit`	No	Rows per page, default 100.
`detail`	No	full adds previous_read and report_read to each row; default compact.	compact
`offset`	No	Rows to skip.
`sector`	No	Only this sector, as alphai_tickers spells it.
`tickers`	No	Only these companies; another share class of a company matches too.
`days_back`	No	Days before today to include, listing companies we read; default 0.
`days_ahead`	No	Days after today to include; 0 is today only, default 7.

Output Schema

Name	Required	Description	Default
`items`	Yes
`total`	Yes
`to_date`	Yes
`from_date`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedNov 6, 2026

addedInput schema / properties / days_back

Added value: +{
+  "default": 0,
+  "description": "Days before today to include, listing companies we read; default 0.",
+  "maximum": 7,
+  "minimum": 0,
+  "type": "integer"
+}

changedInput schema / properties / detail / description

Previous value: -"full adds previous_read to each row; default compact."New value: +"full adds previous_read and report_read to each row; default compact."

addedOutput schema / properties / items / items / properties / report_read

Added value: +{
+  "anyOf": [
+    {
+      "properties": {
+        "fiscal_period": {
+          "type": "string"
+        },
+        "published_at": {
+          "format": "date-time",
+          "type": "string"
+        },
+        "ticker": {
+          "type": "string"
+        },
+        "uid": {
+          "type": "string"
+        },
+        "verdict": {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        }
+      },
+      "required": [
+        "uid",
+        "ticker",
+        "fiscal_period",
+        "published_at"
+      ],
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

AddedNov 5, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/openWorld safety, yet the description still adds substantial behavior: past days only list companies whose filing has been read (capped at 7), missing rows may still report, ordering is by day then by most recent news, session is an expected session never an exact time, and status flips to reported once the SEC filing lands. It also flags previous_read as AI-generated rather than an analyst estimate, which is the kind of caveat an agent needs before quoting it.

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?

It is front-loaded with the core definition and then proceeds in a logical order: inclusion rules, use cases, ordering, field semantics, sibling routing, pagination. The single dense paragraph runs long and the closing 'Informational, not investment advice' is boilerplate, but nearly every clause carries distinct information.

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 an output schema present the description need not document return shapes, and it correctly focuses on inclusion rules, ordering, field meaning, and pagination via total/limit/offset. For a 7-parameter read tool with rich annotations, nothing an agent needs in order 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 still earns a bump by explaining what days_back actually returns (companies whose filing we have read) and by spelling out the contents of detail='full' (previous_read: guidance and what_to_watch; report_read: uid, listing, period, verdict). It says less about sector and tickers than the schema already does, so it stops short of a 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 sentence names the specific resource (companies with a confirmed report date, by day, in New York market days) and the filtering rule that defines it (estimated dates excluded). It explicitly contrasts itself with alphai_earnings (the reads) and alphai_calendar (macro releases), so an agent can separate it from siblings 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 concrete when-to-use phrasing ('who reports today, tomorrow or this week') and a second mode tied to a parameter ('with days_back for who reported this week'). It also names the two alternatives and the conditions that route to them, and states a scope exclusion (covers large and actively followed names, not every listing).

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.