Skip to main content
Glama
aiordanescu

ib-gateway-mcp

by aiordanescu

WSH metadata

get_wsh_metadata
Read-only

Retrieve Wall Street Horizon event calendar metadata—event types and filter fields—to build get_wsh_events queries. Filter by text query and limit response length.

Instructions

Describe the Wall Street Horizon (WSH) event calendar: event types and filter fields.

Use it to build get_wsh_events queries: `event_types` lists the event type tags
(wshe_ed is the earnings date, for example) and `metadata_json` holds the full
description, filtered by `query` and cut at max_chars (default 30000, max 200000).
The metadata is fetched once and then served from this server's cache (`cached`).
Needs a Wall Street Horizon corporate event data subscription (paid) on the IBKR
login; without it IBKR answers with an ib_api_error. not_found means nothing matched
`query`.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryNoOnly return the parts of the metadata mentioning this text (case-insensitive), e.g. 'earnings' or 'wshe_ed'. Omit for everything.
max_charsNoLongest JSON to return, in characters (at most 200,000); longer JSON is cut and truncated is true.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryNoThe filter applied to the metadata, if any.
cachedYesTrue when served from this server's cache instead of a new request.
truncatedNoTrue when the result was cut to the limit.
fetched_atYesWhen the metadata was fetched from IBKR (UTC).
event_typesNoEvent type tags (wshe_...) found in the returned metadata; pass them as event_types to get_wsh_events.
total_charsYesLength of the full (filtered) JSON before truncation.
metadata_jsonYesThe metadata as compact JSON (only the parts mentioning query, when given). Not valid JSON when truncated is true.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only provide readOnlyHint and openWorldHint, so the description carries more weight. It discloses the caching behavior ('fetched once and then served from this server's cache'), the subscription requirement with the resulting ib_api_error, and the meaning of not_found. These are valuable behavioral details not present in the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded with purpose, but it repeats some schema details (default 30000, max 200000) and weaves parameter behavior into the usage sentence. It is a few sentences longer than strictly necessary, but each sentence carries useful information.

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

Completeness4/5

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

Given the tool's low complexity, two optional parameters, and an output schema, the description is largely complete. It covers purpose, usage context, caching, prerequisites, and error semantics. Minor gaps such as refresh behavior for the cache are not critical for correct invocation.

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?

Schema description coverage is 100%, so the baseline is 3. The description mostly restates what the schema already says about query filtering and max_chars truncation, and even the example 'wshe_ed is the earnings date' appears in the schema. It adds slight context by linking event_types and metadata_json to get_wsh_events, but does not meaningfully enhance parameter understanding beyond 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 opens with a specific verb and resource: 'Describe the Wall Street Horizon (WSH) event calendar: event types and filter fields.' It clearly distinguishes this metadata tool from its data-fetching sibling get_wsh_events by explicitly framing it as the assistant for building get_wsh_events queries.

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 gives explicit usage guidance: 'Use it to build get_wsh_events queries,' directly naming the alternative tool and the scenario in which this tool is appropriate. It also specifies prerequisites (paid subscription) and the failure mode without it, which helps an agent decide whether to call the tool at all.

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