SiteCheck Crypto & Finance

Daily historical prices for a US stock, ETF or index: date

finance_stooq_historical_stocks

Read-only

Daily historical prices for a US stock, ETF or index: date, open, high, low, close and volume, newest first, for any date range up to 10 years back (max 1,000 rows per call). Data from Nasdaq.com's public historical quotes API (Stooq blocks automated downloads). Price: $0.002 in USDC per successful call, paid with x402 (Base, Solana or Arc); failed calls are not charged.

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": {
      "symbol": "<symbol>"
    },
    "name": "finance_stooq_historical_stocks"
  }
}

Input Schema

Name	Required	Description
`to`	No	End date YYYY-MM-DD (default today)
`from`	No	Start date YYYY-MM-DD (default 30 days ago)
`limit`	No	Rows, 1 to 1000 (default 100)
`symbol`	Yes	US ticker, e.g. AAPL, SPY
`assetClass`	No	stock (default), etf or index (Nasdaq indexes only: NDX, COMP...; for S&P 500, Dow or Russell use the ETFs SPY, DIA, IWM)

Output Schema

Name	Required	Description	Default
`to`	No
`from`	No
`prices`	No
`source`	No
`symbol`	No
`checkedAt`	No
`totalRecords`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 31, 2026

changedInput schema / properties / assetClass / description

Previous value: -"stock (default), etf or index"New value: +"stock (default), etf or index (Nasdaq indexes only: NDX, COMP...; for S&P 500, Dow or Russell use the ETFs SPY, DIA, IWM)"

First observedOct 23, 2026

TDQS

A3.9/5.0

Behavior5/5

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

Beyond the readOnly/openWorld annotations, the description discloses a paid-call model ($0.002 USDC per successful call via x402 on Base, Solana or Arc), that failed calls are not charged, the 1,000-row cap, the 10-year lookback ceiling, and the newest-first ordering. These are concrete behavioral traits an agent cannot get from the annotations or schema, and none of them contradict the declared read-only, open-world profile.

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 a single dense passage that front-loads the resource and returned fields before the operational limits and pricing. Every clause carries information, though the parenthetical about Stooq is a minor aside that could be trimmed.

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

Completeness4/5

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

With an output schema present, return values need no explanation, and the description still covers data source, cost, row and date limits, and ordering. It stops short of addressing edge cases such as invalid tickers, empty ranges, or how the 1,000-row cap interacts with long date ranges (truncation vs error).

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 symbol, from, to, limit and assetClass in detail, including the index-vs-ETF workaround for S&P 500/Dow/Russell. The description only reinforces the row cap and date ceiling plus the output ordering, which is minimal added meaning over the structured fields.

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

Purpose4/5

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

The description gives a specific verb-like scope (daily historical prices) plus the exact returned fields (date, open, high, low, close, volume) and the asset universe (US stock, ETF or index). It also names the underlying data source (Nasdaq.com), which helps distinguish it from overlapping siblings like finance_yahoo_finance or finance_stockanalysis, though it never explicitly says how it differs from those tools.

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

Usage Guidelines3/5

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

It states hard operating bounds (any range up to 10 years back, max 1,000 rows per call), which implicitly tells the agent when the tool is usable. However, there is no explicit when-to-use versus when-not guidance and no reference to the many sibling price tools, so the agent must infer selection from the name and source note.

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

All SiteCheck Crypto & Finance 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?