Skip to main content
Glama
bybit-exchange

Bybit MCP Server

Official

queryStrategyList

Read-only

Fetch and filter your Bybit trading strategies by status, symbol, type, or time range. Monitor active strategies, inspect stopped ones, and paginate through large result sets.

Instructions

Retrieve a list of strategies with filtering options and pagination support.

When to use:

  • Check status of specific strategy by strategyId

  • Monitor all running strategies

  • Review completed strategies for performance analysis

  • Filter strategies by symbol, type, or time period

Query modes:

  1. Exact lookup: Provide strategyId to get specific strategy details

  2. Filtered list: Use symbol, category, strategyType, status filters

  3. Time range: Use beginTimeE0 and endTimeE0 for date range queries

  4. Paginated: Use cursor and pageSize for large result sets

Strategy Status Values:

  • 2: Running - Strategy is actively executing

  • 3/4: Terminated - Strategy has stopped (check terminateType for reason)

  • 5: Paused - Strategy is temporarily paused

  • 6: Untriggered - Conditional strategy waiting for trigger price

Important notes:

  • Strategies are sorted by creation time (newest first)

  • Use cursor for pagination (nextCursor in response)

  • Maximum pageSize: 50

  • Default pageSize: 20

  • Time filters use Unix timestamp in seconds

Agent hint: Use this endpoint when user asks about their strategies, wants to check strategy status, or needs to review strategy performance. Common queries: "show my strategies", "check TWAP strategy status", "what strategies are running on BTCUSDT". positionValue is the total strategy value for value-based orders (maxValue for POV), and is empty for quantity-based strategies. Inspect terminateType and terminateRemark when a strategy stops: 28 means the POV quantity or value cap was reached (normal completion); 31 means no fills for 24 hours in quantity/value-cap mode (safety stop); 32 means the order book was empty and value could not be converted to quantity. Do not automatically restart a stopped strategy.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cursorNo
statusNo
symbolNo
categoryNo
pageSizeNo
endTimeE0No
strategyIdNo
beginTimeE0No
strategyTypeNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.1.11

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses sorting order (newest first), pagination mechanics (nextCursor, max/default pageSize), time unit (Unix seconds), status code meanings (2/3/4/5/6), and terminateType codes (28/31/32) with operational guidance (do not auto-restart). This far exceeds what annotations or schema provide.

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 description is lengthy but well-structured with an intro, usage bullets, query modes, status values, and notes. Each section adds distinct value, though the agent hint partly duplicates the 'When to use' bullets, making it slightly more verbose than necessary.

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 a tool with no output schema Syndicate, the description covers key return semantics: nextCursor, positionValue semantics, terminateType meanings, and explicit guidance on terminal states. This is more than enough for an agent to invoke the tool and interpret results correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% description coverage, so the description must carry full parameter semantics. It covers every query mode: strategyId for exact lookup, symbol/category/strategyType/status for filtering, beginTimeE0/endTimeE0 for time range, and cursor/pageSize for pagination, including defaults and limits.

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?

The description opens with a clear statement: 'Retrieve a list of strategies with filtering options and pagination support.' It then enumerates query modes and use cases, making it unmistakably distinct from strategy-creation or mutation siblings like createTwapStrategy and stopStrategy.

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 'When to use' section gives concrete scenarios (checking specific strategy status, monitoring running strategies, reviewing completed for performance) and even example user queries in the agent hint. It stops short of explicitly naming alternatives or exclusions, so it misses a 5.

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