ib-gateway-mcp

Account values

get_account_values

Read-only

Retrieve detailed IBKR account values per currency, including cash, accrued interest, and segment details, to fill gaps left by summary data.

Instructions

Return the full key/value account data: every tag IBKR reports, per currency.

Use it for details the summary lacks (per-currency cash, accrued interest, segment
values with -C/-S suffixes, currency exchange rates...). Each row has the raw `value`
and, when numeric, `amount`. Values update about every 3 minutes or on change.
With `model_code` (financial advisors) the values of that model are fetched once.
Default limit 200, maximum 1000; `truncated` says whether more matched.
Errors: invalid_request lists the valid tags when a tag is unknown.

Input Schema

TableJSON Schema

Name	Required	Description
`tags`	No	Only these tags (case-insensitive), e.g. ['CashBalance'].
`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.
`account`	No	IBKR account id, e.g. DU1234567. Omit to use the default account; list_accounts shows which accounts are allowed.
`currency`	No	Only values in this currency, e.g. USD; BASE for converted totals.
`model_code`	No	Financial-advisor model code, to scope the result to one model portfolio. Omit for the whole account (normal for non-advisor accounts).

Output Schema

TableJSON Schema

Name	Required	Description
`as_of`	Yes	When this server read the values (UTC).
`total`	Yes	How many values matched the filters before the limit.
`values`	Yes
`account`	Yes
`truncated`	No	True when the result was cut to the limit.
`model_code`	No	Advisor model code, when one was given.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 23, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare readOnlyHint and openWorldHint, but the description adds substantial behavioral context: values update every ~3 minutes or on change, default and maximum limits (200/1000), truncated flag semantics, repeated fetching behavior with model_code, and error behavior with invalid_request listing valid tags. These details go well beyond the annotations and schema, with 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 dense but well organized, leading with the core purpose, then use cases, update cadence, limits, and errors. Each sentence adds distinct information and none feel redundant with the schema or annotations.

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 the output schema exists and the input schema already covers parameters, the description still provides essential behavioral context: cadence, limits/truncation, error handling, and use-case differentiation from get_account_summary. An agent has enough information to select and invoke the tool correctly in most scenarios.

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?

Schema description coverage is 100%, so the baseline is 3. The description adds meaningful value on top: it explains the row structure (raw value and numeric amount), clarifies model_code fetches the model's values once, and connects the limit/truncation semantics. This lifts it above the baseline, though most parameter-level detail still comes from the schema.

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 a specific verb and resource: 'Return the full key/value account data: every tag IBKR reports, per currency.' It also distinguishes this tool from the sibling summary tool, so an agent can reliably tell get_account_values apart from get_account_summary without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly tells when to use this tool: 'Use it for details the summary lacks' and gives concrete examples such as per-currency cash, accrued interest, and segment values. It also references the alternative get_account_summary and explains special cases like model_code for financial advisors, giving clear contextual guidance.

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

Deploy Server