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

With no annotations, the description carries the full burden. It discloses data source, coverage, extended hours, archive start date, date range limits (max 5 trading days), and interval resampling behavior. However, it omits details about the `limit` parameter behavior, default date handling, and exact response format, leaving minor ambiguity.

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 with high information density. Front-loads the core purpose, then provides usage and constraints. No redundant phrasing or filler. Every clause adds value.

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?

For a tool with 6 parameters, no annotations, and no output schema, the description covers purpose, usage, data provenance, date constraints, and interval behavior. It lacks explicit mention of the response structure (e.g., OHLCV fields) and the effect of `limit`, but these are inferable from the term 'bars' and schema defaults. Overall, it is sufficiently complete for an agent to select and invoke 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?

Schema description coverage is only 17%, so the description must compensate. It does well by explaining date usage ('date=YYYY-MM-DD (or start+end, max 5 trading days)') and interval semantics ('1m is the native grain; 5m/15m/1h are resampled server-side'). The `limit` parameter is not addressed, but its schema definition provides default and max, so it's partially covered.

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 it provides 'Intraday minute bars for one equity' from FIRM's own market-data capture, with specific scope (~10.5k tickers, extended hours). It distinguishes itself from siblings by specifying 'one equity' and intraday granularity, and uses a specific verb ('bars') and 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?

Explicitly states when to use: 'when an agent needs REAL intraday price/volume history — how a ticker traded through an event, VWAP context, or a finer-grained chart than daily bars.' Also implies exclusions by saying 'one equity' and references daily bars as a contrast. This gives clear direction without needing named alternatives.

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