mcp-tradecanvas

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), yet the description still adds real behavioral detail: the exact composition of the response and the non-obvious gotcha that output line keys are often not the indicator id ('RSI's line is `value`'), which directly prevents a common downstream mistake. It also discloses that lookup is alias-tolerant (id, short name, or full name), which is behavior an agent must know to call it correctly.

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?

It is a single front-loaded sentence with zero filler, and the most important framing ('One built-in indicator in full') leads. The heavy parenthetical nesting makes it denser than ideal, but every clause carries information the agent needs.

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 carries the full burden of explaining return values, and it does so field by field (params, inputs, lines, levels, code). For a one-parameter read-only lookup with full annotation coverage, nothing material is missing apart from unknown-id error behavior.

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 single `id` parameter is already fully documented. The description's 'Takes the id, the short name or the full name' largely restates the schema's 'id, short name or name' with no added syntax, casing, or ambiguity-resolution detail, so baseline 3 applies.

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 names a specific verb and resource (retrieving one built-in indicator in full) and enumerates exactly what comes back: default params, inputs, lines, levels, and sample code. The phrase 'One built-in indicator in full' implicitly contrasts with the sibling list_indicators, so an agent can tell retrieval from enumeration without opening a schema.

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?

Usage is only implied: the mention that the returned params are 'what addIndicator takes' and that lines are 'the keys getIndicatorOutput returns' tells the agent this is a prerequisite lookup before adding or reading an indicator. There is no explicit when-to-use statement, no exclusion, and no named alternative such as list_indicators for discovery, so guidance is present but inferred.

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

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

Annotations already establish read-only, idempotent, non-destructive, non-open-world behavior. The description adds useful behavioral detail about the returned record shape (type, points/anchors, pointer behavior, options) and search matching, though it does not discuss pagination or result limits.

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 tightly written sentences with the core purpose front-loaded. No wasted words, and the search behavior is appended efficiently.

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 read-only list tool, annotations cover safety, the schema covers the only parameter, and the description explains the returned fields despite there being no output schema. Enough information is present for correct invocation.

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?

The single query parameter is fully described in the schema, and the description restates its search target with examples ('fib', 'channel'). Because schema coverage is 100%, the schema already carries the primary semantics; the description adds only examples and slight clarification.

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: it lists built-in drawing tools. It further specifies exactly what is returned (type, anchor count, pointer behavior, options) and ties the type values to chart.addDrawing and chart.setDrawingTool, distinguishing it from sibling list 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?

Clearly indicates the tool is used to discover drawing-tool types for chart.addDrawing and chart.setDrawingTool, and explains that the query can search by type or name. It does not explicitly name when to choose a sibling instead, but the context is clear enough for an agent.

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

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.

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

Annotations already declare this as a read-only, idempotent, non-destructive, closed-world operation. The description adds useful behavioral context by describing the return contents: option name, TypeScript type, doc, and allowed values where applicable.

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 action and resource, then adds return details and search behavior in a compact two-sentence form. There is no wasted text.

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 read-only listing tool with rich schema and annotations, the description is nearly complete: it explains what is returned and how search works. Minor omissions such as ordering or pagination are not critical here.

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 both parameters are already documented in the schema. The description reinforces the query behavior and target entry points but does not add substantial meaning beyond 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?

The description states a specific verb and resource: it lists the options accepted by three named constructors, and it explains what each returned option includes. It is clear what the tool does, though it does not explicitly differentiate itself from siblings such as list_widget_features or list_style_keys.

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?

It implies usage by saying the tool lists constructor options and that users can search by words in the option name or doc. However, it gives no explicit when-to-use guidance versus alternatives and no exclusions or prerequisites.

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

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

The annotations already declare this as a safe, read-only, idempotent, non-destructive listing operation. The description adds useful semantic detail about value types and width limits, but it does not describe return structure, ordering, exhaustiveness, or other behavioral traits beyond what the annotations establish.

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 three well-structured sentences: purpose and value types first, usage destination second, and filtering guidance third. Every sentence contributes useful information without repetition or filler.

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 single-parameter listing tool with full annotation coverage and no output schema, the description is largely complete. It explains what is returned at a high level and how to narrow it, though it could be slightly more explicit about the shape of the returned data.

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%, and the single optional `prefix` parameter is already documented with examples. The description repeats the prefix-filtering behavior and adds one additional example (`series.candlestick.`), but it does not meaningfully extend the parameter semantics beyond 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?

The description uses a specific verb and resource: it lists chart style keys and the value types each accepts. It also situates the keys in Chart's `overrides` option and `chart.applyOverrides(...)`, which gives enough context to distinguish the tool from generic option-listing siblings, though it never explicitly names an alternative.

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?

It clearly explains the intended usage context: the returned keys belong in `overrides` or `chart.applyOverrides({...})`, and it suggests narrowing with a prefix. It does not state when to prefer this over `list_options` or other sibling tools, so it falls short of full alternative guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety behavior is covered. The description adds useful semantics beyond annotations: every switch defaults on unless set false, undotted names disable a whole capability, and dotted names target a specific location.

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 dense sentences with no waste. The core purpose and naming semantics are front-loaded, followed by the filtering behavior.

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 read-only listing tool with one optional parameter and no output schema, the description provides enough context to call it correctly. It could mention return ordering or exact output shape, but no critical information is missing.

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 the `prefix` parameter is already well documented in the schema. The description reinforces prefix narrowing but does not add substantial syntax or format detail beyond the schema's own example.

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 names accepted by ChartWidget's `features` option. The resource is precise enough to distinguish it from sibling list tools such as list_style_keys or list_indicators.

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 explains how to narrow results with a prefix, which implies when to use the optional parameter. It does not explicitly compare this tool with alternatives or state when not to use it, but the usage context is reasonably clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuinely useful behavior beyond them: unknown names come back with the likely intended one and with a note on which other entry point an option belongs to, and nested options are checked too. The instruction that functions and adapters must be written as strings ('they pass') flags a real gotcha that no annotation covers.

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 tool verb and the destination constructors are front-loaded, and the long enumeration of checked categories is dense rather than padded. It is a single heavy sentence plus one short corrective clause; readable, though the middle list could be trimmed without losing meaning.

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 validation entry point with nested, free-form input and no output schema, the biggest missing piece is what a result looks like — does it return a boolean, a list of messages, or throw? The description implies errors are described but never states the return shape or whether success is silent. Everything else an agent needs (target values, what gets checked, string-only functions) is present.

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% and the target enum is fully documented, so the baseline would be 3. The description earns more by explaining what the free-form `options` object is checked against and by calling out that nested options are included and that function/adapter values must be strings — semantics the empty `properties: {}` schema cannot convey.

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 gives a specific verb (checks/validates) and resource (an options object), and names the exact consumers it validates against: new ChartWidget, new Chart, new ChartWidgetGrid. It then enumerates the error classes it detects (unknown option names, out-of-range values, numeric strings, intervals, feature switches, style keys, languages), which makes it clearly distinct from the sibling list_* tools that only enumerate values.

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?

"before it goes to new ChartWidget, new Chart or new ChartWidgetGrid" establishes the timing and context of use clearly. It does not explicitly route the agent (e.g. 'use list_options when you need the valid names rather than a verdict'), so alternatives are left implicit, but the use case itself is unambiguous.

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