Skip to main content
Glama
Sign In

FinzData market data

by io.github.FinzData
OverviewDiscussionsAdmin

Get tick trades (every trade print)

get_ticks
Read-onlyIdempotent

Answers 'show me every NVDA trade on this day.' Give a symbol and a day (YYYY-MM-DD); optionally start/end times (HH:MM, US Eastern) to narrow the window, or omit day to list the days available. Returns every trade print (time in UTC nanoseconds and ISO, price, size, exchange, condition codes) for 1,100+ US stocks and ETFs over the last 5 years. Buyers get the trades; other keys get the day's trade count, first and last trade and the history options available. Free sample for every key: all trades on 2026-10-01 for SPY, QQQ, NVDA, AAPL, TSLA, MSFT, AMZN, META, AMD and IWM.

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": "get_ticks"
  }
}

Input Schema

NameRequiredDescriptionDefault
dayNoTrading day YYYY-MM-DD; omit to list available days.
endNoOptional end time HH:MM (US Eastern).
as_ofNoPoint-in-time cutoff (YYYY-MM-DD). Nothing dated after this is returned, preventing look-ahead bias. Defaults to today (UTC).
startNoOptional start time HH:MM (US Eastern).
symbolYesUS stock or ETF, e.g. NVDA, SPY.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare read-only, idempotent, non-destructive, closed-world behavior. The description adds genuinely useful context beyond that: tiered results (buyers get full prints, other keys get count/first/last trade), 1,100+ symbol coverage, 5-year history, and an explicit free sample. It omits volume/row-limit behavior, which matters greatly for tick data.

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 the motivating question, then symbol/day, then options, then returns, then entitlement and sample. Efficient overall, though the return-fields parenthetical and the sample sentence make it denser than strictly necessary.

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 no output schema, the description carries the burden of describing return values and does so (time in UTC ns and ISO, price, size, exchange, condition codes), plus explains degraded results for non-buyer keys. What's missing is any indication of result size limits or pagination for a potentially enormous tick stream.

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%, so all five parameters are already documented. The description restates the day format, the HH:MM US Eastern convention for start/end, and the omit-day-to-list-days behavior, adding little beyond the schema and saying nothing about as_of, the point-in-time cutoff.

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?

Opens with a concrete user question ('show me every NVDA trade on this day') and names the resource unambiguously: every trade print for one symbol on one day. The title's 'every trade print' implicitly separates it from bar-based siblings like get_bars, but no sibling is named explicitly, so the differentiation is inferential rather than stated.

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?

Gives clear usage patterns: supply symbol + day for trades, omit day to list available days, add start/end to narrow the window. It also discloses a free sample case. It stops short of saying when to prefer this over get_bars or other price tools, and doesn't state any exclusions.

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

All FinzData market data 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