FREE, no payment: real intraday OHLCV bars for AAPL on 2024-01-02, identical in shape to a paid query. Call this first to verify data quality before spending. Takes no arguments — fixed ticker and date.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: it is free ('FREE, no payment'), returns real data ('real intraday OHLCV bars'), and produces output identical to a paid query. It also notes it takes no arguments, providing complete cost and data authenticity expectations.
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?
The description is three short sentences, each earning its place: it states the data delivered and cost, instructs when to use it, and clarifies the parameter constraints. No wasted words.
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?
Given the tool's simplicity (zero params, no output schema), the description is complete: it covers purpose, cost, usage timing, and limitations. The reference to 'OHLCV' implies the standard return fields, making it sufficient for an agent to select and invoke the tool correctly.
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?
Although the schema is empty, the description adds meaningful semantics by explicitly stating 'Takes no arguments — fixed ticker and date' and naming the fixed values (AAPL, 2024-01-02), which the schema cannot convey. This exceeds the baseline for zero-parameter tools.
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 what the tool does: it returns real intraday OHLCV bars for AAPL on 2024-01-02. It distinguishes itself from sibling tools by explicitly being a free, fixed-parameter sample identical in shape to a paid query, which is a distinct resource.
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?
It provides explicit when-to-use guidance: 'Call this first to verify data quality before spending.' This tells the agent to use it as a trial before using paid queries, and the fixed ticker/date limitation implies it is not for arbitrary queries.
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.