Skip to main content
Glama
Sign In
Keel — Hyperliquid trading strategies

Keel — Hyperliquid trading strategies

by keel-trade
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Get Backtest Positions

keel_backtest_positions
Read-onlyIdempotent

Review one completed backtest's entry-to-exit positions: get win rate and P&L summaries, page trade details by asset or date, or compare two runs for one asset.

Instructions

The positions of ONE completed backtest, entry to exit — what drove its result. Default: a summary (count, win rate, P&L by asset, five best, five worst). asset and/or start/end: one page of positions (entry/exit time and price, side, entry value, net P&L, fees) and a cursor. compare_to pairs two runs' positions for one asset.

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": {
      "backtest_id": "<backtest_id>"
    },
    "name": "keel_backtest_positions"
  }
}

Input Schema

NameRequiredDescriptionDefault
endNoWindow end on entry time, YYYY-MM-DD (exclusive).
sortNoRow order within a scope: `pnl` = largest absolute P&L first, `time` = entry time.pnl
assetNoOne asset's positions (e.g. 'BTC').
limitNoMaximum rows per page within a scope (1-100).
startNoWindow start on entry time, YYYY-MM-DD (inclusive).
cursorNoThe `cursor` from a previous page.
compare_toNoA second backtest_id; with `asset`, pairs the two runs' positions by nearest entry time.
backtest_idYesA completed run's backtest_id.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.9.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the default return shape when no filters are given, the cursor-based pagination contract, and the fact that compare_to requires an asset to pair positions. It does not mention rate limits or data freshness, but for a read-only tool the disclosure is solid.

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

Conciseness5/5

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

Three dense sentences, no filler, and the core identity of the tool is front-loaded before the mode breakdown. The use of inline code for parameter names makes the branching structure skimmable. Every sentence carries a distinct piece of information.

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 an 8-parameter tool with an output schema, the agent needs to know which parameter combinations produce which response shape, how to paginate, and what the default does — all three are present. Since the output schema exists, the brief enumeration of returned fields is bonus clarity rather than a missing requirement.

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 would be 3, but the description adds meaning the schema cannot express: the interaction rules binding parameters together — that `asset`/`start`/`end` switch the response from summary to a paginated page, and that `compare_to` only pairs positions when combined with `asset`. That is node-level semantics beyond per-field docs.

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?

States a specific verb+resource with scope: 'The positions of ONE completed backtest, entry to exit — what drove its result.' The emphasis on 'ONE' implicitly separates it from multi-run siblings like keel_backtest_compare, but no sibling is named explicitly, so an agent must infer the boundary rather than read it.

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 three operating modes are laid out with the parameter combinations that select them: default = summary, `asset` and/or `start`/`end` = one paginated page, `compare_to` = paired positions. That is clear conditional guidance, though it never names the sibling tools (keel_backtest_summarize, keel_backtest_compare) that would let an agent route between them by name.

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