Skip to main content
Glama
Sign In

Vike Data API

by io.vike
OverviewDiscussionsAdmin

Stream Info

stream_info
Read-onlyIdempotent

How to use the vike WebSocket stream (wss://stream.vike.io/v1/stream/), read off the server's own registry: every path (hl, hl-cohorts, onchain, polymarket) with its channels; per channel its filter keys, each a list (with its maximum length), one value, a number (min_usd and the other min_ keys) or a boolean (contract: true or false, not a string), with the allowed values or the server's own message for a bad one, and its defaults (hl.fills: min_usd 1000 unless given); the REST catch-up route of each path; the limits (ONE connection per API key per path and THREE per account per path, newest wins with close 4410; 100 subscriptions per connection; a ping every 15 s); the close codes; cursor retention (3 days) and the subscribe message's shape. Check a filter with stream_check_filter and read missed events with stream_events.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "stream_info"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so safety and purity are covered. The description adds domain behavior such as connection limits, close codes, and cursor retention, but these are facts about the stream API being documented rather than traits of the tool itself. It does not disclose whether an API key is required or how the response is structured.

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

Conciseness2/5

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

The entire description is a single dense run-on sentence with nested parentheses and semicolons, making it hard to scan. While every detail might be valuable, the lack of front-loaded summary or bullet-like structure harms readability significantly.

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 zero parameters, read-only annotations, and no output schema, the description provides extensive detail about what information is available (paths, channels, filters, limits, close codes, retention). It does not describe the response format, but given the tool's nature as a documentation lookup, the content coverage is strong.

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?

The tool takes zero parameters, so the baseline is 4. There is no parameter semantics to explain, and the description does not need to compensate for any schema gaps.

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?

The description clearly identifies the resource: documentation for the vike WebSocket stream, covering paths, channels, filters, limits, close codes, and subscribe message shape. It distinguishes itself from siblings by naming stream_check_filter and stream_events for related tasks. However, it lacks a crisp verb like 'Returns' or 'Provides' and reads more like a content dump than a purpose statement.

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 explicitly routes the agent to stream_check_filter for validating filters and stream_events for missed events, which clarifies alternatives. It does not state when not to use this tool or mention stream_connections, but the implied use case—learning the stream setup—is clear.

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 toolsInspect
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.

Resources