Vike Data API

Stream Events

stream_events

Read-onlyIdempotent

Stored events of ONE stream channel after a cursor, oldest first, with the stream's own filters: the REST catch-up of wss://stream.vike.io, for what a socket missed or a quick look without a socket. Returns {events: [{cursor, event}], next_cursor, has_more}; event is byte for byte what the WebSocket frame carried. An idle window of the on-demand channel is an item {cursor, gap} in its place. Pass next_cursor back as cursor for the next page; a page at the end returns the channel head, so an empty page on a quiet channel returns the same cursor. Events are kept 3 days: an older cursor is refused with a resume cursor in the message. since_ms starts at an ARRIVAL time instead of a cursor. Delivery is at least once: dedupe on event.event_id. hl.fills without min_usd is min_usd 1000, as on the socket (0 = every fill). Every channel stream_info lists is accepted, including one the stream does not run yet (a subscribe there answers unknown_channel): its pages are empty, like a quiet channel's. Same data as GET /v1/{hyperliquid,onchain,polymarket}/stream-events.

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": {
      "channel": "<channel>"
    },
    "name": "stream_events"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Events per page, 1 to 1000 (default 200).
`cursor`	No	`next_cursor` of the previous page or the `cursor` of a stream frame. Omit (and omit since_ms) for the oldest retained event.
`filter`	No	The channel's filter keys as on a subscribe, e.g. `{"coin": ["BTC"], "min_usd": 100000}`. An unknown or channel-foreign key is refused.
`channel`	Yes	A stream channel, e.g. `hl.fills`, `hl.liquidations`, `chain.transfers`, `pm.trades`; stream_info lists them all. Required.
`since_ms`	No	Epoch MILLISECONDS: start after this arrival time instead of a cursor. Not together with `cursor`.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 2, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already carry the read-only/idempotent profile, and the description still layers on real behavior: at-least-once delivery with dedupe on event.event_id, 3-day retention with a refused older cursor and resume cursor in the error, gap items {cursor, gap} for idle windows, and end-of-page cursor behavior on a quiet channel. These are exactly the traits an agent cannot infer from annotations.

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?

The core action is front-loaded in the first clause and every sentence carries a functional fact with no filler. It is a dense, single-paragraph block of edge cases, though, which makes it slower to scan than a lightly segmented version would be.

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?

With no output schema, the description supplies the return shape ({events: [{cursor, event}], next_cursor, has_more}), the byte-for-byte fidelity of event payloads, the retention limit, and the empty-page/unknown-channel edge cases. Nothing an agent needs to call it correctly or interpret the response is missing.

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 baseline is 3, but the description adds meaning the schema lacks: since_ms starts at an arrival time, hl.fills without min_usd defaults to 1000 (0 = every fill), an unknown/foreign filter key is refused, and any channel stream_info lists is accepted even if the stream is not running. Only the limit/cursor interplay is left entirely to the schema.

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+resource with precise scope: stored events of ONE stream channel after a cursor, oldest first, replayed with the channel's own subscription filters. It grounds the tool against siblings by naming stream_info as the channel enumerator and by mapping it to the equivalent REST endpoint, so an agent can place it immediately.

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?

Gives concrete use cases ('what a socket missed or a quick look without a socket') and explains the cursor vs since_ms decision plus the pagination loop. It stops short of explicit exclusions or naming a sibling to use instead when live streaming is preferred, so it is clear context rather than full routing guidance.

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

All Vike Data API tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.