Skip to main content
Glama

Polymarket Chainlink Prices

polymarket_chainlink_prices
Read-onlyIdempotent

The price Polymarket's crypto up/down markets resolve on: Chainlink Data Streams prices, as Polymarket's live-data socket relays them for its crypto markets, for btc, eth, sol, xrp, doge, bnb, hype or zec in USD, from 2026-11-06 09:24:15 UTC to about a minute ago (rows are stored once a minute). series=price (default) is the price, about one tick a second; series=twap60 is its 60-second time-weighted average. interval=1s (default) returns every tick; 1m, 5m, 15m, 1h, 4h or 1d return one row per bucket aligned to UTC, the FIRST tick at or after the bucket's start: the price an up/down market compares at the start and the end of its window. For a 5-minute, 15-minute or hourly market from S to E pass interval = its length (5m, 15m or 1h), from_ms=S and to_ms=E+1: two rows, the price at its start and at its end. 4-HOUR AND DAILY MARKETS FOLLOW US EASTERN TIME, off the UTC grid of the 4h and 1d buckets: pass interval=1m with from_ms=S and to_ms=S+60000, and again with from_ms=E and to_ms=E+60000. Returns {rows, has_more, next_cursor}; each row {ts_ms (bucket start, epoch ms), price_ts_ms (the tick's own time), price (USD)}. from_ms is inclusive and to_ms exclusive, both on ts_ms. While has_more is true pass next_cursor back as cursor; a page can hold fewer rows than limit while has_more is true, and within the last two minutes a page ends at the last row stored so far. About 1.6% of seconds have no row and nothing is filled in: about 600 single seconds a day, about 17 gaps a day of 2 to 5 seconds, and about 85 a day of 6 to 30 seconds that nearly always every coin skips at once; the longest, 74 seconds, was 2026-11-06 11:15:33 to 11:16:46 UTC. Compare price_ts_ms with ts_ms. A page is 100 rows by default and at most 10,000.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "symbol": "<symbol>"
    },
    "name": "polymarket_chainlink_prices"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoRows per page (default 100, max 10000, as the REST route).
to_msNoBucket start, epoch milliseconds, EXCLUSIVE; must be greater than from_ms. Omit for up to now.
cursorNoThe previous page's next_cursor, passed back unchanged.
seriesNoprice = the price, about one tick a second (default); twap60 = its 60-second time-weighted average.price
symbolYesbtc, eth, sol, xrp, doge, bnb, hype or zec; btcusd, btc/usd and BTC-USD work too, in any case.
from_msNoBucket start, epoch MILLISECONDS, inclusive. Omit for the first recorded tick.
intervalNo1s = every tick (default); wider = one row per UTC bucket, its first tick.1s

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the read-only, idempotent annotations, the description discloses critical behavioral details: one-row-per-minute storage, roughly one-tick-per-second cadence, known gap frequencies and durations, pagination behavior with has_more and next_cursor, and the special last-two-minutes page boundary. This is exceptionally transparent for an agent invoking the tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The content is front-loaded and nearly every detail is useful for correct usage, but it is delivered as one long run-on paragraph with repeated defaults and no structural breaks. It would be easier to scan as bullets or short sections.

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?

For a complex time-series tool with no output schema, the description supplies the return shape, row fields, pagination contract, data gaps, interval alignment rules, supported symbols, and page-size limits. An agent has enough information to call it correctly without opening other docs.

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 100%, so the baseline is 3, but the description adds substantial meaning: it explains UTC bucket alignment and first-tick selection, clarifies that from_ms and to_ms apply to ts_ms, and provides market-window query recipes including the US Eastern offset for 4h and 1d markets. Some schema-level details remain carried by the schema itself.

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 states a precise resource: Chainlink Data Streams prices relayed by Polymarket for crypto up/down market resolution, covering named symbols in USD. It clearly distinguishes this data from other Polymarket sibling tools by identifying the resolution price source and series/interval semantics.

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?

It gives very clear usage context and detailed query recipes for 5-minute, 15-minute, hourly, 4-hour, and daily market windows, including the exact interval and from_ms/to_ms values. It does not explicitly name alternative tools or state when not to use this one, which keeps it below a 5.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.