Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

kalshi_markets

List and filter Kalshi prediction markets by ticker, event, series, or status, with pagination and market details like prices, volume, and rules.

Instructions

Kalshi markets. Lists Kalshi markets, up to limit rows (default 25, max 200), continued with cursor. Filter by event_ticker, series_ticker, ticker, or status (unopened, open, closed or settled). Each market has its title, status, prices, bid and ask, volume, open interest and rules text. A returned status can read active even though the filter does not accept it.

Input Schema

NameRequiredDescriptionDefault
limitNoRows to return, default 25, max 200
cursorNoPagination cursor from a previous Kalshi response
statusNoMarket status filter
tickerNoKalshi market ticker filter
event_tickerNoKalshi event ticker filter
series_tickerNoKalshi series ticker filter

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.17.5
    • addedInput schema / properties / status / enum
      Added value: +[
+  "unopened",
+  "open",
+  "closed",
+  "settled"
+]
  2. Addedv1.6.0
  3. Removedv1.6.0
  4. Addedv1.1.0

TDQS

A3.7/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 well: it discloses pagination defaults/caps (default 25, max 200), the accepted status values, and a genuine gotcha that a returned status can read 'active' even though the filter rejects it. It omits any auth or rate-limit context, but as a read-only list operation that is a minor gap.

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?

Four compact sentences, with the operative facts (what it lists, limit, pagination, filters, returned fields) front-loaded. The 'Kalshi markets.' fragment is mildly redundant with the following sentence but costs little.

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?

With no output schema or annotations, the description compensates by naming the returned fields (title, status, prices, bid/ask, volume, open interest, rules) and covering filters and pagination. For a list endpoint it is nearly complete, lacking only error/rate-limit or empty-result behavior.

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 and the baseline is 3. The description largely restates the filter set and limit/cursor behavior, adding only the 'active' status quirk, so it does not meaningfully extend what the schema provides.

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?

States a specific verb and resource ('Lists Kalshi markets') and enumerates the filters and returned fields, so the agent knows exactly what the call produces. It does not, however, differentiate itself from close siblings like kalshi_market, kalshi_events, or kalshi_markets_history, leaving the agent to infer the choice.

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?

Filtering and pagination guidance is present (filter by ticker/status, continue with cursor), which implies how to narrow or page through results. But there is no explicit when-to-use-this-vs-alternatives statement naming siblings like kalshi_market or kalshi_events, so selection is left to inference.

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