Full trading day of intraday bars for one US stock (interval 3-240 min, default 3m). Every bar carries absolute open/high/low/close plus pct_open/pct_high/pct_low/pct_close (fractional change from that day's open), volume and transactions. $0.025 USDC.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | YYYY-MM-DD | |
| ticker | Yes | Stock ticker (e.g. AAPL) | |
| interval | No | Bar interval in minutes: 3, 6, 9, 12, 15, 30, 60, or 240 (default 3) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behaviors: returns a full trading day of bars, each bar contains absolute OHLC plus pct-change fields, volume, and transactions. It also discloses the cost ($0.025 USDC). This goes beyond simple data retrieval by explaining return structure and pricing, though it doesn't mention rate limits, timezone, or market session specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences pack all essential information: scope, interval, default, data fields, and cost. The opening phrase 'Full trading day of intraday bars' immediately captures the tool's core purpose. No irrelevant details or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description effectively explains the return format (OHLC, pct fields, volume, transactions) and also mentions pricing. It covers the main contextual needs for a data retrieval tool. Minor gaps like timezone handling or market session definition prevent a 5, but overall it is complete for typical usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by stating 'full trading day' (clarifying that 'date' means a single trading day) and 'one US stock' (context for ticker). It also previews interval range and default, which the schema already covers. This marginal addition justifies a slight upgrade.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'Full trading day of intraday bars for one US stock', specifying the verb (query/returns), resource (minute bars), and scope (one US stock, interval 3-240 min). It distinguishes from siblings like query_daily or get_bars by emphasizing 'intraday' and 'full trading day', making the tool's unique purpose explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this for intraday bars with configurable interval, defaulting to 3 minutes, for a single US stock on a specific date. While it doesn't explicitly name alternatives or exclusions, the scope ('full trading day', 'one US stock') implicitly differentiates from range/daily tools. It lacks an explicit 'use this instead of X' statement, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Several tools overlap significantly: get_bars, query_minute_bars, query_range, and query_batch all provide intraday bar data, making it hard to distinguish when to use which. Additionally, get_brief and get_fundamentals overlap in fundamentals coverage. The descriptions do not clearly delineate boundaries between these tools.
The naming pattern is a mix of get_* and query_* prefixes, with list_ and scan_ as exceptions. While each individual name is readable, similar operations like get_bars and query_minute_bars use different verbs, making the overall convention inconsistent.
15 tools is a reasonable count for a comprehensive financial data server, covering market data, fundamentals, filings, insiders, and scanning. The count is not excessive, though the overlapping intraday bar tools suggest some redundancy that could be consolidated.
The tool surface is fairly complete for its domain, offering intraday and daily market data, fundamentals, SEC filings, insider transactions, company profiles, and market scanning. Minor gaps exist (e.g., no dedicated dividend/split tool), but these are not critical and can be worked around via existing tools like get_brief.