Skip to main content
Glama

detect_position_mode

Check current position mode (one-way or hedge) and get recommended positionIdx for orders on Bybit exchange to ensure proper trade execution.

Instructions

Detect current position mode (one-way vs hedge) and get recommended positionIdx for orders

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
categoryYesCategory (spot, linear, inverse, etc.)
symbolNoSymbol (e.g., ETHUSDT) - optional, will check all positions if not provided

Implementation Reference

  • The core handler function that implements the detect_position_mode tool logic. It fetches current positions via getPositions, analyzes whether the account is in 'one-way' or 'hedge' mode by checking for simultaneous long/short positions or positionIdx values, and returns the detected mode, recommended positionIdx, explanation, and current positions list.
    async detectPositionMode(
      category: string,
      symbol?: string
    ): Promise<{
      positionMode: 'one-way' | 'hedge';
      recommendedPositionIdx: string;
      explanation: string;
      currentPositions: any[];
    }> {
      try {
        // Get current positions
        const currentPositions = await this.getPositions(category, symbol);
        
        if ('error' in currentPositions) {
          return {
            positionMode: 'one-way',
            recommendedPositionIdx: '0',
            explanation: `Could not check positions: ${currentPositions.error}. Defaulting to one-way mode.`,
            currentPositions: []
          };
        }
    
        const positions = currentPositions.result.list;
        
        if (positions.length === 0) {
          return {
            positionMode: 'one-way',
            recommendedPositionIdx: '0',
            explanation: 'No existing positions found. Defaulting to one-way mode (positionIdx: 0).',
            currentPositions: []
          };
        }
    
        // Check if we have separate long/short positions (hedge mode)
        const hasLongPosition = positions.some(p => p.side === 'Buy' && parseFloat(p.size) > 0);
        const hasShortPosition = positions.some(p => p.side === 'Sell' && parseFloat(p.size) > 0);
        
        if (hasLongPosition && hasShortPosition) {
          return {
            positionMode: 'hedge',
            recommendedPositionIdx: '1', // Default to long for new orders
            explanation: 'Hedge mode detected (both long and short positions exist). Use positionIdx: 1 for long, 2 for short.',
            currentPositions: positions
          };
        } else if (hasLongPosition || hasShortPosition) {
          // Check if positions have positionIdx > 0 (indicating hedge mode setup)
          const hasHedgePositions = positions.some(p => p.positionIdx > 0);
          
          if (hasHedgePositions) {
            return {
              positionMode: 'hedge',
              recommendedPositionIdx: '1',
              explanation: 'Hedge mode detected (positions have positionIdx > 0). Use positionIdx: 1 for long, 2 for short.',
              currentPositions: positions
            };
          } else {
            return {
              positionMode: 'one-way',
              recommendedPositionIdx: '0',
              explanation: 'One-way mode detected (single position type with positionIdx: 0).',
              currentPositions: positions
            };
          }
        } else {
          return {
            positionMode: 'one-way',
            recommendedPositionIdx: '0',
            explanation: 'One-way mode detected (no active positions, but account configured for one-way).',
            currentPositions: positions
          };
        }
    
      } catch (error: any) {
        return {
          positionMode: 'one-way',
          recommendedPositionIdx: '0',
          explanation: `Error detecting position mode: ${error.message}. Defaulting to one-way mode.`,
          currentPositions: []
        };
      }
    }
  • The input schema definition for the detect_position_mode tool, registered in the MCP server's listTools response. Specifies required 'category' parameter and optional 'symbol'.
    {
      name: 'detect_position_mode',
      description: 'Detect current position mode (one-way vs hedge) and get recommended positionIdx for orders',
      inputSchema: {
        type: 'object',
        properties: {
          category: {
            type: 'string',
            description: 'Category (spot, linear, inverse, etc.)',
          },
          symbol: {
            type: 'string',
            description: 'Symbol (e.g., ETHUSDT) - optional, will check all positions if not provided',
          },
        },
        required: ['category'],
      },
    },
  • src/index.ts:972-985 (registration)
    The switch case registration in the MCP CallToolRequestSchema handler that routes detect_position_mode tool calls to the BybitService.detectPositionMode method and returns the JSON-stringified result.
    case 'detect_position_mode': {
      const result = await this.bybitService.detectPositionMode(
        typedArgs.category,
        typedArgs.symbol
      );
      return {
        content: [
          {
            type: 'text',
            text: JSON.stringify(result, null, 2),
          },
        ],
      };
    }
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions detecting position mode and getting a recommendation, but doesn't specify whether this is a read-only operation, if it requires authentication, what happens if no positions exist, or any rate limits. For a tool with potential trading implications, this is a significant gap in transparency.

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?

The description is a single, efficient sentence that front-loads the core functionality ('detect current position mode') and adds the secondary benefit ('get recommended positionIdx'). There is no wasted verbiage, making it easy for an agent to parse quickly.

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?

Given the complexity of position mode detection in trading contexts, the description is incomplete. No annotations exist to clarify safety or behavior, and there's no output schema to explain the return values (e.g., what 'positionIdx' means or the format of the detection result). This leaves critical gaps for an agent to use the tool effectively without additional context.

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?

The input schema has 100% description coverage, with clear docs for 'category' and 'symbol'. The description doesn't add any parameter-specific details beyond what the schema provides, such as examples for 'category' values or clarification on 'positionIdx'. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.

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?

The description clearly states the tool's purpose: 'Detect current position mode (one-way vs hedge) and get recommended positionIdx for orders'. It specifies the verb ('detect'), the resource ('position mode'), and the additional output ('recommended positionIdx'). However, it doesn't explicitly differentiate from sibling tools like 'get_positions' or 'set_margin_mode', which might also relate to position management.

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 on when to use this tool versus alternatives. It doesn't mention prerequisites, such as needing an active position or specific account settings, nor does it compare to siblings like 'get_positions' for checking positions or 'set_margin_mode' for configuring modes. This lack of context leaves the agent to infer usage scenarios.

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