Skip to main content
Glama
Coinversaa

Coinversaa Pulse

Official
by Coinversaa
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Recent Closed Lifecycles

pulse_lifecycles_recent
Read-onlyIdempotent

Monitor recently closed position lifecycles across every Hyperliquid wallet, filterable by coin, notional, hold duration, and time window, with MAE/MFE and liquidation flags.

Instructions

Global feed of the most recently CLOSED position lifecycles across ALL wallets — 'what just closed exchange-wide right now'. Reads the corrected position_lifecycles_full table: includes MAE/MFE (when backfilled), a liquidation flag, and optional spot. Cross-wallet successor to pulse_recent_closed_positions. Filter by coin, minNotional, hold-duration range, and time window. Note: the very freshest closes may not have MAE/MFE yet — the risk backfill lags real-time, so recent rows can show null MAE/MFE. Lifecycles are a rolling 90-day window; the table's first day is not exposed by the API — see data_coverage.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
coinNoFilter by coin symbol (e.g. BTC, ETH, SOL). For builder dex: prefix:COIN (e.g. xyz:SILVER).
limitNoNumber of lifecycles to return.
sinceNoTime window: e.g. '10m' (minutes), '1h' (hours), '1d' (days)1h
includeSpotNoInclude spot (@-prefixed) pairs. Default false (perps only).
maxDurationNoMaximum hold duration in milliseconds (e.g. 1000 for sub-second HFT).
minDurationNoMinimum hold duration in milliseconds (e.g. 60000 for >= 1 minute).
minNotionalNoMinimum notional in USD (peak_size * entry_vwap), e.g. 100000 for $100K+ positions.
useToonFormatNoReturn data in compact toon format (default: true). Set to false for standard JSON.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.8.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already establish a safe read-only, idempotent, open-world profile, and the description layers on genuinely useful operational context: MAE/MFE values may be null because the risk backfill lags real-time, the lifecycle table is a rolling 90-day window, and the first day is not API-exposed (routed to data_coverage). This discloses data-freshness and coverage caveats the agent cannot infer from structured fields.

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 feed description and source-table caveats are front-loaded and every sentence carries information, but the prose is dense with parentheticals and near the upper end of what an agent needs to parse. Slightly trimming the field-recitation sentence would improve it.

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 compensates by naming the returned content (MAE/MFE, liquidation flag, optional spot) and the source table, plus coverage limits and a redirect to data_coverage. For an 8-parameter read tool this is complete enough to call correctly.

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%, so every parameter (coin, limit, since, includeSpot, min/maxDuration, minNotional, useToonFormat) is already documented, including units like milliseconds for duration and USD notional. The description's 'filter by coin, minNotional, hold-duration range, and time window' merely restates these without adding format or default semantics, so baseline 3 is appropriate.

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 + scope: a global feed of recently CLOSED position lifecycles across ALL wallets. It explicitly positions itself as the 'cross-wallet successor to pulse_recent_closed_positions', so an agent can distinguish it from that sibling 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.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The framing 'what just closed exchange-wide right now' plus the named predecessor clearly signals the use case (global, not per-trader). It does not explicitly state when to prefer the sibling pulse_trader_lifecycles or pulse_recent_closed_positions in edge cases, so it falls short of a full when/when-not statement.

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

Deploy Server

Other Tools