6ix

Earnings call calendar

get_earnings_calendar

Read-onlyIdempotent

Use this when someone asks which companies hold earnings calls on a day or in a date range, for example this week, across the market or on one exchange. Give it dates (YYYY-MM-DD, UTC; default the next seven days) and optionally an exchange. Returns calls in time order with company and 6ix.com link, and how many calls the range holds; pass the answer's nextCursor as cursor until hasMore is false to get every call in the range.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_earnings_calendar"
  }
}

Input Schema

Name	Required	Description
`to`	No	Last day, YYYY-MM-DD, included (default: a week from the first day; at most 31 days)
`from`	No	First day, YYYY-MM-DD (default today)
`page`	No	Pages of `limit` calls in time order
`limit`	No
`cursor`	No	To read on: nextCursor from this tool's last answer, exactly as given, with the same other arguments
`exchange`	No	Only companies listed on this exchange, e.g. NYSE, NASDAQ, LSE, TSE

Output Schema

Name	Required	Description
`to`	Yes
`asOf`	No	When 6ix answered (ISO 8601, UTC)
`from`	Yes
`first`	Yes	Position of this answer's first call in the range, from 1
`total`	Yes	Every call 6ix lists in the range (and exchange)
`events`	Yes
`hasMore`	Yes	More follow: ask again with cursor set to nextCursor
`nextCursor`	Yes	Pass as cursor to read on from the last item shown; null at the end
`listChanged`	No	The list changed since the cursor was made and the last item shown is no longer in it, so an item may repeat or be missed here

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedOct 14, 2026

addedInput schema / properties / cursor

Added value: +{
+  "description": "To read on: nextCursor from this tool's last answer, exactly as given, with the same other arguments",
+  "maxLength": 700,
+  "minLength": 8,
+  "type": "string"
+}

addedInput schema / properties / page

Added value: +{
+  "default": 1,
+  "description": "Pages of `limit` calls in time order",
+  "maximum": 10000,
+  "minimum": 1,
+  "type": "integer"
+}

addedOutput schema / properties / first

Added value: +{
+  "description": "Position of this answer's first call in the range, from 1",
+  "type": "integer"
+}

addedOutput schema / properties / hasMore

Added value: +{
+  "description": "More follow: ask again with cursor set to nextCursor",
+  "type": "boolean"
+}

addedOutput schema / properties / listChanged

Added value: +{
+  "description": "The list changed since the cursor was made and the last item shown is no longer in it, so an item may repeat or be missed here",
+  "type": "boolean"
+}

addedOutput schema / properties / nextCursor

Added value: +{
+  "description": "Pass as cursor to read on from the last item shown; null at the end",
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / total / description

Added value: +"Every call 6ix lists in the range (and exchange)"

changedOutput schema / required

Previous value: -[
-  "from",
-  "to",
-  "events",
-  "total"
-]New value: +[
+  "from",
+  "to",
+  "events",
+  "total",
+  "first",
+  "hasMore",
+  "nextCursor"
+]

AddedOct 14, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds genuinely useful behavior the annotations don't: the default seven-day window, time-ordered results, and the full cursor/hasMore pagination loop. It does not mention rate limits or auth, but the pagination protocol is the key operational detail an agent needs.

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?

Three sentences, front-loaded with the usage trigger, then parameters, then return/pagination semantics. Dense but every clause carries information; no filler. Slightly packed rather than maximally tight.

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?

An output schema exists, so return values need not be explained, yet the description still covers ordering, result fields, the count, and the cursor loop. Combined with annotation coverage, an agent has everything needed to call and page through this tool correctly.

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 83%, so most parameters are already documented, establishing a baseline of 3. The description adds the UTC interpretation for the date inputs (the schema only says 'format: date') and restates the default window and cursor round-trip, giving real value beyond the schema.

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 states a concrete verb and resource: 'which companies hold earnings calls on a day or in a date range'. The scope phrase 'across the market or on one exchange' implicitly separates it from the per-company sibling get_company_earnings_calls, but no sibling is named explicitly, so it stops short of full sibling differentiation.

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?

Opens with an explicit trigger ('Use this when someone asks which companies hold earnings calls on a day or in a date range') and gives concrete examples ('this week', 'across the market or on one exchange'). It never names the alternative (get_company_earnings_calls) or states when NOT to use it, so no exclusions are provided.

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

All 6ix 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.

Resources

Need Help?