listing_all_symbols

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

No annotations are provided, so the description carries full burden for behavioral disclosure. The description accurately states this is a read operation returning listed symbols, which is consistent with its nature. However, it doesn't disclose potential response size concerns (all symbols across three exchanges), whether the source parameter affects data freshness, or any rate-limit or permission implications.

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?

A single sentence that conveys the complete purpose with zero wasted words. It names the exchanges explicitly and is front-loaded with the core action ('Get all listed stock symbols'). There's nothing extraneous to trim.

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 list-retrieval tool with one optional parameter and an output schema present, the description is largely sufficient. The exchange coverage is explicitly stated. The only gap is that it doesn't distinguish itself from listing_symbols_by_exchange and listing_symbols_by_group siblings, which could cause an agent to select the wrong tool for a filtered query. But given the simplicity of the tool and good schema coverage, this is a minor omission.

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%, meaning the schema documents the single 'source' parameter with its default (VCI) and options (VCI or KBS). The description doesn't add meaning beyond the schema—it doesn't explain when to choose VCI vs KBS, what distinguishes these sources, or any quality/timeliness differences. Baseline 3 is appropriate when the schema fully covers parameters and description adds no additional context.

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 the tool's function: 'Get all listed stock symbols on Vietnamese exchanges (HOSE, HNX, UPCOM).' It uses a specific verb+resource (get/listed symbols) and explicitly scopes to Vietnamese exchanges, listing the exact exchanges covered. It distinguishes from sibling tools like listing_symbols_by_exchange and listing_symbols_by_group by indicating this is the comprehensive 'all symbols' retrieval rather than a filtered subset.

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 indicates this returns ALL symbols across HOSE, HNX, UPCOM, which implicitly suggests it's the broad-coverage tool compared to listing_symbols_by_exchange (per-exchange) and listing_symbols_by_group (grouped). However, it doesn't explicitly state when to prefer this over the sibling alternatives or mention any trade-offs such as response size or pagination. The context is implied rather than stated.

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