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

With no annotations present, the description carries the burden of behavioral disclosure and does well by stating 'No account or write access,' establishing the tool as read-only and safe. It also discloses the self-describing behavior of omitting operation to discover available operations and schemas. It doesn't cover error behavior or pagination, but the core behavioral profile is transparent.

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 compact and front-loaded with the main read scope, followed immediately by the essential discovery instruction and safety note. Every clause adds distinct value, and the long data-type list is dense but not redundant.

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?

The tool appears to be a dynamic operation-driven venue-data API, and the description provides the key bootstrapping instruction: omit operation to discover schemas. The presence of an output schema helps cover return-value expectations. Some ambiguity remains around body/platform/parameters, but the discovery mechanism likely closes that gap.

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 for all parameters. The only parameter guidance given is that 'operation' can be omitted to discover names and schemas; body, platform, and parameters remain undefined. This leaves the agent guessing about the request structure.

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 starts with a clear, specific verb and resource: 'Read public historical markets/candles/trades...' and lists concrete data categories. It clearly identifies this as a read-only venue-data tool, though it doesn't explicitly differentiate it from overlapping siblings like foresea_price_history or foresea_recent_trades.

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 an actionable instruction: 'Omit operation to discover operation names and schemas,' which tells an agent how to bootstrap usage. It also implies this tool is for public read access, but it does not provide explicit when-to-use vs. alternatives guidance or exclusions for sibling tools.

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