get_tick_data

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

Annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds further context by warning that the data 'Can be very large' and by noting the entitlement requirement. This goes beyond the annotations, though it does not mention pagination or response size limits; an output schema exists to cover return values. No contradiction with annotations.

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 two sentences, front-loaded with the main action, and every phrase adds value: the purpose, a warning about large data, an explicit alternative tool, and a prerequisite. There is no redundancy or fluff.

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 simple 2-parameter, read-only tool, the description covers the core purpose, a warning about data volume, a recommended alternative, and a prerequisite. The output schema handles return values. It is fairly complete but could include a note on maximum allowable days or pagination behavior.

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 0%, so the description must compensate. It clarifies the 'days' parameter via 'over the last N days' but does not explicitly describe the 'symbol' parameter, which is required. While symbol is self-evident from context, the description could have specified that the parameter is a symbol string. Thus it partially compensates but not fully.

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 begins with a specific verb 'Get' and resource 'tick-by-tick trades over the last N days', making the action and scope immediately clear. It also distinguishes itself from the sibling tool get_intraday_candles by explicitly recommending it as an alternative, resolving potential ambiguity.

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?

Provides explicit usage guidance: 'prefer get_intraday_candles beyond a single session' warns against using this tool for long ranges, and 'Needs the real-time quote entitlement' specifies a prerequisite. This tells the agent when to use the tool and when not to, which is exactly what this dimension requires.

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