Skip to main content
Glama

get_stock_prices

Read-onlyIdempotent

Price history (open, high, low, close, volume) plus dividends of a stock, ETF or index. interval '1d' = daily bars (full history available), '5m' = 5-minute bars of about the last month. points = how many of the newest bars to return (default 250, about one trading year of daily bars; up to about 500 fit in one answer). ETFs and indexes work like stocks, e.g. SPY, VOO, QQQ, DIA, IWM, VTI, bond funds TLT, IEF, SHY, AGG, BND, HYG, LQD, sector funds XLK to XLRE, GLD, IAU, SLV; indexes start with a caret: ^GSPC (S&P 500; ^SPX also works), ^DJI, ^IXIC, ^NDX, ^RUT, ^VIX, ^TNX. search_symbols finds the ticker of a fund or index by name.

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_stock_prices"
  }
}

Input Schema

NameRequiredDescriptionDefault
pointsNoHow many of the newest bars to return (default 250, about one trading year of daily bars).
tickerYesTicker symbol, e.g. AAPL, SPY or BTC-USD (crypto uses the -USD suffix).
filtersNoOptional extra filters as a JSON object of API parameter names and values, e.g. {"fiscal_year": 2025}. Call list_filters with this tool's name to see every accepted filter.
intervalNo'1d' for daily bars (full history) or '5m' for 5-minute bars (about the last month).1d

Output Schema

NameRequiredDescriptionDefault
dataNoThe records: a list of objects (or one object) with the requested data.
noteNoPresent when the answer was shortened, with how to get the rest.
rowsNoNumber of records the API returned (before any shortening).
errorNoPresent when the call failed, with the reason.
detailNoExtra error detail from the API, e.g. which filter is required.
pagingNoFor paged answers: offset, rows_shown, total and next_offset (call again with offset=next_offset for more rows).
endpointNoDataPorium API endpoint that answered, e.g. /company-info.
filters_sentNoFilters sent to the API for this answer.
allowed_filtersNoOn an unknown-filter error: the filters this endpoint accepts.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedOutput schema / properties / paging
      Added value: +{
      +  "anyOf": [
      +    {
      +      "additionalProperties": true,
      +      "type": "object"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "For paged answers: offset, rows_shown, total and next_offset (call again with offset=next_offset for more rows).",
      +  "title": "Paging"
      +}
  2. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely useful operational constraints the annotations don't carry: the ~1 month limit for 5m bars and the ~500-bar ceiling per answer.

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, interval semantics and the points cap before the examples. The long ETF/index ticker enumeration is the one stretch that could be trimmed, but it does real disambiguation work for caret-prefixed indexes.

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?

An output schema exists, so return values need no explanation. Combined with interval semantics, result-size limits, ticker format guidance and a pointer to search_symbols, an agent has everything needed to call this correctly.

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 goes further by noting the practical cap of about 500 bars per response and by enumerating valid index/ETF ticker forms (caret-prefixed indexes) that the schema's examples don't cover.

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 — price history (OHLCV) plus dividends — and scopes it to stocks, ETFs and indexes. This clearly separates it from siblings such as get_commodity_prices, get_fx_rates and get_options_chain, which cover different asset classes.

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?

Explains the two interval modes and their data horizons ('1d' full history vs '5m' about the last month) and points the agent to search_symbols for finding a fund/index ticker. It does not explicitly state when to prefer a sibling tool over this one, but the usage context is unambiguous.

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