Skip to main content
Glama

tickerbot_get_bars

OHLCV bars from 1-second through monthly. The prices underneath the table.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNoWindow end (inclusive): a bare `YYYY-MM-DD` means through the end of that day, same as series. Mutually exclusive with `asof` and `before` (400).
asofNoPoint-in-time: the most recent bar whose period had closed at or before that moment. A bare `YYYY-MM-DD` means that day's close. A full timestamp means the last FINISHED bar — at 10:00 ET on a Wednesday the day's close has not happened, so `1d` returns Tuesday's bar. Returns one bar unless you also pass `limit`, which gives the last `limit` closed bars. Mutually exclusive with `before`/`cursor` (400). Unlimited depth.
fromNoWindow start (inclusive): `YYYY-MM-DD`, ISO timestamp, or epoch-ms. Combines with `to` for an explicit window; page within it using `cursor`. Mutually exclusive with `asof` and `before` (400).
limitNoMost-recent N bars. Max 1000 — an over-cap value is clamped, not an error.
beforeNoReturn the N bars ending strictly before this date/timestamp — back-paging. Mutually exclusive with `cursor` (they are the same control — a 400 when both are sent).
cursorNoContinuation token from a prior response's `next_cursor`; sugar for `before` (sending both is a 400; a blank `cursor=` counts as absent), and the way to page inside a `from`/`to` window.
tickerYesTicker symbol, or a comma-separated list (up to 50) for a bulk response keyed by symbol.
sessionNoSub-hour intervals only. `all` (default) includes pre- and post-market bars. `regular` keeps bars whose start is in 09:30–16:00 ET (DST-aware). Why you might want it: the vendor buckets trades by SIP report time, and late-reported off-exchange (Form T) prints on thin names can land 20 min to hours late in a pre-market minute — a `$1.70` print at 08:13 ET on a `$3.85` stock. Daily high/low are untouched by those. `limit` counts after the filter; paging still works.all
adjustedNoDefault `true`: prices are split-adjusted — restated after each later split, as the tape is, so a series is continuous across a split. `false` returns the price as it printed that day (a name that later did a 1:10 reverse split reads `21.4` adjusted and `2.14` on the tape), which is what a broker fill or a chart from that time shows. Volume scales the other way. Un-adjusted on read from the splits table; the store is untouched.
intervalYesBar interval. `2h`/`4h` roll up hourly bars; `1w`/`1mo` roll up daily bars into calendar weeks (Monday start) and months — the bar's `t` is the bucket start (UTC), and with `asof` the last bucket is the week/month to date.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
barsYesOHLCV bars, chronological, in the compact array shape. Bulk requests key this by symbol instead.
noteNoPresent only when there is something to disclose about how the page was served: the first on-demand fetch for an untiered symbol (explains the latency; later calls are stored), or a `1s` page served from the local store because the provider could not be reached. Bulk responses carry `notes[symbol]` instead.
as_ofYesServer time this response was assembled (ISO 8601).
countYesBars returned in single-symbol mode; the number of SYMBOLS in bulk mode.
notesNoBulk (comma-list) requests only: the per-symbol disclosures, keyed by symbol, in place of `note`.
tickerYesThe symbol you asked for.
sessionYesThe session filter applied: `all` (default) or `regular` (09:30–16:00 ET, sub-hour intervals only).
adjustedYesWhether the bars are split-adjusted — `true` unless you passed `adjusted=false`.
coverageYesWhy the page looks the way it does: `covered` when bars were found, `no_data` when the vendor has none for the window, `not_in_minute_tier` when a sub-hour interval was asked of a symbol the minute store does not carry.
intervalYesThe bar size served.
next_cursorNoOpaque token for the next page; `null` on the last page. Absent on bulk (comma-list) requests, which are unpaged. Absent on bulk requests — page bulk symbol-by-symbol.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "additionalProperties": false,
      +  "properties": {
      +    "adjusted": {
      +      "description": "Whether the bars are split-adjusted — `true` unless you passed `adjusted=false`.",
      +      "type": "boolean"
      +    },
      +    "as_of": {
      +      "description": "Server time this response was assembled (ISO 8601).",
      +      "type": "string"
      +    },
      +    "bars": {
      +      "description": "OHLCV bars, chronological, in the compact array shape. Bulk requests key this by symbol instead.",
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    "count": {
      +      "description": "Bars returned in single-symbol mode; the number of SYMBOLS in bulk mode.",
      +      "type": "number"
      +    },
      +    "coverage": {
      +      "description": "Why the page looks the way it does: `covered` when bars were found, `no_data` when the vendor has none for the window, `not_in_minute_tier` when a sub-hour interval was asked of a symbol the minute store does not carry.",
      +      "type": "string"
      +    },
      +    "interval": {
      +      "description": "The bar size served.",
      +      "type": "string"
      +    },
      +    "next_cursor": {
      +      "description": "Opaque token for the next page; `null` on the last page. Absent on bulk (comma-list) requests, which are unpaged. Absent on bulk requests — page bulk symbol-by-symbol.",
      +      "type": "string"
      +    },
      +    "note": {
      +      "description": "Present only when there is something to disclose about how the page was served: the first on-demand fetch for an untiered symbol (explains the latency; later calls are stored), or a `1s` page served from the local store because the provider could not be reached. Bulk responses carry `notes[symbol]` instead.",
      +      "type": "string"
      +    },
      +    "notes": {
      +      "description": "Bulk (comma-list) requests only: the per-symbol disclosures, keyed by symbol, in place of `note`.",
      +      "type": "object"
      +    },
      +    "session": {
      +      "description": "The session filter applied: `all` (default) or `regular` (09:30–16:00 ET, sub-hour intervals only).",
      +      "type": "string"
      +    },
      +    "ticker": {
      +      "description": "The symbol you asked for.",
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "as_of",
      +    "ticker",
      +    "interval",
      +    "adjusted",
      +    "session",
      +    "count",
      +    "coverage",
      +    "bars"
      +  ],
      +  "type": "object"
      +}
  2. Added

TDQS

D1.9/5.0
Behavior1/5

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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. The description only states what the tool returns and does not mention any behavioral traits such as side effects, authentication requirements, rate limits, or response format. This is a significant gap for a data retrieval tool.

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

Conciseness2/5

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

The description is extremely short, but it is under-specified rather than concise. It lacks structure and meaningful content, with a cryptic phrase that does not aid understanding. It is not front-loaded with useful information and reads as an incomplete thought.

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

Completeness1/5

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

For a tool with 10 parameters and a rich schema, the description is severely inadequate. It does not explain when to use the tool, what to expect in the response, or any operational constraints. The output schema exists but the description does not reference or complement it. This fails to provide the context an agent needs.

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 schema already documents all parameters comprehensively. The description adds little beyond noting interval availability, which is already in the schema. Per the baseline rule for high coverage, a 3 is appropriate since the description does not need to compensate but also provides minimal added value.

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

Purpose3/5

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

The description states the tool returns OHLCV bars across various intervals, which gives a general sense of purpose. However, it lacks specificity about the resource scope and does not differentiate it from siblings like get_series or get_ticker. The phrase 'the prices underneath the table' is vague and doesn't add clarity.

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

Usage Guidelines1/5

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

No guidance is given on when to use this tool versus alternatives. There is no mention of conditions, exclusions, or when a different tool would be more appropriate. Given the large set of sibling tools, this is a critical omission.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.