Vike Data API

Alerts Events

alerts_events

Read-onlyIdempotent

Read the events the current user's alert rules produced, oldest first (the feed behind GET /v1/alerts/events). Page forward by passing the returned next_cursor back as cursor; an empty page returns the same cursor, so a poller keeps it and asks again. Each event has id, rule_id, alert_label, alert_type, created_at, event (what happened: the transfer, fill, liquidation, bias flip, proximity crossing, Polymarket trade, price move or resolution) and delivery: one item per channel it went to with id, channel, channel_key, status, attempts, last_attempt_at, next_attempt_at (while it waits) and last_error as a code only (http 500, timeout, network). A delivery's id is what alerts_resend_delivery takes. Events are kept for 15 days. Read-only; only the user's own rules appear.

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": "alerts_events"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Events per page, 1 to 500. Default 100.
`cursor`	No	The previous page's `next_cursor`. Omit for the oldest retained event.
`rule_id`	No	Only the events of this alert (its id from alerts_list).

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 28, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description still adds substantial context: 15-day retention, scope limited to the user's own rules, the non-obvious empty-page/same-cursor behavior, and the shape of both event and delivery records including last_error being a code only. This is behavior beyond what the structured fields supply.

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?

Front-loaded with purpose and pagination behavior, and nearly every sentence carries operational information. The enumeration of event types and delivery fields is long but serves the agent's need to interpret results without an output schema.

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 takes on the burden of describing return values and does so thoroughly (event fields, delivery fields, error code format), plus retention and pagination quirks. Nothing an agent needs to call or interpret this tool correctly is missing.

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 coverage is 100% and each parameter is documented there, so baseline 3 applies. The description reinforces cursor semantics and rule scoping but adds little syntax or format detail the schema does not already carry, and never mentions the limit parameter.

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 and resource ('Read the events the current user's alert rules produced') plus ordering ('oldest first') and even maps it to the underlying endpoint GET /v1/alerts/events. An agent can distinguish this from alerts_list (rules) and stream_events without opening a schema.

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?

Explains the polling workflow (pass next_cursor back as cursor; empty page returns the same cursor so a poller keeps it) and cross-links to alerts_resend_delivery for the delivery id, which is exactly the chaining an agent needs. It stops short of explicit exclusions (e.g. 'for the rule definitions themselves use alerts_list'), so not a 5.

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.