List built-in indicators

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds value beyond that by describing the shape of the returned record (id, name, placement) and explaining what placement values actually mean operationally, which matters because no output schema exists. It doesn't discuss result size or ordering, a minor gap.

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?

Three short sentences, front-loaded with the tool's output, then search semantics, then the downstream call pattern. Nothing is padded and every clause carries information the agent needs to call it and use its results.

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?

With no output schema, the description correctly takes on the job of describing the return fields and their meaning, and it explains the relationship to get_indicator so the two-tool workflow is complete. Only result-set characteristics (ordering, whether no query means full listing) are left unspecified, which is a small residual gap for a two-optional-parameter tool.

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 coverage is 100%, so 3 is the baseline, but the description earns more: it clarifies that the query matches against words of the id or name and gives real example searches ("moving average", "bollinger"), which conveys partial/word matching rather than exact match. The placement parameter's two enum values are restated in plain domain language (price pane vs own pane), reinforcing the schema.

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 ("Lists the built-in indicators") and immediately enumerates what comes back: ids, names, and draw placement. The overlay-vs-panel distinction plus the pointer to get_indicator separates it cleanly from the sibling tools, which all deal with options, drawing tools, style keys or a single indicator's details.

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 a concrete usage path: search here with words like "moving average" or "bollinger", then feed the returned id into chart.addIndicator(id, params). It explicitly routes the agent to get_indicator for params and line keys, so the split between the two tools is unambiguous. It stops short of stating exclusions or edge cases (e.g. empty query returns everything), which keeps it at 4 rather than 5.

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