ib-gateway-mcp

List subscriptions

list_subscriptions

Read-only

List all active market data subscriptions—quotes, depth, ticks, bars, scans, news—with their status, idle expiry, and capacity usage against server and IBKR limits. Monitor what's subscribed and how much capacity remains.

Instructions

List every open subscription of every kind: quotes, depth, ticks, bars, scans, news...

For each: its id, kind, key, contract, parameters, when it was created and last
read, when it will be cancelled for being idle (`idle_expires_at`), and `stale`
(true while the gateway connection is down). Also shows capacity: subscriptions
used out of the server maximum, and market depth and tick-by-tick streams used out
of IBKR's limits, plus the connection's current market data type.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description
`max`	Yes	IBKR_MCP_MAX_SUBSCRIPTIONS.
`used`	Yes
`depth_max`	Yes
`depth_used`	Yes
`idle_ttl_s`	Yes
`subscriptions`	Yes
`market_data_type`	No	What later market data requests on this connection get.
`tick_by_tick_max`	Yes
`tick_by_tick_used`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 23, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already provide readOnlyHint and openWorldHint, so the description only needs to add interpretive context. It does: idle expiration via `idle_expires_at`, `stale` while the gateway connection is down, and capacity relative to server and IBKR limits. No contradiction with annotations.

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 front-loaded with the core scope in the first sentence and then organizes details logically: per-subscription fields, idle/stale behavior, then capacity and connection type. Every sentence adds useful information without padding.

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 tool has no parameters and an output schema exists, the description covers everything an agent needs to invoke it correctly and interpret the result: which subscriptions are included, what fields appear, staleness semantics, and capacity limits. Nothing material is missing.

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 tool has zero parameters and an empty input schema, so there is no parameter meaning for the description to augment. The baseline of 4 applies; the description sensibly devotes its space to the response contents instead.

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 opens with 'List every open subscription of every kind,' giving a specific verb, resource, and scope, followed by concrete kinds: quotes, depth, ticks, bars, scans, news. This makes the tool's purpose unmistakable and clearly distinct from lower-level retrieve or subscribe tools.

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 makes the usage context clear: this is the tool for an overview of all open subscriptions and their state, including capacity and staleness. It does not explicitly name a per-subscription alternative or give when-not conditions, so it stops short of full routing guidance.

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

Deploy Server