Skip to main content
Glama

get_open_orders

Retrieve active trading orders from Bybit exchange to monitor positions, manage trades, and track execution status across various categories and symbols.

Instructions

Get open orders

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
categoryYesCategory (spot, linear, inverse, etc.)
symbolNoSymbol (e.g., BTCUSDT)
orderIdNoOrder ID
orderLinkIdNoOrder link ID
orderFilterNoOrder filter
limitNoNumber of orders to retrieve

Implementation Reference

  • Core handler function implementing the get_open_orders tool by constructing API parameters and calling the Bybit /v5/order/realtime endpoint via makeBybitRequest.
    async getOpenOrders(
      category: string,
      symbol?: string,
      orderId?: string,
      orderLinkId?: string,
      orderFilter?: string,
      limit: number = 50
    ): Promise<BybitResponse<{ list: Order[] }> | { error: string }> {
      const params: any = { category, limit };
      if (symbol) params.symbol = symbol;
      if (orderId) params.orderId = orderId;
      if (orderLinkId) params.orderLinkId = orderLinkId;
      if (orderFilter) params.orderFilter = orderFilter;
      return this.makeBybitRequest('/v5/order/realtime', 'GET', params);
    }
  • MCP CallToolRequest handler that receives tool arguments, calls BybitService.getOpenOrders, and formats the response as MCP content.
    case 'get_open_orders': {
      const result = await this.bybitService.getOpenOrders(
        typedArgs.category,
        typedArgs.symbol,
        typedArgs.orderId,
        typedArgs.orderLinkId,
        typedArgs.orderFilter,
        typedArgs.limit
      );
      return {
        content: [
          {
            type: 'text',
            text: JSON.stringify(result, null, 2),
          },
        ],
      };
    }
  • src/index.ts:350-384 (registration)
    Tool registration in the ListTools response, defining the name, description, and input schema for get_open_orders.
    {
      name: 'get_open_orders',
      description: 'Get open orders',
      inputSchema: {
        type: 'object',
        properties: {
          category: {
            type: 'string',
            description: 'Category (spot, linear, inverse, etc.)',
          },
          symbol: {
            type: 'string',
            description: 'Symbol (e.g., BTCUSDT)',
          },
          orderId: {
            type: 'string',
            description: 'Order ID',
          },
          orderLinkId: {
            type: 'string',
            description: 'Order link ID',
          },
          orderFilter: {
            type: 'string',
            description: 'Order filter',
          },
          limit: {
            type: 'number',
            description: 'Number of orders to retrieve',
            default: 50,
          },
        },
        required: ['category'],
      },
    },
  • JSON schema defining the input parameters for the get_open_orders tool, including required 'category' and optional filters.
    inputSchema: {
      type: 'object',
      properties: {
        category: {
          type: 'string',
          description: 'Category (spot, linear, inverse, etc.)',
        },
        symbol: {
          type: 'string',
          description: 'Symbol (e.g., BTCUSDT)',
        },
        orderId: {
          type: 'string',
          description: 'Order ID',
        },
        orderLinkId: {
          type: 'string',
          description: 'Order link ID',
        },
        orderFilter: {
          type: 'string',
          description: 'Order filter',
        },
        limit: {
          type: 'number',
          description: 'Number of orders to retrieve',
          default: 50,
        },
      },
      required: ['category'],
    },
Behavior2/5

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

No annotations are provided, so the description carries full burden for behavioral disclosure. 'Get open orders' implies a read-only operation, but the description doesn't clarify whether this requires authentication, has rate limits, returns paginated results, or what format the output takes. For a tool with 6 parameters and no output schema, this leaves significant behavioral questions unanswered.

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

Conciseness3/5

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

The description is extremely concise at just three words, but this brevity comes at the cost of being under-specified. While it's not verbose or repetitive, it fails to provide essential context that would help an agent understand and use the tool effectively. The single phrase doesn't represent appropriate conciseness for a tool with 6 parameters and multiple sibling alternatives.

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 6 parameters, no annotations, no output schema, and multiple sibling tools in a trading context, the description is inadequate. It doesn't explain what constitutes an 'open order' versus historical orders, doesn't mention authentication requirements for accessing trading data, and provides no context about the trading platform or exchange this interacts with. The description leaves too many contextual questions unanswered.

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 all parameters are documented in the schema. The description adds no additional parameter information beyond what's already in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no parameter information in the description. The description doesn't compensate for any gaps because there are none in the schema.

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

Purpose2/5

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

The description 'Get open orders' is a tautology that essentially restates the tool name. It doesn't specify what type of orders (trading orders), from what system (exchange/trading platform), or what 'open' means in this context. While the name suggests it retrieves active trading orders, the description adds no meaningful clarification beyond the name itself.

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?

The description provides no guidance about when to use this tool versus alternatives. With sibling tools like 'get_order_history' and 'cancel_order' available, there's no indication whether this tool retrieves only currently active orders while 'get_order_history' retrieves completed/canceled ones, or whether this should be used before attempting to cancel orders. No prerequisites or context for usage are mentioned.

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

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/kondisettyravi/mcp-bybit-node'

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