Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official

kalshi_markets_history

Retrieve candlestick history for up to 25 Kalshi markets in one call by providing market tickers; set start, end, and interval to batch-download grouped market data.

Instructions

Kalshi batch market history. Returns candlesticks for up to 25 Kalshi markets in one call. market_tickers is required, as a comma-separated list or repeated values. start_ts defaults to 7 days ago, end_ts to now and period_interval to 1440 minutes. Results are grouped by market. Ranges are capped at 366 days.

Input Schema

NameRequiredDescriptionDefault
end_tsNoUnix end timestamp in seconds. Defaults to now.
start_tsNoUnix start timestamp in seconds. Defaults to 7 days ago.
market_tickersYesComma-separated Kalshi market tickers. Repeated query values are also accepted.
period_intervalNoCandlestick interval in minutes. Default: 1440.
include_latest_before_startNoInclude the latest candle before start_ts when supported upstream.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.6.0
  2. Removedv1.6.0
  3. Addedv1.1.0

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does disclose real behavioral facts: the 25-market batch limit, the 366-day range cap, the grouping of results by market, and the default time window. It does not cover auth requirements or error behavior, but for a read-only history tool the disclosed limits are substantive.

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?

Front-loads the purpose, then constraint and default information in compact sentences with zero padding. Every line (batch size, required param, defaults, grouping, range cap) earns its place.

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?

For a 5-parameter batch history tool with no output schema, the description explains the return shape (candlesticks grouped by market) and all the key limits and defaults, which is nearly enough to call it correctly. Only the exact candlestick schema and any error/auth behavior are left unstated.

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 the schema already documents every parameter including the defaults the description repeats (start_ts 7 days ago, end_ts now, period_interval 1440, comma-separated tickers). The description adds the fact that market_tickers is required and repeatable, but that is largely restated from the schema, 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 verb and resource (returns candlesticks for Kalshi markets) plus the batch scope (up to 25 markets in one call), which distinguishes it from the singular kalshi_market_history and kalshi_historical_market_history siblings. An agent can pick it based on the multi-market batching alone.

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 its use case by stating it handles up to 25 markets in one call, so batch retrieval is the intended scenario, but it never explicitly says when to prefer this over the single-market or historical-market siblings, nor any prerequisites. Usage is inferable, not stated.

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