MetricDuck — Financial Analysis

Stock Price (Daily)

get_stock_price

Read-only

Use this when the user asks for a share price on a date or a return between two dates: daily end-of-day close, adj_close and volume for US-listed stocks, from a market-data feed, not SEC filings; get_company_overview shows only the latest price; get_metric_history has period-end multiples.

Markets are open only on business days, so rows exist ONLY for trading days — the data IS the trading calendar:

Price ON OR AFTER a date (a single date, or an announcement landing on a weekend): pass start_date= alone; the FIRST row of the short forward window is that date or the next open day.
Price ON OR BEFORE a date: pass end_date=; the LAST row is that date or the prior open day.

Use Cases:

"AAPL close on 2025-07-28" -> get_stock_price("AAPL", start_date="2025-07-28")
"DKNG return 2025-01-02 → 2026-02-27" -> get_stock_price("DKNG", start_date="2025-01-02") + get_stock_price("DKNG", end_date="2026-02-27"), first/last close (cheaper than one 14-month window)
"SUI +1/+14/+30 days after an 8-K" -> start_date=, end_date=<announce + ~32d>; pick rows on/after each
No dates -> the latest price

When the window spans ≥2 trading days, the response also reports the first/last close and the period return on BOTH close (point-to-point) and adj_close (split-adjusted, and on some rows, mostly pre-Sept 2023, dividend-adjusted too; not a total return).

Each response also includes the latest REPORTED period-end shares outstanding on/before your end date (period-end balance-sheet count; dei cover where absent) plus the implied market cap at the latest close — use these for market-cap / EV / P/B math instead of deriving share counts from NI/EPS (that yields weighted-average shares, a different basis).

Coverage: ~8,400 US common-equity tickers, end-of-day only (no intraday/real-time, no options/FX). Recent history is dense; deep pre-2014 history may be sparse. For a CUSTOM multiple (e.g. lease-adjusted EV), get_metric_history's metric_id lists the primitives to price with this tool.

Input Schema

Name	Required	Description
`limit`	No	Max rows (newest first if the window exceeds it). Default 30. With start_date alone, the short forward window is returned whole. For a point-to-point return over a long span, make TWO narrow-window calls (one per date) rather than one wide window — cheaper, and avoids the cap dropping your start date. Replies are capped at ~20K chars: when the rows do not fit, raw_data carries the NEWEST rows that do, and a `Next:` call (an earlier end_date) returns the rest.
`ticker`	Yes	Company ticker symbol (e.g., 'AAPL'). US exchange-listed (NYSE/Nasdaq/AMEX), 1–5 letters.
`end_date`	No	Window end (YYYY-MM-DD). The LAST returned row on/before this date is the price ON OR BEFORE it. Omit start_date to fetch just the price on/before this date.
`start_date`	No	Window start (YYYY-MM-DD). Markets trade only on business days — if this date is a weekend/holiday the FIRST returned row is the next OPEN day (the price ON OR AFTER this date). Omit end_date to fetch just the price on/after this date.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 17, 2026

changedInput schema / properties / limit / description

Previous value: -"Max rows (newest first if the window exceeds it). Default 30. With start_date alone, the short forward window is returned whole. For a point-to-point return over a long span, make TWO narrow-window calls (one per date) rather than one wide window — cheaper, and avoids the cap dropping your start date."New value: +"Max rows (newest first if the window exceeds it). Default 30. With start_date alone, the short forward window is returned whole. For a point-to-point return over a long span, make TWO narrow-window calls (one per date) rather than one wide window — cheaper, and avoids the cap dropping your start date. Replies are capped at ~20K chars: when the rows do not fit, raw_data carries the NEWEST rows that do, and a `Next:` call (an earlier end_date) returns the rest."

Changed1 schema field changedOct 9, 2026

changedInput schema / properties / limit / description

Previous value: -"Max rows (newest first if the window exceeds it). Default 30. For a point-to-point return over a long span, make TWO narrow-window calls (one per date) rather than one wide window — cheaper, and avoids the cap dropping your start date."New value: +"Max rows (newest first if the window exceeds it). Default 30. With start_date alone, the short forward window is returned whole. For a point-to-point return over a long span, make TWO narrow-window calls (one per date) rather than one wide window — cheaper, and avoids the cap dropping your start date."

First observedOct 1, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only cover the safe-read profile (readOnlyHint/openWorldHint/destructiveHint), so the description must carry the rest — and it does: rows exist only on trading days, coverage is ~8,400 US common-equity tickers, end-of-day only (no intraday/options/FX), deep pre-2014 history may be sparse, returns are point-to-point not total return, and the ~20K-char reply cap plus `Next:` continuation behavior are disclosed.

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-loaded with purpose, then a clean bulleted date-semantics section, then use cases and coverage notes — every block earns its place. It is long and partially redundant with the equally verbose start_date/end_date schema descriptions, which keeps it just short of a 5.

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?

There is no output schema, so the description must describe returns, and it does: first/last close, period return on both close and adj_close bases, latest reported shares outstanding and implied market cap, plus how they should be used in market-cap/EV/P/B math. Nothing an agent needs to call or interpret the result 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 interpretation beyond the schema field text: which row counts as 'the price on/after' vs 'on/before' a date, the weekend/announcement landing case, and the strategy of two narrow calls instead of one wide window. Much of this is echoed in the schema descriptions, so it is additive rather than essential, but it is genuinely clarifying.

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 opening sentence states a specific verb+resource+scope: daily end-of-day close, adj_close and volume for US-listed stocks from a market-data feed, explicitly 'not SEC filings'. It also names and distinguishes the two nearest siblings (get_company_overview shows only latest price; get_metric_history has period-end multiples), so an agent can route without opening any other schema.

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?

Gives explicit when-to-use rules with concrete examples ('AAPL close on 2025-07-28', a two-call point-to-point return, event-relative windows, no-dates case), plus the when-not signal (not SEC filings) and the cheaper two-narrow-window alternative to a wide window. Alternatives and their selecting conditions are all named.

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

All MetricDuck — Financial Analysis tools Inspect

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

Need Help?