ib-gateway-mcp

Trading schedule

get_trading_schedule

Read-only

Get an instrument's trading sessions for recent days: start, end, trading date, exchange timezone offset, with holidays, early closes, and overnight sessions visible.

Instructions

Return an instrument's trading sessions (start, end, trading date) for recent days.

Times are in the exchange's time zone with the offset included, so holidays, early
closes and overnight sessions show up as they really were. For the upcoming
sessions, get_contract_details also lists trading and liquid hours. Counts toward
IBKR's historical-data limits.

Errors: not_found (no such contract, or no sessions in the range).

Input Schema

TableJSON Schema

Name	Required	Description
`end`	No	Last day to cover, ISO 8601 (no offset means UTC). Omit for now.
`use_rth`	No	True: regular trading hours only. False: include pre-market, after-hours and overnight data.
`contract`	Yes	The instrument. A con_id alone is unambiguous; otherwise give symbol and sec_type, plus expiry, strike and right for options.
`num_days`	No	How many days of sessions, ending at end (1-30).

Output Schema

TableJSON Schema

Name	Required	Description
`end`	No	End of the covered range.
`start`	No	Start of the covered range.
`use_rth`	Yes	True: regular hours only; false: including extended hours.
`contract`	Yes
`sessions`	Yes	Oldest first.
`time_zone`	Yes	The exchange's time zone, as IBKR names it.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 23, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Beyond the readOnlyHint annotation, the description reveals that times are returned with the exchange's offset so holidays, early closes, and overnight sessions appear as they actually occurred. It also discloses a side effect on IBKR historical-data quota and lists the not_found error case. These details are not present in the annotations and materially shape invocation expectations.

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 compact and front-loaded: the purpose is in the first sentence, followed by one behavioral paragraph, one limit note, and one error line. Every sentence adds distinct value—timezone handling, data limits, and failure modes—with no filler.

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?

With an output schema present, the description needs only the behavioral and error context, which it supplies. It explains timezone formatting, rate-limit implications, the not_found error, and the relevant sibling alternative. No key operational detail an agent needs before calling appears to be missing.

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

Parameters3/5

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

All four parameters already carry prose descriptions in the schema (100% coverage), so the baseline is 3. The description does not add parameter-specific guidance beyond restating the 'recent days' notion that maps to end/num_days. No extra meaning is missing.

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 a specific verb and resource: 'Return an instrument's trading sessions (start, end, trading date) for recent days.' It clearly defines the output contents and timeframe, and distinguishes itself by naming get_contract_details as a related alternative for upcoming sessions.

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 sentence 'For the upcoming sessions, get_contract_details also lists trading and liquid hours' gives the agent a concrete alternative when future-looking hours are needed. It also flags that the call counts toward historical-data limits, a practical consideration. However, it never explicitly says when not to use this tool or states a hard branching rule.

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

Deploy Server