ib-gateway-mcp

Executions

get_executions

Read-only

Retrieve recent account executions (fills) with commission and realized P&L, sorted newest first. Filter by symbol, side, security type, or time. Covers the current trading day.

Instructions

List the account's executions (fills), newest first, with commission and realized P&L.

Covers the current trading day only (up to 7 days if the gateway's trade-log setting
allows); older trades are not available through the API. `commission` is null until
IBKR reports it (usually within seconds of the fill); realized_pnl is 0 for fills
that opened a position. Default limit 100, maximum 1000.

Input Schema

TableJSON Schema

Name	Required	Description
`side`	No	Only buys (BUY) or sells (SELL).
`limit`	No	Maximum number of items to return. Omit for the tool's default; larger values are capped. The result's truncated flag says whether more were available.
`since`	No	Only executions at or after this time (ISO 8601; no zone = UTC).
`symbol`	No	Only this symbol, e.g. AAPL.
`account`	No	IBKR account id, e.g. DU1234567. Omit to use the default account; list_accounts shows which accounts are allowed.
`sec_type`	No	Only this security type, e.g. STK or OPT.

Output Schema

TableJSON Schema

Name	Required	Description
`total`	Yes	How many executions matched before the limit.
`account`	Yes
`truncated`	No	True when the result was cut to the limit.
`executions`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 23, 2026

TDQS

A4.7/5.0

Behavior5/5

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

The annotations only signal read-only and open-world behavior, so the description carries the burden of explaining field semantics. It adds valuable behavior: commission is null until IBKR reports it, realized_pnl is 0 for position-opening fills, and the default/maximum limit are concretely specified. This goes well beyond the annotations and introduces no contradiction.

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 organized into short, focused sentences: purpose first, then time coverage, then field semantics and limits. Every sentence earns its place, and there is no filler or redundant restatement.

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

Completeness5/5

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

Given that the output schema exists and all parameter schemas are already descriptive, the description supplies the remaining contextual essentials: data availability window, null/zero value semantics, and limit behavior. An agent has enough information to select and invoke this tool correctly.

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?

All six parameters are already documented in the input schema, so the baseline is 3. The description adds the specific default limit of 100 and maximum of 1000, which the schema leaves unspecified, providing meaningful extra value for the limit parameter.

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

Purpose5/5

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

The description states the exact resource ('executions (fills)') and the verb 'List', and it specifies ordering ('newest first') and the key returned fields ('commission and realized P&L'). This makes it clearly distinct from sibling order-status tools like get_open_orders and get_completed_orders.

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?

It gives clear context: it covers the current trading day only, with a possible 7-day extension depending on the gateway setting, and explicitly states that older trades are not available through the API. It does not name a sibling alternative, so it stops short of full when-to-use-vs-alternative routing.

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

Deploy Server