Skip to main content
Glama

get_order_history

Retrieve detailed order history from Bybit by specifying category, symbol, order ID, and time range. Use this tool to monitor past orders, analyze trading activity, and manage portfolio performance.

Instructions

Get order history

Args:
    category (str): Category (spot, linear, inverse, etc.)
    symbol (Optional[str]): Symbol (e.g., BTCUSDT)
    orderId (Optional[str]): Order ID
    orderLinkId (Optional[str]): Order link ID
    orderFilter (Optional[str]): Order filter
    orderStatus (Optional[str]): Order status
    startTime (Optional[int]): Start time in milliseconds
    endTime (Optional[int]): End time in milliseconds
    limit (int): Number of orders to retrieve

Returns:
    Dict: Order history

Example:
    get_order_history("spot", "BTCUSDT", "123456789", "link123", "Order", "Created", 1625097600000, 1625184000000, 10)

Reference:
    https://bybit-exchange.github.io/docs/v5/order/order-list

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
categoryYesCategory (spot, linear, inverse, etc.)
endTimeNoEnd time in milliseconds
limitNoNumber of orders to retrieve
orderFilterNoOrder filter
orderIdNoOrder ID
orderLinkIdNoOrder link ID
orderStatusNoOrder status
startTimeNoStart time in milliseconds
symbolNoSymbol (e.g., BTCUSDT)

Implementation Reference

  • MCP tool handler for get_order_history: decorated with @mcp.tool(), defines input schema via Pydantic Field, delegates to BybitService.get_order_history, handles errors and logging.
    @mcp.tool()
    def get_order_history(
        category: str = Field(description="Category (spot, linear, inverse, etc.)"),
        symbol: Optional[str] = Field(default=None, description="Symbol (e.g., BTCUSDT)"),
        orderId: Optional[str] = Field(default=None, description="Order ID"),
        orderLinkId: Optional[str] = Field(default=None, description="Order link ID"),
        orderFilter: Optional[str] = Field(default=None, description="Order filter"),
        orderStatus: Optional[str] = Field(default=None, description="Order status"),
        startTime: Optional[int] = Field(default=None, description="Start time in milliseconds"),
        endTime: Optional[int] = Field(default=None, description="End time in milliseconds"),
        limit: int = Field(default=50, description="Number of orders to retrieve")
    ) -> Dict:
        """
        Get order history
    
        Args:
            category (str): Category (spot, linear, inverse, etc.)
            symbol (Optional[str]): Symbol (e.g., BTCUSDT)
            orderId (Optional[str]): Order ID
            orderLinkId (Optional[str]): Order link ID
            orderFilter (Optional[str]): Order filter
            orderStatus (Optional[str]): Order status
            startTime (Optional[int]): Start time in milliseconds
            endTime (Optional[int]): End time in milliseconds
            limit (int): Number of orders to retrieve
    
        Returns:
            Dict: Order history
    
        Example:
            get_order_history("spot", "BTCUSDT", "123456789", "link123", "Order", "Created", 1625097600000, 1625184000000, 10)
    
        Reference:
            https://bybit-exchange.github.io/docs/v5/order/order-list
        """
        try:
            result = bybit_service.get_order_history(
                category, symbol, orderId, orderLinkId,
                orderFilter, orderStatus, startTime, endTime, limit
            )
            if result.get("retCode") != 0:
                logger.error(f"Failed to get order history: {result.get('retMsg')}")
                return {"error": result.get("retMsg")}
            return result
        except Exception as e:
            logger.error(f"Failed to get order history: {e}", exc_info=True)
            return {"error": str(e)}
  • BybitService helper method that directly calls the pybit.unified_trading.HTTP client.get_order_history API.
    def get_order_history(self, category: str, symbol: Optional[str] = None,
                          orderId: Optional[str] = None, orderLinkId: Optional[str] = None,
                          orderFilter: Optional[str] = None, orderStatus: Optional[str] = None,
                          startTime: Optional[int] = None, endTime: Optional[int] = None,
                          limit: int = 50) -> Dict:
        """
        Get order history
    
        Args:
            category (str): Category (spot, linear, inverse, etc.)
            symbol (Optional[str]): Symbol (e.g., BTCUSDT)
            orderId (Optional[str]): Order ID
            orderLinkId (Optional[str]): Order link ID
            orderFilter (Optional[str]): Order filter
            orderStatus (Optional[str]): Order status
            startTime (Optional[int]): Start time in milliseconds
            endTime (Optional[int]): End time in milliseconds
            limit (int): Number of orders to retrieve
    
        Returns:
            Dict: Order history
        """
        return self.client.get_order_history(
            category=category,
            symbol=symbol,
            orderId=orderId,
            orderLinkId=orderLinkId,
            orderFilter=orderFilter,
            orderStatus=orderStatus,
            startTime=startTime,
            endTime=endTime,
            limit=limit
        )
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions what parameters are available but doesn't describe important behaviors: whether this is a read-only operation, if it requires authentication, how results are paginated (beyond the limit parameter), or what happens when multiple filters are combined. The example shows a call but doesn't explain the return format beyond 'Dict: Order history'.

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?

Well-structured with clear sections (Args, Returns, Example, Reference). The description is appropriately sized for a tool with 9 parameters. The 'Get order history' statement is front-loaded, though it could be more informative. The example is helpful but could be better integrated with the parameter explanations.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 9 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain the return format beyond 'Dict: Order history', doesn't mention authentication requirements, doesn't describe error conditions, and doesn't provide guidance on parameter combinations. The reference link helps but doesn't compensate for missing contextual information.

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 description coverage is 100%, so the schema already documents all parameters thoroughly. The description repeats parameter information in the Args section but doesn't add meaningful context beyond what's in the schema - no explanation of how parameters interact, what 'orderFilter' values are valid, or what 'orderStatus' options exist. Baseline 3 is appropriate when schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'Get order history' which is a clear verb+resource combination, but it's quite basic and doesn't differentiate from sibling tools like 'get_open_orders' or 'get_positions'. It doesn't specify what kind of history (all orders vs filtered) or scope beyond the parameters listed.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like 'get_open_orders' or 'get_positions'. The description provides parameter information but doesn't explain the tool's role in the broader API context or when it's the appropriate choice for different querying needs.

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

Install Server

Other Tools

Related Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/dlwjdtn535/mcp-bybit-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server