pro_get_trades

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

The annotations already establish read-only, idempotent, non-destructive behavior, so the bar is lower. The description adds meaningful context by noting the response is a paginated list with metadata, enumerating the returned trade fields, and tagging the data as [PRIVATE]. These details go beyond the structural hints and help an agent understand what to expect.

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 front-loaded with the core purpose and customer-facing summary of behavior, followed by a compact filter list, a use case, and a response note. Every sentence adds useful information; there is no filler or redundancy.

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 has nine optional parameters but a fully descriptive schema, and no output schema, the description appropriately covers what the tool returns and that it is paginated. The [PRIVATE] tag plus the read-only annotations provide enough safety and authorization context for an AI agent to invoke it 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 100%, so the input schema carries the semantic weight for all nine parameters. The description merely summarizes filters such as pair, side, date range, limit, offset, and sort order, without adding new meaning beyond the schema. This meets the baseline but does not exceed it.

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 states a specific verb and resource: 'Gets the user's trade history in Pro Trading.' It clarifies that it returns executed trades with concrete fields, distinguishing it from pro_get_open_orders and pro_get_public_trades. The account-scoped 'user's trade history' also parses it apart from order-level or public trade tools.

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 gives clear context in 'Use this to review past trading activity,' which tells an agent when to select this tool. It does not explicitly name alternative tools or exclusions, but the purpose statement and response details are enough to guide selection among the sibling trade-related tools.

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