Skip to main content
Glama
code-rabi

Interactive Brokers MCP Server

by code-rabi

get_positions

Retrieve current trading positions from Interactive Brokers accounts to monitor portfolio holdings and track investment exposure.

Instructions

Get current positions. Usage: {} or { "accountId": "<id>" }.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
accountIdYes

Implementation Reference

  • src/tools.ts:57-63 (registration)
    Registration of the 'get_positions' MCP tool using server.tool(). It specifies the name, description, input schema (GetPositionsZodShape), and handler function.
    // Register get_positions tool
    server.tool(
      "get_positions", 
      "Get current positions. Usage: `{}` or `{ \"accountId\": \"<id>\" }`.",
      GetPositionsZodShape,
      async (args) => await handlers.getPositions(args)
    );
  • Zod shape definition for 'get_positions' input validation, requiring an 'accountId' string.
    export const GetPositionsZodShape = {
      accountId: z.string()
    };
  • Primary handler function in ToolHandlers class that executes the get_positions tool logic. Validates input, ensures gateway and auth readiness, calls IBClient.getPositions, formats result as MCP response.
    async getPositions(input: GetPositionsInput): Promise<ToolHandlerResult> {
      try {
        if (!input.accountId) {
          return {
            content: [
              {
                type: "text",
                text: "Account ID is required",
              },
            ],
          };
        }
        // Ensure Gateway is ready
        await this.ensureGatewayReady();
        
        // Ensure authentication in headless mode
        if (this.context.config.IB_HEADLESS_MODE) {
          await this.ensureAuth();
        }
        
        const result = await this.context.ibClient.getPositions(input.accountId);
        return {
          content: [
            {
              type: "text",
              text: JSON.stringify(result, null, 2),
            },
          ],
        };
      } catch (error) {
        return {
          content: [
            {
              type: "text",
              text: this.formatError(error),
            },
          ],
        };
      }
    }
  • IBClient helper method that makes the actual API call to IB Gateway's /portfolio/{accountId}/positions endpoint to retrieve positions data.
    async getPositions(accountId?: string): Promise<any> {
      try {
        let url = "/portfolio/positions";
        if (accountId) {
          url = `/portfolio/${accountId}/positions`;
        }
    
        const response = await this.client.get(url);
        return response.data;
      } catch (error) {
          Logger.error("Failed to get positions:", error);
        
        // Check if this is likely an authentication error
        if (this.isAuthenticationError(error)) {
          const authError = new Error("Authentication required to retrieve positions. Please authenticate with Interactive Brokers first.");
          (authError as any).isAuthError = true;
          throw authError;
        }
        
        throw new Error("Failed to retrieve positions");
      }
    }
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. The description only shows usage syntax without explaining what 'positions' are, what data is returned, whether this requires authentication, rate limits, or any side effects. For a financial/trading tool with zero annotation coverage, this leaves critical behavioral traits undocumented.

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 extremely concise - just two short sentences showing usage patterns. It's front-loaded with the core purpose. While arguably too brief for completeness, every word serves a purpose with no fluff or repetition.

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 financial/trading tools, no annotations, no output schema, and 0% schema description coverage, the description is severely incomplete. It doesn't explain what 'positions' are, what data structure is returned, authentication requirements, or how this tool relates to siblings like 'get_account_info'. The agent lacks sufficient context to use this tool effectively.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate. It mentions the 'accountId' parameter in a usage example but provides no semantic meaning - what an accountId is, where to find it, or what happens when omitted. The description adds minimal value beyond what the bare schema provides, failing to adequately explain the single required parameter.

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 current positions' which clearly indicates a read operation on positions data. However, it doesn't specify what type of positions (trading positions, job positions, etc.) or distinguish this tool from sibling tools like 'get_account_info' or 'get_live_orders' that might also retrieve financial data. The purpose is understandable but lacks specificity and differentiation.

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 usage syntax examples but no guidance on when to use this tool versus alternatives. It doesn't mention when to use the optional accountId parameter versus empty object, nor does it differentiate from sibling tools like 'get_account_info' or 'get_live_orders' that might retrieve related financial data. The agent receives no contextual usage advice.

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/code-rabi/interactive-brokers-mcp'

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