Skip to main content
Glama
Sign In
MaverickMCP

MaverickMCP

by wshobson
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

get_upcoming_catalysts

List upcoming catalyst events such as earnings and dividends within a user-specified number of days, with optional ticker filtering.

Instructions

List upcoming catalyst events (earnings, ex-dividend, FDA decisions, etc.) within a given number of days from today. Optionally filter to a specific list of ticker symbols.

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_upcoming_catalysts"
  }
}

Input Schema

NameRequiredDescriptionDefault
symbolsNo
days_aheadNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It reveals the tool is a read-only list operation, but lacks details on data source, caching, pagination, or rate limits. However, it sufficiently indicates non-destructive behavior.

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?

The description is concise with two sentences covering purpose and parameters. Every word earns its place; no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given an output schema exists, the description adequately covers core usage. It could mention the maximum allowed days or data source, but for a simple list tool it is sufficiently complete.

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?

With 0% schema description coverage, the description adds meaning for both parameters: 'symbols' as optional ticker filter and 'days_ahead' as the time horizon. It clarifies the purpose beyond the raw schema, though it could be more explicit about parameter formats.

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 description clearly states the tool lists upcoming catalyst events such as earnings, ex-dividends, and FDA decisions, with a specific timeframe and optional ticker filter. It uses a specific verb ('list') and resource ('catalyst events'), and the examples differentiate it from siblings like 'get_economic_calendar'.

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?

The description implies usage for retrieving catalyst events within a time range but does not explicitly state when to use this tool over alternatives like 'get_economic_calendar' or provide when-not-to-use guidance. No exclusions or preconditions are mentioned.

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

Deploy Server

Other Tools