Skip to main content
Glama
Sign In

KeyVex

by com.keyvex
OverviewDiscussionsAdmin

get_daily_prices

Read-only

Returns daily end-of-day closing-price history for one US-listed ticker (stocks, ETFs, mutual funds — including delisted tickers, so historical analysis is survivorship-bias-free). Coverage extends back as far as 1962 for the oldest names, subject to plan history limits. PAID PLANS ONLY. Each row: date, close (as-traded), adj_close (split+dividend adjusted — use THIS for charts and return calculations), div_cash (dividend with that ex-date), split_factor (e.g. 4 = 4:1 split that session). price_currency (top level) is the ISO currency of EVERY price in the response: USD. KeyVex covers US-listed securities priced in US dollars (foreign companies listed on US exchanges included); a ticker listed only elsewhere, e.g. a Shanghai or Shenzhen A-share, answers 'Not covered' with no prices. null means the currency is not known. asset_type is the listing's type (Stock, ETF, Mutual Fund). The freshness block grades THIS ticker too: its newest bar (last_available) against the newest US sessions, in sessions behind (mutual-fund NAVs post later, so funds have a wider tolerance). last_trade is the newest session with volume > 0: present for a series marked as no longer trading; otherwise only when the window includes its newest year (and absent for funds, which price at NAV with no volume). An inactive ticker reads 'no trades since <last_trade>', plus 'the vendor repeats the last price at zero volume' when it still prints bars after that trade. delisted_since appears only where an SEC delisting or deregistration filing (Form 25 / Form 15 families) is on file for the ticker, with delisting_form naming it; it is never inferred from prices. When a symbol was retired because its issuer moved to another symbol, continues_as names that symbol and the day it took effect (e.g. PSKY → SKYD from 2026-10-07). adjustment_hold appears only while a vendor split or dividend is held for review and not yet applied to earlier adjusted prices: for a split or a dividend of 10%+ of the prior close, every adjusted price before adj_withheld_before is null (close is as traded); for a smaller dividend, adj_close is served and the notice says it is off by that dividend. include_ohlc=true adds the session's open / high / low / volume and their adjusted variants — the day's RANGE, which is what a stop or a target is actually tested against. On weekly/monthly these are aggregated over the period (first open, highest high, lowest low, summed volume), not the last session's values. Omit the flag and the response is unchanged. At most 5,000 rows per call (5,000 daily rows is about 20 years). When the window holds more, the response says truncated=true. Without since, you get the NEWEST 5,000 and prev_until: call again with until=prev_until for the page before. With since, you get the 5,000 from since onward and next_since: call again with since=next_since for the page after. Rows are never dropped silently. For multi-year ranges prefer frequency='weekly' or 'monthly' (last bar per period; dividends summed, split factors compounded), which never page: 10 years daily ≈ 2,500 rows vs ~120 monthly. One call = one ticker. Compare securities with multiple calls. Close Prices from Tiingo.com.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "ticker": "<ticker>"
    },
    "name": "get_daily_prices"
  }
}

Input Schema

NameRequiredDescriptionDefault
sinceNoISO date YYYY-MM-DD inclusive. Default: earliest your plan allows. Setting since pages FORWARD from it: to read the next page of a long window, pass the previous response's next_since.
untilNoISO date YYYY-MM-DD inclusive. Default: latest available. Without since a long window returns its newest 5,000 rows; to read the page before, pass the previous response's prev_until here.
tickerYesTicker symbol, e.g. 'AAPL', 'SPY', 'BRK-B' (hyphen for share classes).
frequencyNoDownsampling. Default daily. Use weekly/monthly for multi-year charts.
include_ohlcNoAdd open/high/low/volume (+ adjusted variants) to each row. Default false. Aggregated per period on weekly/monthly.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / since / description
      Previous value: -"ISO date YYYY-MM-DD inclusive. Default: earliest your plan allows."New value: +"ISO date YYYY-MM-DD inclusive. Default: earliest your plan allows. Setting since pages FORWARD from it: to read the next page of a long window, pass the previous response's next_since."
    • changedInput schema / properties / until / description
      Previous value: -"ISO date YYYY-MM-DD inclusive. Default: latest available."New value: +"ISO date YYYY-MM-DD inclusive. Default: latest available. Without since a long window returns its newest 5,000 rows; to read the page before, pass the previous response's prev_until here."
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only declare readOnly/openWorld/non-destructive; the description goes well beyond them, disclosing the paid-plan gate, the 1962 history floor, the 5,000-row cap with truncation and bidirectional paging, the null-fill behavior during adjustment_hold, and the rule that delisted_since is only asserted from SEC filings. It also explains when last_trade and continues_as appear, which are non-obvious response behaviors an agent could otherwise misread.

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?

It is front-loaded with purpose and coverage before drilling into per-field meaning, and with no output schema most of the field-by-field detail (adj_close, price_currency, freshness) is load-bearing. It is dense and a few sentences are expendable — 'Omit the flag and the response is unchanged' and the repeated paging restatement add little — but there is no filler or marketing prose.

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 and a complex response surface, the description carries the full burden and discharges it: it enumerates every returned field, defines currency and asset_type semantics, explains freshness grading and mutual-fund NAV lag, and describes truncation and continuation tokens. An agent can parse and paginate the response from the description alone.

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 genuine meaning: include_ohlc=true is framed as the day's range used for stops/targets and is described as period-aggregated on weekly/monthly, and frequency is characterized as downsampling with dividends summed and split factors compounded. The paging semantics for since/until are largely restated from the schema text rather than extended.

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 first sentence states a specific verb and resource — end-of-day closing-price history for one US-listed ticker — and immediately scopes coverage (stocks, ETFs, mutual funds, delisted names). It explicitly bounds the tool to one ticker at a time and points at multiple calls for comparison, so an agent can tell it apart from sibling tools without opening a 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?

It gives concrete selection guidance: use weekly/monthly for multi-year ranges, page with until=prev_until or since=next_since depending on which bound was set, and expect 'Not covered' for tickers listed only outside the US. It notes PAID PLANS ONLY, which is a real precondition. What it lacks is any explicit routing to a named alternative sibling (e.g. get_delistings for corporate delisting history), 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.

All KeyVex toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources