Skip to main content
Glama

Valuein — SEC EDGAR Fundamentals & Smart-Money Data

Price History (date range)

get_price_history
Read-onlyIdempotent

Daily EOD bar series (OHLCV) for a company over a date range. Returns up to 252 trading-day bars oldest-first — one bar per trading day. Each bar carries: open / high / low / close (raw, unadjusted), total_return_index (dividends reinvested and splits neutralized, forward-compounded from an arbitrary base so only RATIOS of it are meaningful — TOTAL RETURN BETWEEN TWO DATES IS tri_b / tri_a - 1; it is PIT-immutable, so a later dividend appends rather than restating), adjusted_close (the vendor's own back-adjusted series — SPARSELY POPULATED, usually null, and retroactively restated on each corporate action so it is NOT PIT-immutable; prefer total_return_index), volume (shares traded), div_cash (ex-dividend cash per share on that date, 0 on non-dividend days), and split_factor (1.0 on non-split days). Never compute a return from raw close — a 4-for-1 split reads as a 75% crash. If total_return_index is null across the returned bars (a tier that has not re-exported since schema 2.29.0), the response note says so and you should compound close with div_cash / split_factor instead. For a company with more than one listing (dual-class, CVR), bars are the requested share class where the data supports it; listing_resolution and multi_listing on the response say which listing you actually received. Omit start_date for the trailing year before end_date. Omit end_date for the latest available close. Coverage follows your plan's tier slice: full = all companies & all history, pro = all companies & last 15 years, sp500 = S&P 500 only, sample = S&P 500 & last 5 years. Available on all plans.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of bars to return (1–252; default 252 ≈ 1 trading year). When the range contains more bars than `limit`, the most recent `limit` bars within the range are returned.
tickerYesStock ticker symbol, e.g. AAPL, MSFT
end_dateNoInclusive end of the date range (YYYY-MM-DD). Defaults to today (the latest available close). Weekends and holidays resolve to the last trading close on or before this date.
start_dateNoInclusive start of the date range (YYYY-MM-DD). Bars on or after this date are returned (up to `limit`). Omit to receive the `limit` most-recent bars before end_date.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
cikYes
barsYes
noteYes
planYes
_metaYesProvenance envelope — data lineage for every MCP response
tickerYes
end_dateYes
bar_countYes
start_dateYes
company_nameYes

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare readOnlyHint and idempotentHint, but the description goes far beyond: explains PIT immutability of total_return_index, retroactive restatement of adjusted_close, the split-factor warning ('a 4-for-1 split reads as a 75% crash'), and tier-based coverage. This is rich behavioral disclosure not present in 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 long but every sentence carries essential information (field semantics, split handling, null fallback, multi-listing, tier coverage). It is front-loaded with the core purpose and structured logically. Slightly dense but justified by the tool's complexity.

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?

For a data-retrieval tool with an output schema, the description still explains the semantics of each field, edge cases (null TRI, adjusted_close sparsity), multi-listing resolution, and plan limitations. This is comprehensive and leaves little ambiguity for an agent to invoke correctly.

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 coverage is 100% with descriptions for all parameters. The description reinforces behavior like 'Omit start_date' and 'Omit end_date' but does not add new parameter meaning beyond what the schema already documents. It adds context about plan tiers, but that is not parameter-specific. Baseline 3 is appropriate.

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 clearly states the tool's function: 'Daily EOD bar series (OHLCV) for a company over a date range.' It specifies the exact resource (price history) and the operation (returns bars), and the detail about one bar per trading day distinguishes it from single-quote siblings like get_stock_price.

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?

Provides detailed usage guidance: how to omit dates for defaults ('Omit start_date for the trailing year before end_date'), when to use total_return_index versus adjusted_close ('prefer total_return_index'), and what to do if TRI is null. It does not explicitly name sibling alternatives, but the context is strong enough to infer when to use this tool.

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.

TDQS

A4/5.0
Disambiguation5/5

Each tool has a distinct purpose with detailed descriptions that clarify differences. Overlaps like get_peer_comparables vs screen_universe are well-differentiated by scope (single company vs cross-sectional). Similarly, get_insider_sentiment vs get_smart_money_flow are clearly distinguished by data sources and methodology.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern (e.g., create_report, get_financial_ratios, delete_alert). No mixing of conventions or inconsistent verbs.

Tool Count2/5

With 69 tools, the count far exceeds the 25+ threshold for 'too many'. While the domain is broad, the sheer volume likely overwhelms agents and increases selection complexity.

Completeness4/5

The tool set covers a wide range of SEC filings, ratios, smart-money data, alerts, reports, and more. Minor gaps exist (e.g., no options or detailed debt data), but most analyst workflows are supported.