Skip to main content
Glama

CeylonCharts - Colombo Stocks Exchange (CSE) data for AI Agents

Get OHLC price history

get_ohlc_data
Read-onlyIdempotent

Get OHLCV (open, high, low, close, volume) data for a CSE symbol. Prices are adjusted for splits by default (clean price action), but NOT for rights issues or dividends, unless requested. Defaults to the most recent 50 trading days; if more history is available the response says so and how to page further back with offset. Returns CSV (date,open,high,low,close,volume) preceded by a note if the symbol was resolved from a name/typo, if the company has other instruments, or if any corporate actions (splits/rights/dividends) fall within the requested range. If the input is ambiguous, returns JSON candidates instead.

Input Schema

NameRequiredDescriptionDefault
toNoEnd of an explicit date range to fetch, in YYYY-MM-DD format. Omit to default to the latest available trading day.
fromNoStart of an explicit date range to fetch, in YYYY-MM-DD format. Omit to use the default recent-trading-days window instead (see `limit`).
limitNoMax trading days to return. The most recent matching days are selected first and then reordered chronologically before being returned — use `offset` to page further back in history.
offsetNoSkip this many of the most recent trading days before taking `limit` — use to page further back into history.
symbolYesA CSE ticker (e.g. "SAMP" or "SAMP.N0000") or the company name (e.g. "Sampath Bank"). Typos are tolerated. A bare symbol or name defaults to the voting-shares instrument if the company has more than one listed instrument (voting/non-voting/rights/debentures/preferential) — the response notes the others if so. If the input is ambiguous, the response returns candidates instead of data; ask the user to pick one and call again with the exact symbol.
intervalNoBar size for the returned series — use "weekly" or "monthly" to aggregate into coarser bars instead of daily candles.daily
adjust_rightsNoAdjust historical prices for past rights issues falling within the range, producing continuous pre-/post-issue price action.
adjust_splitsNoAdjust historical prices for stock splits and scrip/bonus share dividends.
adjust_dividendsNoAdjust historical prices for cash dividends, producing a total-return series — turn this on when the user is asking about total return / performance rather than raw price action.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changed
    • changedInput schema / properties / adjust_dividends / description
      Previous value: -"Adjust historical prices for cash dividends, producing a total-return series. Default false — turn this on when the user is asking about total return / performance rather than raw price action."New value: +"Adjust historical prices for cash dividends, producing a total-return series — turn this on when the user is asking about total return / performance rather than raw price action."
    • changedInput schema / properties / adjust_rights / description
      Previous value: -"Adjust historical prices for rights issues. Default false."New value: +"Adjust historical prices for past rights issues falling within the range, producing continuous pre-/post-issue price action."
    • changedInput schema / properties / adjust_splits / description
      Previous value: -"Adjust historical prices for stock splits and scrip/bonus share dividends. Default true."New value: +"Adjust historical prices for stock splits and scrip/bonus share dividends."
    • changedInput schema / properties / from / description
      Previous value: -"Start date in YYYY-MM-DD format"New value: +"Start of an explicit date range to fetch, in YYYY-MM-DD format. Omit to use the default recent-trading-days window instead (see `limit`)."
    • changedInput schema / properties / interval / description
      Previous value: -"Data interval"New value: +"Bar size for the returned series — use \"weekly\" or \"monthly\" to aggregate into coarser bars instead of daily candles."
    • changedInput schema / properties / limit / description
      Previous value: -"Max trading days to return, most recent first (before reversing to chronological order). Default 50, max 500."New value: +"Max trading days to return. The most recent matching days are selected first and then reordered chronologically before being returned — use `offset` to page further back in history."
    • changedInput schema / properties / to / description
      Previous value: -"End date in YYYY-MM-DD format"New value: +"End of an explicit date range to fetch, in YYYY-MM-DD format. Omit to default to the latest available trading day."
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations: default adjustment policy (splits on, rights/dividends off), the 50-day default and offset paging, CSV shape, note prefixes for name resolution / other instruments / corporate actions, and the JSON-candidates behavior on ambiguous input. That is exactly the extra context annotations cannot carry.

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?

Front-loads purpose and defaults, then layers edge cases; nearly every clause carries information (adjustment policy, paging, ambiguous-input path). It is dense and somewhat clause-heavy, but not padded.

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 no output schema, the description carries the return-format burden and does so fully: CSV columns, the leading note variants, and the JSON-candidates substitute response. Nothing an agent needs to call and interpret this tool 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?

Schema coverage is 100%, so the baseline is 3, but the description adds cross-parameter meaning the schema states only piecemeal: the default split-only adjustment posture and the interaction that offset + limit page backward through history. It stops short of adding format details 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?

States a specific verb and resource ('Get OHLCV data for a CSE symbol') and immediately scopes it with adjustment semantics and the default window. An agent can separate this from get_quotes (snapshot) and get_chart (visual) without opening any schema.

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?

Gives real conditional guidance: adjust_dividends for total-return questions, offset for paging further back, and the ambiguity fallback ('ask the user to pick one'). It never names a sibling tool as the alternative for a competing task, so it stops short of a 5.

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.

Resources