Skip to main content
Glama
code-rabi

Interactive Brokers MCP Server

by code-rabi

get_live_orders

Monitor and validate open orders in Interactive Brokers accounts to confirm market order execution. Use to check all accounts or specify an account ID.

Instructions

Get all live/open orders for monitoring and validation. Usage: {} for all accounts or { "accountId": "<id>" } for a specific account. This is the recommended way to validate that market orders were executed successfully after placing them.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
accountIdNo

Implementation Reference

  • The main execution logic for the 'get_live_orders' tool. Ensures prerequisites (gateway and auth), calls ibClient.getOrders with optional accountId, and returns JSON-formatted results or formatted error.
    async getLiveOrders(input: GetLiveOrdersInput): Promise<ToolHandlerResult> {
      try {
        // Ensure Gateway is ready
        await this.ensureGatewayReady();
        
        // Ensure authentication in headless mode
        if (this.context.config.IB_HEADLESS_MODE) {
          await this.ensureAuth();
        }
        
        // Pass accountId as query parameter if provided
        const result = await this.context.ibClient.getOrders(input.accountId);
        return {
          content: [
            {
              type: "text",
              text: JSON.stringify(result, null, 2),
            },
          ],
        };
      } catch (error) {
        return {
          content: [
            {
              type: "text",
              text: this.formatError(error),
            },
          ],
        };
      }
    }
  • Zod shape definition for get_live_orders input validation, allowing optional accountId to filter orders by account.
    export const GetLiveOrdersZodShape = {
      accountId: z.string().optional()
    };
  • src/tools.ts:93-100 (registration)
    Registers the 'get_live_orders' tool with the MCP server, providing name, description, input schema (GetLiveOrdersZodShape), and handler reference.
    // Register get_live_orders tool
    server.tool(
      "get_live_orders",
      "Get all live/open orders for monitoring and validation. Usage: `{}` for all accounts or `{ \"accountId\": \"<id>\" }` for a specific account. " +
      "This is the recommended way to validate that market orders were executed successfully after placing them.",
      GetLiveOrdersZodShape,
      async (args) => await handlers.getLiveOrders(args)
    );
Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the tool's purpose and usage context well, but doesn't mention important behavioral aspects like whether this is a read-only operation (implied but not stated), potential rate limits, authentication requirements, or what format the returned data takes. The description adds value but leaves significant behavioral gaps unaddressed.

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 perfectly concise and well-structured. The first sentence states the purpose, the second provides parameter usage examples, and the third gives the primary use case. Every sentence earns its place with no wasted words, and the information is front-loaded appropriately.

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

Completeness3/5

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

Given that there are no annotations and no output schema, the description should do more to compensate. While it covers purpose, usage guidelines, and parameter semantics adequately, it doesn't describe what the tool returns (order format, data structure, error conditions) or address authentication requirements. For a tool with zero annotation coverage and no output schema, this leaves significant gaps in contextual understanding.

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

Parameters4/5

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

The schema has 1 parameter with 0% description coverage, so the description must compensate. It does this effectively by explaining the parameter's semantics: '{} for all accounts or { "accountId": "<id>" } for a specific account.' This clearly explains what the parameter does and provides usage examples. However, it doesn't specify what format the accountId should be in or where to obtain it, preventing a perfect score.

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: 'Get all live/open orders for monitoring and validation.' It specifies the verb ('Get') and resource ('live/open orders'), and the context ('monitoring and validation') adds useful nuance. However, it doesn't explicitly differentiate this from sibling tools like 'get_order_status' or 'get_positions', which prevents a perfect score.

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 description provides clear context for when to use this tool: 'for monitoring and validation' and specifically 'to validate that market orders were executed successfully after placing them.' It also gives usage examples for different scenarios (all accounts vs. specific account). However, it doesn't explicitly state when NOT to use it or mention alternatives among sibling tools, which keeps it from a score of 5.

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