Search and inspect the Kalshi Eye archive of prediction market data (Kalshi, Polymarket, Limitless, Chainlink) through 10 tools, and get signed links to download its daily Parquet files.
search — find series, events and markets by keyword, optionally filtered by venue, archive category, or live/closed status.
get_series — one series' description, cadence, and how many markets and days of data it has.
list_markets — markets in a series that closed or close within the last 1–7 days, with status, result and times.
get_market — one market by Kalshi ticker or Polymarket token id: terms, status, result, recorded coverage.
market_price_history — recorded YES best bid/ask path over a market's life (about 40 points) plus coverage.
list_datasets — every dataset with what it holds, its columns, required plan and days available.
dataset_series — which series have files in a dataset, with days, rows and size.
recording_status — whether the recorder is running, the last published day, and recent completeness by venue.
list_files — daily Parquet files for a dataset over a date range, optionally one series (needs KALSHIEYE_API_KEY).
download_links — signed download URLs for file keys from list_files; first download of a file per month counts against the plan allowance (needs a key, not read-only).
Note: the schema differs from the README in two places — list_markets here takes only a series plus days (no keyword/venue paging), and market_price_history returns about 40 points rather than ~240.
Provides access to Chainlink price data recorded in the Kalshi Eye archive, queryable alongside prediction-market data from Kalshi, Polymarket, and Limitless.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Kalshi Eye MCP Server How did the Bills vs Rams market trade on October 12?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that lets AI assistants such as Claude and Cursor search the Kalshi Eye archive of prediction market data. It can find Kalshi, Polymarket and Limitless markets, show how a market's price moved, check what was recorded, and list the order book files you can download.
It needs a Kalshi Eye API key: create one at API keys (a free account works) and set it as KALSHIEYE_API_KEY.
Claude Code:
claude mcp add kalshieye -e KALSHIEYE_API_KEY=clab_your_key -- uvx kalshieye-mcpClaude Desktop, Cursor and other clients (claude_desktop_config.json, .cursor/mcp.json, ...):
{
"mcpServers": {
"kalshieye": {
"command": "uvx",
"args": ["kalshieye-mcp"],
"env": { "KALSHIEYE_API_KEY": "clab_your_key" }
}
}
}Without a key, or with a placeholder, every tool answers with how to get one. Listing files and download links cover the datasets your plan includes.
uvx comes with uv. With pip instead: pip install kalshieye-mcp, then use kalshieye-mcp as the command.
Related MCP server: Polymarket MCP Server
Tool | What it does |
| Find series, events and markets by keyword, venue, category or status. Series lead and come a page at a time ( |
| One series: what it is, how often it runs, markets in the catalog, and days of data files |
| A series' markets, or the markets on every venue holding each word of |
| Every event on every venue whose title, series name or category holds each word of the query, newest first, a page at a time ( |
| One market's terms, status, result, and how much of it was recorded |
| The recorded YES bid/ask path, up to about 240 points over the market's busiest stretch; |
| Every dataset: what it holds, columns, plan, days available |
| Which series have files in a dataset, with days, rows and size, up to 500 a page with |
| Whether recording is running, and the recorded share of recent days by venue |
| Daily Parquet files for a dataset, date range and series, page by page |
| Signed download URLs for up to 100 of those files (counts toward the monthly allowance) |
Things to ask:
"Which bitcoin markets does Kalshi Eye record, and since when?"
"What were the last few hours of the Bills vs Rams market on October 12 like?"
"How much of the Fed decision series is in the order book files?"
"Is the recorder running, and how complete was last week?"
Kalshi is recorded since October 12, 2026; Polymarket, Limitless and Chainlink prices since October 15, 2026. Each UTC day is published the next morning.
Prices are dollars between 0 and 1. A Kalshi YES ask is 1 minus the best NO bid. Times are UTC.
Free data without any key: a one-day sample on Hugging Face and runnable examples. The Python client for downloading files is kalshieye.
KALSHIEYE_BASE_URL points the server at another deployment (default https://kalshieye.com).
Kalshi Eye is independent and is not affiliated with Kalshi, Polymarket or Limitless. MIT licensed.
Which series have files in one dataset (for example book_l2 or trades), with days, rows and size.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | ||
| dataset_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so safety behavior is covered. The description adds useful context about the metrics returned (days, rows, size), but does not discuss pagination despite the limit parameter, authentication needs, or other behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with the core purpose front-loaded. It contains no filler, though it is sparse enough that it leaves key parameter meaning unaddressed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists and annotations cover read-only/open-world behavior, but the tool has three parameters with zero schema descriptions and the description does not explain query or limit. For an agent to invoke it confidently, more parameter and routing guidance is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It only indirectly identifies dataset_id via 'in one dataset' and examples, and says nothing about the query or limit parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool lists series with files in one dataset, with examples like book_l2 and trades, and mentions returned metrics (days, rows, size). It is specific about the resource and scope but does not differentiate itself from nearby tools such as get_series or list_files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives like get_series, search, or list_files. The dataset-scoped purpose implies usage, but no exclusions, prerequisites, or alternative-selection criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Signed download URLs for file keys from list_files. Needs KALSHIEYE_API_KEY.
The first download of a file in a month counts toward the plan's monthly allowance.
| Name | Required | Description | Default |
|---|---|---|---|
| keys | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds real context beyond the annotations: an API key is required, and quota is consumed on a per-file, first-download-of-the-month basis. This explains the otherwise puzzling readOnlyHint=false and complements idempotentHint=true (repeat downloads in a month do not double-charge). It does not mention URL expiry or whether one URL is returned per key.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core purpose, followed by the two facts an agent cannot infer (auth and quota). No filler or restated name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with an output schema covering the return shape, auth and billing context are the main gaps and both are addressed. Missing only operational details like URL lifetime and maximum keys per request.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% for the single 'keys' parameter, so the description carries the burden — and it does, stating that keys are file keys obtained from list_files. That is the key missing semantic. It does not say whether keys must be exact matches or how many can be batched per call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific output (signed download URLs) for a specific resource (file keys), and anchors the resource to the sibling tool that produces it (list_files). An agent can tell this apart from search, get_series, or list_files without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly implies the usage chain: call list_files first, then pass those keys here. The auth prerequisite (KALSHIEYE_API_KEY) is stated explicitly. It stops short of naming when not to use it or any limits on batch size, so it is strong but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One market by ticker (Kalshi ticker, or a Polymarket token id): terms, status, result, and how much of its life was recorded.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds real value beyond that: it discloses that the key namespace spans two venues (Kalshi ticker or Polymarket token id) and that the response reports how much of the market's life was recorded, a non-obvious behavioral detail. It doesn't cover not-found behavior, which is the main remaining gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact sentence with the core action and key identifier caveat front-loaded; every clause adds information and nothing is padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value explanation is not required, and the description still hints at it. Combined with the identifier dual-namespace note, an agent has enough to call this correctly; only error/empty-result handling is unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must carry the lone parameter — and it does, naming accepted identifier formats (Kalshi ticker or Polymarket token id). That is meaningful disambiguation for an otherwise bare string field. It omits format examples or validation notes, so it is not a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource (one market), the lookup key (ticker), and enumerates what comes back: terms, status, result, recording coverage. This clearly separates it from list_markets and market_price_history by singling out a single market's record. It stops short of explicitly naming a sibling to route away from, so it lands at 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied — an agent can infer this is the detail-lookup call for a single known market versus the listing tools. There is no explicit when-to-use, when-not-to-use, or named alternative (e.g. 'use list_markets to find a ticker first').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One series (for example KXBTC15M or KXFEDDECISION): what it is, how often it runs, and how many markets and days the archive has.
| Name | Required | Description | Default |
|---|---|---|---|
| series_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint already tells the agent this is a safe read operation, and the description adds useful content about what information is returned: identity, cadence, market count, and archive day count. It does not add deeper behavioral context such as error handling or rate limits, but with annotations present a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with the resource scope front-loaded and examples placed efficiently in parentheses. Every clause maps directly to what the tool provides.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter lookup with an output schema and read-only annotations, the description gives enough context about what the tool returns. It could be slightly more complete by clarifying how to obtain a series_id, but the core call is understandable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the single required series_id parameter. The description compensates somewhat by giving concrete example IDs, but it does not explain ID format rules, where to obtain valid IDs, or any constraints beyond the examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this retrieves information about a single series, with concrete examples (KXBTC15M, KXFEDDECISION) and the kinds of details returned. It distinguishes scope as singular versus list-oriented siblings, though it does not explicitly name an alternative tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The singular phrasing 'One series' implies this is for looking up a specific series rather than listing many, but there is no explicit guidance on when to choose this over siblings like dataset_series or list_markets. Prerequisites and exclusions are not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every dataset in the archive (order books, top of book, minute bars, trades, settlements, Polymarket, Chainlink...): what it holds, the plan it needs, days available, and its columns.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish read-only and open-world behavior, and the description adds useful context beyond that: each result includes what the dataset holds, its required plan, available days, and columns. It does not mention ordering or pagination, but for a listing tool this is a solid behavioral summary.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence that immediately states the scope and then enumerates the useful returned fields. The examples are compact and the sentence has no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless listing tool with an output schema and clear read-only annotations, the description is complete enough. It explains what the catalog covers and what information each entry supplies, so an agent can call it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter behavior to explain. The baseline for a parameterless tool is 4, and the description appropriately focuses on output content rather than inventing parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource and scope: every dataset in the archive, including examples and the metadata returned for each. It is clear what the tool does, though it does not explicitly distinguish itself from siblings like dataset_series or list_files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the catalog-style description, which suggests it is for discovering datasets and comparing their plans, availability, and columns. However, it gives no explicit when-to-use guidance or alternatives for related tools such as dataset_series or search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Daily Parquet files for a dataset and date range (YYYY-MM-DD, UTC), optionally one series. Needs KALSHIEYE_API_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| series | No | ||
| dataset | Yes | ||
| end_date | Yes | ||
| start_date | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds a genuinely useful behavioral fact — the KALSHIEYE_API_KEY auth requirement — plus the UTC date convention, but says nothing about pagination or how the default limit of 100 behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence with no filler, front-loading the resource and scope before the auth note. It is telegraphic rather than ungrammatical, and every clause carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 described, and auth plus date format are covered. The notable remaining gap is the limit parameter, which is documented nowhere, leaving an agent without guidance on result size or pagination for a list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema coverage at 0%, the description compensates well: it explains that dataset, start_date and end_date define the query and that dates use YYYY-MM-DD in UTC, and that series is optional. Only the limit parameter goes unexplained in both schema and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource precisely — daily Parquet files scoped to a dataset and date range, optionally narrowed to one series — so an agent can tell what it retrieves. It does not, however, distinguish this from siblings like download_links or dataset_series, which an agent must still infer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use vs when-not guidance and no mention of alternatives such as download_links for fetching actual file contents. The agent gets context but no routing logic.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Markets in one series that closed or close within the last days days (1 to 7), with status, result and times.
status is a Kalshi market status, such as active or finalized.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| limit | No | ||
| series | Yes | ||
| status | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish that this is a read-only, open-world operation. The description adds useful behavioral context beyond that: it narrows results to markets that closed or close within a bounded day window and explains that status values follow Kalshi conventions such as active or finalized.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded, and wastes no words. The scope and day-window constraint appear immediately, followed by a brief clarification of status.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so the description need not explain return values. Still, for a four-parameter list tool with no schema descriptions, it omits the `limit` parameter and does not clarify whether `status` filters results or merely describes returned records.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry parameter meaning. It explains the `days` range (1 to 7) and implies `series`, but it never describes the `limit` parameter and does not clearly present `status` as a filter parameter rather than a returned field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the resource and scope: markets in one series that closed or close within a recent day window, with status, result, and times. It is specific enough to distinguish this from get_market or get_series, though it does not explicitly name sibling alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the scope: use it for markets belonging to a single series within the last 1-7 days. However, it never names alternatives such as get_market for a single market or search for broader queries, and it does not state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The recorded YES best bid and ask over a market's life, about 40 points, plus how much was recorded.
Good for "what did the market think over time". For every order book change, use the daily Parquet files (list_datasets, list_files).
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnlyHint, openWorldHint), and the description adds substantive behavior beyond them: the result is a coarse ~40-point sample across the market's lifetime and includes a record-count field. That implicitly warns the agent the data is downsampled, which is the key behavioral caveat. It does not mention rate limits, ordering, or gaps in coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with what is returned and the sampling granularity, followed by the use case and the alternative route. Every sentence carries information; nothing is padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return-value shape needn't be explained, and the description covers the essential caveat (sampled history) plus routing to raw data. The one remaining hole is the ticker argument, which an agent must guess from convention.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter, ticker, has 0% schema description coverage and is never mentioned in the description. 'Over a market's life' weakly implies the ticker identifies a market, but no format, identifier convention, or failure behavior is given, so the description does not compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description precisely characterizes the resource returned: the recorded YES best bid and ask over a market's life, roughly 40 points, plus a count of what was recorded. It is clearly distinguishable from siblings, explicitly pointing to list_datasets/list_files for full order-book granularity. It stops short of a 5 only because the action framing is nominal ('the recorded ... over a market's life') rather than an explicit verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a concrete when-to-use case ('what did the market think over time') and an explicit when-not case with named alternatives (for every order book change, use the daily Parquet files via list_datasets, list_files). Nothing about 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.
Whether the recorder is running now, the last published day, and the recorded share of recent days by venue.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is known. The description adds useful context about what status dimensions are reported, but does not discuss freshness, caching, or other operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the current state and then lists the historical reporting dimensions. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters, a present output schema, and read-only annotations, the description covers the key information an agent needs to understand what this status tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need to explain parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific status resource with concrete reported fields: current recorder state, last published day, and recorded share by venue. Clear enough to distinguish it from data-fetching siblings, though it does not explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, nor any exclusions. The status-diagnostic use case is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Kalshi, Polymarket and Limitless series, events and markets by keyword.
Examples: "bitcoin 15 minute", "fed rate", "NFL", "New York temperature". category is an archive category such as Crypto, Economics, Sports or Politics. status "live" keeps markets still trading.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| venue | No | ||
| status | No | ||
| category | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is clear. The description adds that search spans three venues and that status "live" keeps markets still trading, but it does not explain ranking, result ordering, pagination, or whether venue defaults matter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded with the core purpose, and every line earns its place by adding examples or filter semantics. There is no redundant restatement of the tool name or schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema exists, so return values need not be explained, and annotations cover the read-only/open-world profile. Still, for a five-parameter search tool with 0% schema description coverage, the description omits venue semantics and limit behavior, leaving some invocation ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry parameter meaning. It usefully explains query examples, category as an archive category, and status "live", but it leaves venue values and limit behavior unexplained, including the schema's chainlink venue option.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource scope: keyword search over Kalshi, Polymarket and Limitless series, events and markets. This distinguishes it from sibling listing/getting tools, but it does not explicitly name an alternative tool or clarify the boundary with list_markets/get_series.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by 'by keyword' and reinforced with examples like "bitcoin 15 minute" and "NFL", so an agent can infer when search is appropriate. However, there is no explicit when-not guidance or comparison to sibling tools such as list_markets or get_series.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0dataset_seriesdownload_linksget_marketget_serieslist_datasetslist_fileslist_marketsmarket_price_historyrecording_statussearchScored across 10 tools
Each tool has a distinguishable target: search (keyword discovery), get_series/list_markets/get_market (drill-down by series ticker or market ticker), and a separate archive tier (list_datasets, dataset_series, list_files, download_links). The only mild overlaps are get_series vs dataset_series and search vs list_markets, but descriptions disambiguate them clearly.
Most tools follow verb_noun (download_links, get_series, list_markets, get_market, list_datasets, list_files), but there are notable deviations: the bare verb 'search' and noun-only names like market_price_history, dataset_series, and recording_status. Still readable, but the pattern isn't uniform.
Ten tools is well-scoped for a market data archive: discovery, metadata, file listing, and download each earn their place with no redundant surface.
The full pipeline is covered: search/discover markets and series, inspect datasets, list daily Parquet files, and obtain signed download URLs, plus a recorder health check. Minor gaps exist—events are only reachable via search, and there is no direct query tool beyond price history and raw file download.
Read-only Polymarket search, market details, order books, price history, and market cards.
Order-book depth & history for Polymarket, Kalshi & Limitless. Keyless demo, key for full access.
Polymarket in your AI: market rules, real fill costs, who is trading, top traders. Read-only.
Live prediction markets: Polymarket + Kalshi prices, odds, order books. Pay-per-call USDC, no key.
