get_fx_parameters

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

With no annotations, the description carries the full burden, and it does disclose one important trait: output is auto-paginated. That is genuinely useful context an agent could not infer from the schema. However, it never states that the operation is read-only, nor whether it errs on ambiguity (the schema hints at errors for multi-match track_contains), so behavioral coverage remains partial.

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 compact sentences, zero filler. The scope constraint and the return-field list lead, and the usage directive follows, so the most decision-relevant information is front-loaded.

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 9-parameter tool with no annotations and no output schema, the description does useful work (it substitutes for the missing return-value doc via the field list, and flags auto-pagination). But it leaves the majority of parameters semantically unexplained, so an agent must still reverse-engineer fx_scope, fx_index, and the track-selection cluster from the schema alone.

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?

Nine parameters with only 56% schema description coverage, and the description explains none of them beyond urging the use of param_index. Non-obvious parameters like fx_index, fx_scope (the only enum), and include_values receive no clarifying text in the description, so the coverage gap is not compensated.

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?

States a specific verb and resource ('Full parameter list for ONE FX'), scopes it (single FX, not a bank), and enumerates the returned fields (index, name, normalized value, display value). The 'ONE FX' emphasis plus the return-field list clearly separates it from scan_fx, which presumably covers many plugins.

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?

'Scan before setting parameters; prefer param_index from this scan over name matching' gives a clear workflow trigger and an explicit preference over the alternative (name matching), presumably feeding set_fx_param. It stops short of naming the sibling tools it pairs with or stating when this scan is unnecessary.

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