Basis

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

The description discloses useful behavioral context beyond annotations: nothing is armed until the user opens and confirms the link, no account is needed, and the link lasts seven days. This is especially valuable because annotations mark destructiveHint=true but the description clarifies the deferred activation model, without directly contradicting the annotation.

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 sentences, no filler, and the most important usage guidance is front-loaded. Every sentence earns its place: what the tool does, when to use it, how to choose between price and conditions, and what to return.

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?

Given 12 parameters and no output schema, the description covers the essential decision between price and conditions, and gives output guidance ('Give the URL as a link and say in one line what it watches'). It doesn't enumerate all parameter combinations, but the schema covers the parameter-level details, and the deferred-activation and expiry behavior are disclosed.

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 description adds meaning beyond the schema by explaining the core branching logic: pass price for a price-level alert, pass conditions for anything else, and how 'when' behaves relative to current price. With 83% schema coverage, most parameter details already live in the schema, and the description's additions are targeted and useful, though it doesn't explain every optional parameter.

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 action (prepare a price or indicator alert link), a clear resource (a one-click Basis alert link), and the intended scenario (when the user wants to be told when a level breaks, RSI crosses 70, or price moves 5%). This distinguishes it from siblings like chart_link or indicator_compute by focusing on alert generation rather than chart or indicator manipulation.

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 explicitly says 'Use it whenever the person wants to be told when something happens', giving clear when-to-use context. It does not name sibling alternatives or explicitly state when not to use it, but the examples and the 'price vs conditions' branching provide enough orientation for an agent to select it correctly.

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 cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false). The description adds genuinely valuable behavior beyond those: fill timing ('next bar's open') and cost modeling ('costs are charged per side'), plus a critical evaluation caveat about not judging on total return. No contradiction with annotations.

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 sentences, zero waste. The core purpose is front-loaded, the execution model follows, and the evaluation guidance closes. Every sentence earns its place and there is no redundancy with the schema or annotations.

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 complex tool with 13 parameters, a nested params object, and no output schema, the description covers the most agent-critical facts: scope, execution model, and how to interpret the return value ('risk-adjusted metrics alongside the raw return'). Remaining gaps — how the nested params object is structured, where valid strategyIds come from, and the context-dependent 'default: the chart' behavior — are not addressed, but the description's emphasis on evaluation criteria is the highest-value missing piece for correctness.

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 69%, so the schema already documents most parameters and the description need not repeat them. The description does add meaning tying to parameters — 'charged per side' clarifies feeBps semantics, and 'one set of parameters' scopes the nested params object. But it doesn't explain how the params object maps to strategy inputs or clarify the relationship among ref, exchange, and symbol, so it only partially compensates for the uncovered 31%.

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 ('backtest') and resource ('one built-in strategy'), with a scope qualifier ('one set of parameters'). This clearly distinguishes the tool from siblings like screener_backtest (which presumably backtests screener results across many strategies) and strategy_research. An agent can tell what this tool does without opening the 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?

The scoping language 'one built-in strategy with one set of parameters' gives clear context for when to invoke this tool, and the instruction to 'judge on risk-adjusted metrics, not on total return' is actionable usage guidance. However, it never names an alternative explicitly (e.g., screener_backtest) or states exclusions, so it stops short of full routing 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 establish readOnly, non-destructive, idempotent behavior, so the description's additional job is to add behavioral context. It does this well by revealing that date provenance varies (live, published rule, estimate, user) and that the tool intentionally omits non-derivable events. This gives the agent useful expectations about certainty and scope beyond the annotations.

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 tool's scope, then explains provenance and exclusions in the second sentence. Every sentence earns its place: the event list establishes coverage, the provenance sentence shapes expectations, and the exclusion sentence prevents misuse. It is verbose but information-dense rather than padded.

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 compensates by stating that each row indicates its date source and explaining the certainty differences between derived and fixed dates. It also covers intentional gaps like FOMC/CPI. A minor gap is that it does not describe the full return shape or other row fields, but the tool is simple and the provided context is sufficient 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?

Schema coverage is 100%, and all four parameters already have descriptions in the schema. The description does not add new meaning to days, limit, impact, or symbol, so the baseline of 3 applies. It does not compensate for missing schema information because none is missing.

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 identifies a specific resource—upcoming scheduled events—and enumerates the exact event types it covers (funding settlements, Bitcoin halving, difficulty retargets, options expiry, CME settlement, non-farm payrolls). It also distinguishes the tool from all siblings by stating 'nothing else here looks forward.' This is far beyond a tautological restatement of the name.

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 explicitly says 'Use it before saying anything about what happens next; nothing else here looks forward,' giving a clear when-to-use condition. It also explains deliberate exclusions (FOMC and CPI) because their dates are announced rather than derivable, which indirectly tells the agent not to expect them here. It stops short of naming a specific alternative tool for those announced-event cases, so it is not a perfect 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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds value by disclosing what the call returns for each kind (parameters/defaults, signature, strategy parameters), which helps the agent predict the outcome. It does not cover error behavior for unknown ids, but that is a minor gap for a simple read-only lookup.

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 sentences, no filler. The first sentence front-loads the purpose and enumerates the kind-specific returns, and the second delivers a direct usage directive. Every word earns its place.

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 two-parameter, read-only lookup with rich annotations and no output schema, the description covers what the tool does, what it returns per kind, and when to call it. It is nearly complete; only id provenance and unknown-entry error behavior are unaddressed, and neither is critical.

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?

With 0% schema description coverage, the description must carry the semantic weight, and it meaningfully does so for kind: it maps each enum value to the form of detail returned. The id parameter is left as an implied catalogue-entry reference with no guidance on where valid ids come from (e.g., catalog_search), which is a partial gap.

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 clear verb-plus-resource purpose: 'Full detail for one catalogue entry' with the detail types enumerated (indicator parameters/defaults, formula signature, strategy parameters). It is cleanly distinguishable from the sibling catalog_search, which finds entries, whereas this tool returns full detail for a single entry identified by kind and id.

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?

'Call this before passing parameters you have not seen' is explicit, actionable when-to-use guidance tied directly to downstream tool calls. It does not name alternatives like catalog_search or state when not to use the tool, so it stops short of a full 5, but the use condition is unambiguous.

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=true, idempotentHint=true, and destructiveHint=false, so the description doesn't need to repeat safety. It adds genuinely useful behavior: an empty query lists everything of a kind, and guessed drawing tool ids are refused. Together these go beyond schema and annotations to explain operational quirks.

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 zero filler. The first sentence establishes scope, the second covers usage rules and the empty-query affordance. Every clause carries information an 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?

For a read-only catalogue search with only 3 params, the description covers purpose, when-to-use, the empty-query behavior, a failure mode, and the exact scope of what will be returned. Annotations supply the safety profile Token. No output schema is present, but the description hints at output contents sufficiently for an agent to decide call validity.

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?

Two of three parameters (limit, query) already have schema descriptions, and the description reinforces the meaning of 'query' by stating empty query lists everything of a kind. The 'kind' parameter lacks a schema description, but the description inlines its allowed values anyway ('indicators, formula functions, built-in strategies, ... drawing tools'). This compensates for the uncovered enum.

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 opens with a specific verb 'Search' and enumerates the concrete resources: indicators, formula functions, built-in strategies, extra series in strategy expressions, and drawing tools with their anchor counts. This clearly distinguishes it from siblings like catalog_describe and drawing_add by naming exactly what the catalogue contains.

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?

Explicit usage guidance is given: 'Use this before assuming something does or does not exist — and always before drawing.' It also supplies a consequence ('a drawing tool id you guessed is refused') and explains how to list everything of a kind with an empty query. This gives an agent an unambiguous decision rule for when to invoke this tool.

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 description states 'Changes the chart you are building,' which reinforces the annotations' readOnlyHint=false and discloses the mutation side effect. It also adds the default-value behavior for omitted params and the linking step, which are useful beyond the schema and annotations. No contradiction with annotations.

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 sentences front-load the core purpose, then add parameter guidance, default behavior, and the chart_link follow-up. Every sentence earns its place and there is no repetition of schema data.

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 two-parameter mutation tool with no output schema, the description covers invocation, parameter resolution, default behavior, and post-call chart linking. It is complete enough to call safely; a small gap is not describing what happens with an invalid or unrecognized studyId.

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?

With 0% schema description coverage, the description compensates by explaining studyId as an id or common name with concrete examples ('ema20', 'bollinger') and delegating params to catalog_describe for details. It could enumerate params, but it clearly orients the agent on how to populate both fields.

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 opens with a specific action and resource: 'Put an indicator on the chart.' It clearly distinguishes the tool from sibling mutation tools like chart_remove_indicator, chart_toggle_indicator, and chart_update_indicator by describing the add operation.

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 gives practical usage context: studyId can be an ID or common name, catalog_describe is the source for parameters, and chart_link should be called when finished so the person can open the chart. It does not explicitly name alternate chart tools, but the workflow around building and sharing a chart is 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 are sparse (readOnlyHint=false, openWorldHint=true), so the description carries the behavioral burden. It discloses that the tool can both render the existing chart and build one from provided parameters, and it warns that pixels are for shape while exact numbers should come from figures or data tools. This is useful beyond the annotations.

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: purpose first, then usage guidance, then a practical caveat about numeric precision. Each sentence earns its place, and there is no 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?

With no output schema, the description usefully mentions that the response includes both a PNG and the exact figures shown. It also covers the two usage paths and the main parameter groups. It stops short of detailing response structure or persistence effects of one-call building, but these are not critical gaps for typical 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?

Schema coverage is high at 75%, and the description reinforces the meaning of key parameters by explaining that symbol, timeframe, indicators, and levels can be passed to build a chart in one call. It adds workflow context without needing to restate the schema's field-level descriptions.

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 the specific resource (a PNG of the current chart) and its exact contents: candles, volume, indicators, drawings, and the figures it displays. It also distinguishes the tool from sibling chart tools by framing it as the way to 'see' what has been built.

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 says when to use the tool ('to check structure, levels and what you drew before you describe them') and explains the two entry modes: build first with chart tools, or pass symbol/timeframe/indicators/levels to build and view in one call. It does not explicitly name an alternative tool, but the guidance is clear enough.

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 description adds meaningful behavior beyond the annotations: no account is required, the link expires after seven days, and the note is only for the agent's reply. The destructiveHint annotation is not reflected in the text, but nothing in the description directly contradicts it.

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?

Four sentences, front-loaded with the purpose, and every sentence adds either a workflow, timing, or retention detail. No filler or repetition.

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 publish tool with no required parameters and no output schema, the description covers the action, the two invocation paths, the output instruction (return the URL as a link with a one-line caption), and the auth/expiry constraints. Nothing essential 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?

The description names the main build parameters (symbol, timeframe, indicators, levels) and explains their role in the one-call workflow, supplementing the schema. It does not discuss exchange or market, but those are enum-constrained and low-risk.

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 opens with a specific action and deliverable: 'Publish the chart and get a URL the person can open in Basis.' This clearly distinguishes it from sibling chart tools that mutate chart state or return images, even though no sibling is named.

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 gives explicit timing ('Call it at the end of any answer about a market') and two workflows ('build first with the chart tools, or pass symbol, timeframe, indicators and levels here'). It does not state exclusions or when a sibling like chart_image would be preferred.

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 description adds workflow behavior beyond the annotations: the operation changes the chart being built, and chart_link must be called afterward for the result to be openable. It also tells the agent to source instanceId from chart_state, which is useful behavioral context. It does not contradict the annotations.

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 are front-loaded with the core action, then the parameter source, then the required follow-up workflow. Every sentence earns its place and there is no 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 one-parameter mutation with minimal annotations, the description covers the action, the parameter source, and the essential follow-up (chart_link). It does not cover failure modes or explicitly rule out sibling tools, but an agent has enough to invoke it correctly.

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 supply meaning for the only parameter. It does so by explaining that instanceId comes from chart_state, giving the agent a concrete way to obtain the value. It does not describe exact format, but the schema already gives the type and required status.

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 clear action ('Take an indicator off the chart') and identifies the resource and the key input source ('instanceId from chart_state'). It is easy to understand, though it does not explicitly distinguish removal from the sibling chart_toggle_indicator, so it is not fully differentiated.

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 gives clear usage context: this mutates the chart being built and should be followed by chart_link so the person can open the chart. It does not explicitly state when to prefer this over chart_toggle_indicator or chart_update_indicator, so it lacks exclusions.

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?

With all annotations false, the description carries the burden. It discloses that the tool changes the chart being built and implies a side effect, but it does not mention idempotency, reversibility, or any potential impact on existing indicators or settings. The statement 'This changes the chart you are building' adds some transparency but is thin for a mutating tool.

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 one concise sentence plus an example and a contextual note. The main action is front-loaded, and every sentence adds meaning. There is no fluff, making it efficient and easy to parse.

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 has three parameters with one required and two enums, yet the description does not clarify that only symbol is required while exchange and market are optional. It also fails to explain the 'market' parameter, leaving the agent to guess. The effect on the chart is mentioned, but the description is incomplete for a tool with these parameters and no output schema.

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 0%, so the description must compensate. It explains the format for symbol and exchange ('as the exchange writes them') and gives an example, but it does not address the 'market' parameter (spot/futures) at all. The description adds value for two of three parameters but leaves the third entirely undocumented.

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 clear action ('Point the chart at a market'), names the resource (chart instrument), and provides a concrete example (BTCUSDT on binance). It also explains the effect on the chart being built, distinguishing it from other chart manipulation tools like chart_set_timeframe or chart_set_type by the specific verb and context.

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 implies when to use this tool (when building a chart and needing to set the market) but does not explicitly compare it to alternatives or state when not to use it. It mentions the chart is linked via chart_link, which gives some context, but there is no exclusionary 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 are all false and uninformative, so the description carries the behavioral disclosure burden. It explains that the tool modifies the chart being built and that the result is not accessible until chart_link is called, which is a useful behavioral caveat. A simple setter does not require extensive side-effect documentation.

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 sentences, no filler, with the key action first and the required follow-up second. Every sentence earns its place.

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 single-parameter state-changing tool, the description covers what is changed, gives valid example inputs, and states the necessary follow-up call. Nothing essential is missing for an agent to invoke it correctly.

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 schema only defines timeframe as a string with no enum or format, so the description's examples ('15m, 1h, 4h, 1d') add essential meaning. It does not provide a complete allowed-values list, but the examples are enough for common usage.

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 ('Change') with a precise resource ('the chart timeframe') and provides concrete examples ('15m, 1h, 4h, 1d'). It clearly differentiates the tool from siblings like chart_set_instrument and chart_set_type.

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 places the tool in the chart-building workflow and explicitly instructs calling chart_link afterward so the person can open the chart. It does not enumerate alternatives, but the purpose is distinctive enough that an agent can infer when this tool is appropriate.

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 provide no hints (all false), so the description carries the burden. It discloses that invalid ids are rejected and the error lists valid options, and that the tool mutates the chart being built. It also mentions the follow-up step of calling chart_link. This goes beyond the annotations, though it doesn't cover every possible side effect.

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 sentences, front-loaded with the core action and examples, then error behavior and workflow hint. No fluff; every sentence adds value.

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 single-parameter tool with no output schema, the description covers the purpose, examples, error handling, and the necessary follow-up action (chart_link). It's sufficient for an agent to call it correctly.

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 0% with no enum, so the description must clarify the chartType parameter. It lists example values (candles, heikin ashi, line, renko, footprint) and notes that a wrong id is refused, implying the parameter accepts an id. This adds meaning beyond the bare string type.

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 ('Change how price is drawn') and resource (the chart's price display), with concrete examples (candles, heikin ashi, line, renko, footprint). It clearly distinguishes from sibling tools like chart_set_instrument or chart_set_timeframe by focusing on the drawing style.

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 gives clear context: it's for changing the chart type while building a chart, and instructs to call chart_link afterward. It doesn't explicitly name alternatives, but the purpose is clear enough that an agent would know when to use this tool. It also mentions error handling (wrong id refused) which guides usage.

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 is read-only and idempotent. The description adds useful context by explaining the state includes every indicator and drawing with instance IDs, and that after modifications the tool can be re-called to confirm what landed. This goes beyond annotations without contradicting them.

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 filler. The content and primary use case are front-loaded, with the follow-up action (chart_link) placed at the end. Every clause earns its place.

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 zero-parameter read-only state tool, the description covers what the state contains, why an agent would call it, when to call it again, and the follow-up tool to use. No additional behavioral or return-value information is needed 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 tool has no parameters, and the input schema reflects that with an empty properties object. There is nothing for the description to add about parameters; the baseline of 4 applies, and the description appropriately focuses on the returned state rather than parameters.

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 the exact resource—the chart state for a specific person—and enumerates its contents: venue, symbol, timeframe, chart type, indicators with instance IDs, and drawings. It also states an explicit use case, retrieving instance IDs, which distinguishes it from chart_* sibling actions like chart_set_instrument or chart_add_indicator.

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 gives explicit when-to-use guidance: 'Start here when you need an instance id' and 'call it again after changes to confirm what landed.' It also directs the final step to chart_link. It lacks explicit when-not-to-use or alternative comparisons, but the context is clear enough for an agent to decide when to invoke it.

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 description explains that the operation changes the chart being built and that chart_link must be called afterward, which goes beyond the annotations. It also clarifies that the indicator is hidden/shown rather than destroyed, aligning with destructiveHint=false and readOnlyHint=false.

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 two sentences long, front-loads the core purpose, and every sentence earns its place. It is clear, direct, and free of unnecessary detail.

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 is simple with one parameter and no output schema, and the description covers purpose, usage context, and mutation behavior. However, the missing explanation of instanceId is a notable gap that prevents the description from being fully self-sufficient.

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 description does not explain what instanceId refers to; schema coverage is 0%. While the tool name suggests it identifies an indicator, the definition leaves the parameter meaning implicit and does not compensate for the schema's lack of description.

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 ('hide or show') and resource ('an indicator'), and differentiates itself from removal with 'without removing it.' It clearly communicates the tool's purpose and distinguishes it from sibling tools like chart_remove_indicator.

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 clear context: it is useful for comparing a chart with and without an indicator, and it instructs the agent to call chart_link when done. It does not explicitly spell out when not to use it, but the 'without removing it' phrasing implies the boundary with removal tools.

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 indicate this is not read-only and not destructive, aligning with the description stating it 'changes the chart you are building'. It adds a workflow requirement (call chart_link) and clarifies the identification nuance, providing useful behavioral context beyond the annotations.

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 sentences with no waste, front-loading the core purpose and then adding the identification and workflow notes. Efficient and well-structured.

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 description covers the essential steps: identify by instanceId, change settings, and link the chart. It lacks details on the params structure and error handling, but given the simplicity and the existence of sibling tools, it's reasonably complete for an agent to invoke correctly.

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 description explains that instanceId is from chart_state and that the same indicator can appear multiple times, which adds meaning beyond the schema. However, it doesn't elaborate on the structure of the 'params' object, which has 0% schema coverage, leaving the agent to infer what settings to pass.

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 'Retune' with a clear resource 'indicator already on the chart' and differentiates from siblings by emphasizing the instanceId identification rather than study id. This distinguishes it from chart_add_indicator, chart_remove_indicator, and chart_toggle_indicator.

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?

Provides context that instanceId comes from chart_state, implying the agent must fetch chart_state first, and mentions the workflow of calling chart_link after changes. It doesn't explicitly name alternative tools or state when not to use it, but the phrasing implies other tools for add/remove.

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 readOnly, idempotent, openWorld false, and non-destructive behavior. The description adds value beyond these by explaining that the tool contains no live market data and that its findings include measured sample/verdict pairs plus clearly marked unmeasured conventional readings. This gives the agent an accurate model of what the tool will and will not provide.

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 two sentences and front-loads the core nature of the tool before adding usage guidance. It is dense but not wasteful; nearly every clause adds a distinct piece of information. The 'part worth calling for' aside is slightly editorial but does not undermine clarity.

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?

Given the simple one-parameter shape and existing annotations, the description covers the tool's content, its non-live nature, and when to call it. However, with no output schema and no per-topic explanation, the agent is left to infer what each enum value will produce and what the returned 'verdict' or 'sample' structure looks like. Adequate, but with meaningful gaps.

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?

There is one required enum parameter with 0% schema description coverage, so the description must compensate. It mentions 'topic' once but never explains the eleven enum values or how choosing one affects the returned knowledge. For example, an agent cannot tell from the description what 'workflow' or 'whale-positioning' would return. The enum names are somewhat self-descriptive, but the description itself does not provide the needed semantics.

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 identifies a knowledge/domain-guide resource for crypto analysis and lists concrete content: topic constraints, the Basis tool chain, measured findings with sample and verdict, and unmeasured conventional readings marked as such. It does not use an explicit retrieval verb and does not name a sibling, but the 'no live market data' boundary distinguishes it from market-data tools in the sibling list.

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 explicit call contexts: 'Call it before analysing a chart pattern, interpreting an indicator level, designing a strategy or judging a result that looks strong.' It also states a clear limitation ('It carries no live market data'), though it does not name specific alternative tools or say when not to use it beyond that live-data exclusion.

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=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context: the scan is 'symmetric', uses 'the same top-volume universe', and returns 'rule-independent breadth' and '24h liquidity semantics'. The specific caveat that 'a low match count is never reported as breadth' is valuable and prevents misinterpretation of results. No contradiction with annotations.

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 sentences with no filler: core action and outputs, usage sequence, and an important caveat. It is front-loaded with 'Run one symmetric long/short scan...' and every sentence adds distinct value. Ideal length for the information conveyed.

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?

This is a complex 9-parameter tool with no output schema, and while the description explains the broad output categories and workflow, it does not specify the return format, how breadth vs. candidates are represented, or how parameters like quote/timeframe interact with the scan. It is adequate for initial orientation but not fully complete for a tool of this complexity; the agent would likely need to inspect the schema or call the tool to fully understand the results.

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?

With 56% schema description coverage, the description needed to compensate by explaining parameter intent, but it does not address individual parameters beyond implying longRules/shortRules and universeSize through 'long/short' and 'top-volume universe'. It adds no guidance for quote, lookback, timeframe, limitPerSide, or manualSymbols. The schema descriptions carry the main burden, and the tool description does not enhance parameter understanding meaningfully.

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: 'Run one symmetric long/short scan over the same top-volume universe' and enumerates concrete outputs ('rule-independent breadth, 24h liquidity semantics and ranked directional candidates'). It also distinguishes itself from downstream analysis tools by positioning itself as the first pass before deep-dive with derivatives/order-flow tools. This is far more specific than a generic 'scan' and leaves little ambiguity about what the tool does.

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 explicit guidance: 'Use this first for comprehensive day-trade or scalp discovery; then deep-dive only the shortlist with derivatives/order-flow tools.' This clearly tells the agent when to invoke this tool and what to do next. However, it references tool categories rather than specific sibling names like 'screener_run' or 'orderflow_read', so the routing is clear but not as precise as naming exact alternatives.

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 are all false (readOnly, destructive, idempotent, openWorld), so the description carries the full burden. It discloses that the tool 'Changes the chart you are building', explains validation behavior (refused if outside window when ref given), and describes the response echo ('echoes back what was drawn') – all beyond the schema.

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 ~150 words and front-loaded with the core purpose and coordinate rule. Every sentence adds value, though a few details (e.g., 'The result echoes back...') could be tightened without losing information. Still, it's appropriately sized for a 19-parameter tool.

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?

Given the tool's complexity (19 params, no output schema, 58% schema coverage), the description covers essential context: coordinate semantics, point counts, validation with ref, sibling routing, and the final chart_link step. Nothing an agent needs to invoke it correctly 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 58%, so the description adds substantial meaning. It explains the points format (time in seconds matching candle timestamps, one point for horizontal line, two for trendline/box), the tool parameter format, the reserved meaning of 'up'/'down' colors, and when to pass the ref handle. This complements the schema effectively.

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 ('Draw') and resource ('the chart'), and immediately clarifies coordinate format. It distinguishes from position_draw_on_chart by name and explains when to prefer that sibling, so an agent can tell them apart.

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?

Gives explicit when-to-use guidance: 'Prefer position_draw_on_chart for an entry/stop/target box' and instructs to 'call chart_link when you are done'. It also warns against using stale or self-generated coordinates, providing clear boundaries for correct usage.

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 indicate destructiveHint=true deland readOnlyHint=false, but the description goes further by explaining that the deletion 'cannot be undone' and the shape is 'not recoverable,' and that the user is asked first. It also discloses that the tool changes the chart, adding context beyond what annotations alone provide. There is no contradiction with the annotations.

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 two tight sentences that front-load the main action and then deliver irreversibility, user confirmation, and a follow-up step. Every sentence earns its place and there is no fluff.

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 low-complexity tool, the description covers the operation, consequences, user confirmation, and follow-up action. However, the parameters remain entirely undocumented, and with no output schema, the agent has no guidance on what values to pass or what the response will be. This leaves a meaningful gap in the complete call context.

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%, and there are two parameters (id and symbol) with no property descriptions. The description does not mention either parameter or clarify what 'id' or 'symbol' refer to. Since the description fails to compensate for the missing schema information, an agent cannot confidently determine how to populate the parameters.

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: 'Delete a drawing.' It is unambiguous and clearly distinct from sibling tools like drawing_add and drawing_style, while also explaining the consequence of deletion. An agent knows exactly what operation this tool performs.

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 provides clear context: deletion is irreversible, requires user confirmation, and modifies the chart being built. It also instructs the agent to call chart_link afterward so the person can open the chart. It does not explicitly mention alternatives or when not to use the tool, but the follow-up guidance makes the expected usage 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?

The description adds meaningful behavior beyond annotations: it discloses that the operation changes the chart ('Changes the chart you are building') and highlights non-obvious grouping semantics ('single undoable composition'). It also mandates a follow-up action (call chart_link). Annotations already indicate mutability, so the extra context about composition and workflow earns high marks.

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?

Four sentences, roughly 75 words, with no filler. The main purpose is front-loaded, shape semantics follow, mode guidance comes next, and the workflow note closes. Every sentence contributes a distinct piece of actionable information.

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?

Given the tool's 18 parameters and no output schema, the description covers the essential behavioral and workflow aspects: shape construction, mode selection, and the need to call chart_link afterward. It omits potential prerequisites (e.g., needing an existing chart) and some optional display params, but these are less critical for basic invocation, so the definition is nearly complete.

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 only 39%, and the description compensates for key parameters: it explains the mode enum ('highlighter' vs 'brush'), and clarifies the shape/points structure (line takes two endpoints; ellipse/rectangle take opposite corners). This is critical for correct invocation. It does not cover all remaining params, but the most semantically ambiguous ones are addressed.

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 ('Create'), resource ('freehand strokes'), and the unique composition behavior ('as a single undoable composition'). It clearly differentiates the tool by enumerating supported shapes (stroke, line, ellipse, rectangle) and their input conventions, so an agent can distinguish it from drawing_add, drawing_style, and position_draw_on_chart.

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?

Provides clear context within the tool: 'Use highlighter for translucent emphasis and brush for circles, paths and marks' directs mode selection, and 'call chart_link when you are done' gives a follow-up workflow step. However, it does not explicitly name alternative tools or state when not to use this tool, so it stops short of full exclusion 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 readOnly=false, so mutation is known. The description adds state-changing behavior ('Changes the chart you are building') and a workflow expectation (call chart_link), which is useful beyond annotations. No contradictions.

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 tight sentences, front-loaded with purpose, followed by usage context, then workflow. No 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 16-parameter mutation tool with no output schema, the description covers the core workflow (id source, purpose, final link) but leaves many parameter semantics to an incomplete schema. An agent can call it, but incomplete parameter documentation is a 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 coverage is only 56%, and the tool description does not compensate: it only repeats id source ('from chart_state') and advises on colour usage. Several parameters (lineStyle, showStats, arrowStart/End, extendLeft/Right, showLabels) remain undocumented in both schema and description.

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 opens with a clear verb+resource ('Change how an existing drawing looks'), which immediately distinguishes this from drawing_add/drawing_delete/freehand siblings. It also tells the agent where to get the id (chart_state). It doesn't explicitly name sibling alternatives, so not a 5.

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?

Provides concrete context: use distinct colours for measured vs projected levels and call chart_link after changes so the person can open it. It explains when to use it (after drawing exists) but doesn't mention alternatives or when not to use, hence 4.

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=false, so the statement 'Changes the chart you are building' largely restates the mutation behavior rather than adding new safety context. It does add the useful follow-up workflow of calling chart_link, but does not disclose idempotency, replacement of existing studies, or any destructive edge cases.

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 tightly written in four sentences: what it does, supported variants, input guidance, and the necessary follow-up. Every sentence adds distinct information without repetition or padding.

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 19-parameter drawing tool, the description covers the core purpose, variants, required coordinate semantics, and the chart-link workflow well. It does not explain the output or persistence behavior, but there is no output schema and the mutation+hint workflow is largely captured.

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 only 37%, so the description needs to compensate. It adds useful meaning for the key inputs — 'exact candle coordinates' for points and 'optional custom ratios' for levels — and lists the tool variants. However, many parameters (ref, text, symbol, arrows, extents, lineStyle, showStats/showLabels) remain without meaningful semantic explanation in either the description or 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 names a specific verb and resource: 'Draw a Fibonacci study directly on the chart'. It also lists the supported variant families and describes the coordinate/ratio inputs, which clearly distinguishes it from generic drawing tools like drawing_add.

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 concrete guidance: prefer data from market_candles computations over visual guessesitions, and call chart_link after mutating the chart. It does not explicitly explain when to prefer drawing_add or freehand tools instead, but the Fibonacci-specific scope and workflow are clearly stated.

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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so no contradiction exists. Beyond that, the description adds useful evaluation behavior: multi-line expressions with `let` bindings are supported, and the last expression is the result. This is meaningful behavioral context beyond the safety annotations.

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: the first sentence states the core action, and the next two add expression vocabulary and syntax rules without fluff. It earns its length, though it could still have added param guidance without becoming bloated.

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?

Given 9 parameters, nested objects, enums, and no output schema, the description is not complete enough. It does not explain what the evaluation returns, what `reduce` modes mean, how `parameters` maps into the expression, or how `includeForming` affects behavior. For a tool of this complexity, this is a significant 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 only 44%, so the description must compensate, but it only clarifies the `expression` parameter via series names and `let` bindings. Parameters like `reduce`, `includeForming`, `parameters`, `exchange`, and `ref` remain unexplained in both schema and description, leaving a substantial semantic gap.

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 operation: 'Evaluate a Basis formula expression over a loaded window.' It names the expression domain, mentions available series (open, high, low, close, volume, returns), and points to catalog_search for function discovery. However, it does not explicitly differentiate itself from siblings like indicator_compute or market_candles.

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 implies the tool is used when a formula needs to run over an already-loaded window and points to catalog_search for valid expressions, which gives context. It never states when not to use it or names alternatives, so the guidance remains implicit and partial.

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, openWorld, idempotent, and non-destructive behavior. The description adds useful context by explaining the frozen research-screened cohort and the specific computed outputs such as consensus, participation, agreement, effective-wallet count, and concentration. No contradiction with annotations.

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 sentences with no filler. The most important action and scope are front-loaded, the output coverage is compactly enumerated, and the usage caveat earns its place as guidance for responsible use.

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 usefully lists key returned metrics, but does not describe return structure or formatting. This is a minor gap since the tool's purpose, parameters, and safety profile are otherwise well covered.

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 input schema has 100% description coverage for all six parameters, so the schema carries the semantic load. The description adds context about the focus symbol and optional recent fills, but does not need to explain parameters in detail. Baseline 3 is appropriate.

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 specific verb and resource: 'Read current public Hyperliquid positions for a frozen, research-screened whale cohort.' This clearly distinguishes the tool from general market-data siblings like orderflow_read or market_relationships by specifying both the data source and the cohort.

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 explicitly states when to use the tool: 'Use this for whale/smart-money positioning as one evidence family.' It also gives an exclusion: 'never as a standalone signal.' It does not name sibling alternatives, but the usage context and limitation are clear enough for an agent to decide.

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, openWorldHint, idempotentHint, and non-destructive behavior. The description adds meaningful behavioral detail beyond those: it returns EVERY output series, reduces each series, includes conventional indicator levels for interpretation, and excludes the forming bar unless explicitly requested. This gives the agent a clear mental model of the tool's computation and default behavior.

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 tight sentences with no waste. It front-loads the core purpose, then packs return behavior, examples, invocation modes, and a default exclusion into the remaining sentences. Every clause earns its place.

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?

Given a 10-parameter tool with no output schema, the description covers the essential return shape, invocation modes, and a key default behavior. It could more precisely define what 'reduced' means for each reduce mode or note exchange/market defaults, but an agent can select and call the tool correctly with the information provided.

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 70%, so the description is expected to add some meaning. It does: 'symbol' vs 'ref' is clarified as load-and-compute versus reuse-handle, 'reduce' is implied by 'each reduced,' and includeForming is explained via 'forming bar is excluded unless you ask for it.' It does not clarify exchange defaults or the exact reduce modes, but it adds real value beyond the bare 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 opens with 'Run any indicator in the catalogue,' a specific verb and resource, and immediately clarifies the tool's output behavior with concrete examples (Donchian, MACD). It distinguishes itself from chart-focused siblings like chart_add_indicator by emphasizing that it computes and returns reduced output series rather than manipulating a chart.

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 clear usage context: run any catalogue indicator, and provides two invocation routes ('Pass a symbol to load and compute in one call, or a handle to reuse data'). However, it does not explicitly state when not to use this tool or compare it to alternatives such as chart_add_indicator or catalog_search, leaving the selection criteria mostly implied.

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=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds critical behavioral detail: bars are not returned, only a handle and summary, and the tool defaults to the chart's instrument. This goes beyond what annotations provide and helps the agent understand the tool's unique contract.

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 concise sentences with no fluff. The key behavior (handle vs bars) is front-loaded, and the default behavior is stated at the end. Every word earns its place.

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 has 6 parameters (all optional) and no output schema, but the description clearly explains the output (handle + summary) and the next step (pass handle to compute tools). It covers the essential workflow and default behavior. A minor gap is that the summary format is unspecified, but given the read-only nature and the handle pattern, this is sufficient for an agent to use the tool correctly.

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 83% (5 of 6 parameters have descriptions). The description adds a global 'Defaults to whatever is on the chart' statement, which clarifies that market, symbol, and possibly exchange can be omitted and will use chart context. This supplements the schema's per-field defaults (e.g., market and symbol already say 'Default: the chart') and covers exchange, which has no explicit default. The description adds value 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 action: 'Load price history and return a handle to it, plus a summary.' It also clarifies that bars are deliberately not returned, which distinguishes it from tools like indicator_compute or market_derivatives that might return data directly. This is clear and actionable.

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 the intended workflow: pass the handle to compute tools instead of using the bars directly. It also notes the default behavior of using whatever is on the chart, which tells the agent when parameters can be omitted. However, it does not explicitly name alternative tools or state when not to use this tool, leaving a small gap.

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 description adds a valuable behavioral detail beyond the annotations: venues publish different subsets, and missing data comes back as unavailable rather than zero. This goes beyond the generic openWorldHint by explaining exactly how missing values will appear. It does not discuss auth or limits, but the read-only and idempotent annotations already cover that profile.

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 two sentences with no filler. The data categories are front-loaded, and the second sentence provides a necessary caveat about venue-specific availability. Every word earns its place.

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 single-parameter read-only tool, the description names the returned metrics and the key missing-data behavior, which is useful. However, it leaves the 'loaded contract' prerequisite and the meaning of `ref` undefined, so an agent still cannot confidently construct a valid request.

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 sole parameter, `ref`, has 0% schema description coverage, and the description never explains what `ref` should contain or how it relates to a 'loaded contract.' With only one parameter, the description carries the full burden of explaining input semantics and fails to do so.

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 identifies specific data categories (funding, open interest, positioning, taker flow) and scopes them to 'a loaded contract,' which distinguishes this from sibling tools like market_candles or orderflow_read. It lacks an explicit verb such as 'fetch' or 'return,' and 'loaded contract' is not defined, but the core purpose is clear.

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 no explicit guidance on when to use this tool versus alternatives like orderflow_read or market_relationships. It also does not explain what 'loaded contract' means or what state must exist before calling. The use case is only implied by the listed metrics.

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 and idempotent, so safety is covered. Description adds that data comes from a server-cached aggregate source with source and timestamps, and emphasizes it's a current snapshot, which informs the agent about data freshness and potential lag. No contradictions.

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 sentences with no filler. Front-loads the core data content, then adds usage guidance. Every sentence earns its place.

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 no-parameter snapshot tool, the description covers what data is returned (market cap structure, dominance, stablecoin share), notes source/timestamps, and clarifies non-historical nature. Without an output schema, it provides enough context for an agent to understand the result, though it could be more specific about exact output format. Still complete for typical use.

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?

No parameters exist, so schema coverage is complete. The description doesn't need to explain parameters; baseline 4 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?

States a specific purpose: reports current crypto market-cap structure including BTC/ETH dominance, total cap/volume, stablecoin share, and leading asset shares. Clearly distinguishes from historical backtest series, and mentions it's a current snapshot. This differentiates it from backtest_run and other historical 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?

Explicitly advises using this tool for BTC.D/rotation context, giving a clear when-to-use. Also clarifies it's not a historical series, implying not for backtesting. Does not name specific sibling tools but provides sufficient 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 cover the read-only, non-destructive, idempotent safety profile Mendable. The description adds substantial behavioral context beyond that: it specifies the input data basis (timestamp-aligned closed-bar log returns), the full set of computations, and a deliberate omission. This helps the agent understand what the call will and will not produce.

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 dense but not bloated; every listed output is relevant to an agent deciding whether to invoke the tool. However, the opening sentence is very long and front-loads a large enumeration of results before the 'Use this for' guidance appears. Slightly restructuring into two sentences would improve scannability, so it falls just short of 5.

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 compensates by enumerating the returned diagnostics in detail. It also gives the data basis and a key exclusion; combined with schema defaults and enums, an agent has enough context to call the tool correctly. It stops short of describing the structure of the correlation matrix or rolling series, but those are relatively inferable analytical concepts.

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 71%, so the schema already documents bars, symbols, benchmark, timeframe, and rollingWindow, while market and exchange are self-documenting enums. The description does not explain parameters individually, but it does clarify the analytical intent that connects them. Baseline 3 is appropriate because the structured schema carries most of the parameter semantics.

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 opens with a specific verb and resource: 'Professional multi-asset relationship analysis on timestamp-aligned closed-bar log returns.' It enumerates concrete outputs such as correlation matrix, OLS beta/alpha, and rolling spread z-score, which clearly separates it from siblings like market_candles and market_dominance. The tool's analytical identity is unmistakable.

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 states explicit use cases: 'Use this for BTC correlation, beta, pairs and relative-strength work.' It also gives an explicit exclusion: 'price-level correlation is deliberately not reported,' which tells the agent when not to rely on this tool. This is actionable routing guidance even though no specific sibling tool is named.

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, so the safety profile is covered. The description adds valuable behavioral detail beyond annotations: matching is word-bounded, with concrete examples showing that 'button' does not match TON and 'operation' does not match OP.

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 sentences with no filler. The core purpose is stated first, and the word-boundary caveat is delivered with concrete examples. Every sentence earns its place.

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, idempotent tool with one parameter and no output schema, the description is nearly complete: it states the input, the task, and a key matching behavior. It could be more explicit about the output format, but the phrase 'which crypto assets... refers to' adequately implies a list of detected assets.

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 schema has one parameter, 'text', with 0% description coverage, so the description bears the burden. It clarifies that the input is a piece of text and gives word-boundary examples that help an agent understand what kind of string to pass. It does not specify length limits or case sensitivity, but for a single simple parameter this is adequate.

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: identifying which crypto assets a piece of text refers to. It is specific about the resource (crypto assets) and input (text), though it lacks an explicit verb and does not distinguish itself from sibling 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?

There is no guidance on when to use this tool versus alternatives like news_recent or catalog_search. The intended use is implied by the description, but no exclusions, prerequisites, or alternative tool references are provided.

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 cover read-only, idempotent, open-world, and non-destructive behavior. The description adds a meaningful caveat: 'Impact is a keyword heuristic, not a judgement about the market.' This clarifies that the impact score is not a predictive market signal, which is valuable for correct interpretation of results. This goes beyond the annotations and enhances transparency.

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 two sentences with zero redundancy. The first sentence states the core purpose and output, and the second provides an important caveat. It is front-loaded and every word contributes value.

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 read-only tool with no required parameters and no output schema, the description covers the main return values (headlines, impact score, assets) and adds the heuristic caveat. It does not specify the format or timeframe of 'recent,' but given the simplicity of the tool and the annotations covering safety, this is adequate. A minor gap is not explaining how the impact score relates to the minImpact filter, but that is implicit in the schema.

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 67% (asset and limit have descriptions; minImpact only has an enum). The description does not elaborate on any parameters, but the schema already documents them sufficiently. Since coverage is high, the baseline is 3, and the description adds no extra parameter context, so a 3 is appropriate.

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 what the tool does: retrieve recent crypto headlines, each with an impact score and the assets they touch. The verb 'Recent' and the specific output details (impact score, assets) distinguish it from siblings like news_detect_assets, which likely focuses on asset detection rather than providing a curated headline list with impact scores.

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?

No explicit guidance on when to use this tool versus alternatives. The description does not mention any sibling tools or conditions for selection, such as 'for asset-specific analysis use news_detect_assets.' The only implicit usage is that it provides recent headlines, but there is no contrast or exclusionary language.

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 mark it read-only, open-world, idempotent, and non-destructive. The description adds crucial behavioral nuance beyond those flags: that data is 'measured from the venue aggressor tag, not inferred from bar direction,' and that the tool 'reports coveredMinutes, not the minutes asked for.' Both details meaningfully affect how an agent interprets results and cannot be gleaned from the schema or annotations.

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 dense but every clause earns its place: it opens with the output content, states the methodological basis, provides a concrete when-to-use signal, explains the two calling modes, and closes with a key output caveat. It is front-loaded with the most decision-relevant information and contains no 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 tool with 10 parameters, no output schema, and subtle temporal behavior, the description covers all essential context: what is returned, how it is measured, how to request single vs. multi-candle windows, and a behavioral quirk (coveredMinutes). An agent can invoke the tool correctly and interpret its results without further discovery.

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 90% and already explains most parameters, including the role of candleTime and bucketSize. The description adds a useful clarification by tying candleTime and minutes into a single mental model (exact bar vs. trailing window) and explicitly warns about the coveredMinutes mismatch. This goes beyond the schema's per-field documentation, though most parameter semantics remain in 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 opens with a precise inventory of what the tool computes ('buy and sell volume separated by who crossed the spread, delta, the footprint by price level, the point of control, and absorption or stacked imbalance') and explicitly contrasts it with candles ('use it when the question is who is being aggressive, which candles cannot answer'). This distinguishes it from the many chart/candle siblings and gives an agent an unambiguous picture of the tool's unique role.

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 states exactly when to reach for this tool ('use it when the question is who is being aggressive'), and it differentiates from alternative candle-based analysis. It also provides explicit invocation guidance for the two modes ('for one candle pass candleTime... otherwise it reads the last minutes') and warns about the coveredMinutes discrepancy. This is actionable, not generic.

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=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds value by listing the full set of computed outputs and noting that warnings are produced, which goes beyond the structured annotations. It does not describe internal calculation details or edge cases, but for a pure calculation tool this is adequate.

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 two sentences with zero waste. The first sentence front-loads the tool's purpose and output list, and the second provides a routing directive. Every word earns its place, making it easy to scan and act on.

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 complex calculation tool with 12 parameters and many outputs, the description lists the outputs explicitly, which is the primary missing piece an agent would need. It does not explain how parameters interplay or what 'risk-first' means, but the schema covers most parameter semantics, and annotations cover side effects. No output schema exists, so the description's output list partially compensates. Overall adequate, though it could mention required inputs or units.

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 75%, meaning most parameters (9 of 12) already have descriptive text. The description itself does not add parameter-specific semantics; it only lists outputs. For the 25% without schema descriptions (side, stop, entry), the description offers no clarification, but these are fairly self-explanatory (side has an enum, stop/entry are numeric prices). Given high schema coverage, a baseline of 3 is appropriate.

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 computes risk-first position sizing and enumerates the specific outputs (quantity, notional, margin, effective leverage, fees, funding, breakeven, liquidation estimate, target R multiples, warnings). It also distinguishes itself from the sibling position_plan_on_chart by naming the alternative, so an agent can tell them apart without inspecting schemas.

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 explicit exclusion: 'Use position_plan_on_chart instead when the user should see the plan on the chart.' This provides a concrete when-not condition and names the alternative. However, it does not enumerate other potential alternatives (e.g., position_draw_on_chart) or state explicit conditions for when to choose this tool over others, leaving some context implicit.

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 are all false, so the description carries the full burden of behavioral disclosure. It clearly states that it needs no account equity or risk percentage, performs no position sizing, places no order, and changes the chart being built. It also instructs to call chart_link afterward, which is a required side-effect. No contradictions with annotations.

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 sentences with no wasted words. It front-loads the purpose, then lists exclusions, names the alternative, and ends with the required follow-up action. Every sentence contributes directly to tool selection and correct invocation.

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 drawing tool with 9 parameters and no annotations, the description covers the core behavior, exclusions, and a required follow-up. It does not explain every parameter, but the optional ones are documented in the schema, and the main required fields are clear from context. The description is adequate for an agent to call the tool correctly without further research.

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 only 33% (only toTime, barsWide, and fromTime have descriptions). The description covers the core parameters entry, stop, and target implicitly, and side is implied by 'long/short,' but it does not explain symbol, timeframe, or the optional time/barsWide parameters. It adds meaning for the primary required fields but leaves the rest to schema or inference, which is insufficient given the low coverage.

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 ('Draw'), a clear resource (an entry, stop, and target box on a chart), and explicitly differentiates itself from position_plan_on_chart by noting it performs no quantity or risk calculations. This allows an agent to instantly distinguish it from the closest sibling tool.

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 explicitly names the alternative (position_plan_on_chart) and the condition that selects it: 'only when the user also wants quantity and risk calculations.' It also implies when to use this tool ('immediately when those price levels are known'), leaving no ambiguity about the appropriate context.

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 description discloses a side effect ('Changes the chart you are building') and a required follow-up action ('call chart_link'). Annotations only state readOnlyHint=false and destructiveHint=false, which do not capture the chart modification. The description also mentions persistence ('so later analysis reads the same plan the user sees'), adding behavioral context beyond annotations. No contradiction with annotations.

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 sentences with no waste. The primary action and target are front-loaded, followed by essential behavioral notes (persistence and follow-up). Every clause earns its place.

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 tool with 19 parameters and a side effect, the description covers the critical workflow (calculate, draw, then link), the persistence of the plan, and the chart-modifying nature. There is no output schema, but the description clarifies the outcome. The required parameters are covered by the schema, and the description adds the missing behavioral context. Complete for an agent to use it correctly.

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 68%, so the schema documents most parameters. The description mentions 'optional sandbox program id' and 'targets' implicitly but does not add meaning beyond what the schema already provides. With high coverage, baseline 3 is appropriate; the description does not compensate for the undocumented parameters but doesn't need to.

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 action ('Calculate a risk-first long/short position and draw the entry, stop and first target directly on the live chart') with a clear resource (the chart) and distinguishes itself from siblings like position_calculate and position_draw_on_chart by combining calculation and drawing. It is explicit and non-tautological.

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 provides clear usage context: it modifies the chart and instructs to 'call chart_link when you are done so the person can open it.' This is a sequencing guideline. However, it does not explicitly mention alternatives or when not to use this tool, though the combined calculate+draw purpose implies a distinction from calculation-only or drawing-only tools.

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?

Beyond the readOnlyHint and idempotentHint annotations, the description discloses concrete behavior: equal-weight long/short portfolios, next-bar-open entry and following-bar-open exit, re-screening each bar, and turnover-based cost calculation so unchanged holdings are not double-charged. This is rich, non-obvious behavioral detail.

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 sentences with no filler: the mechanism is front-loaded, the usage condition follows, and the cost nuance earns its place. Every sentence contributes distinct value.

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 complex 12-parameter backtest tool, the description plus a well-covered schema and strong annotations gives an agent everything needed to select and invoke it correctly. The absence of an output schema is acceptable because the description focuses on behavior needed before calling, and the schema documents the parameters.

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 high (83%), so the baseline is 3, but the description adds meaningful parameter-level context: 'equal-weight' clarifies maxPositions behavior, 'long or short' ties to direction, and the turnover-cost sentence clarifies how feeBps actually applies. It doesn't document each parameter, but it adds interaction semantics the schema lacks.

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 opens with a specific verb and resource: 'Historically replay a cross-sectional screen at every bar,' then details the portfolio construction, entry/exit timing, and re-screening process. It explicitly distinguishes itself from a single-symbol backtest, so an agent can tell it apart from siblings like backtest_run.

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 gives an explicit use case: 'Use this when the question is whether repeatedly trading screener matches worked.' It also states what is not a substitute — a single-symbol backtest of coins that match today — providing clear when-not 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?

The description adds useful behavior beyond the annotations: it fetches history for every instrument in the universe Choose a JSON code block with all scores and justifications. and is therefore slow;; this is meaningful operational context. The annotations already cover read-only, idempotent, and non-destructive behavior, so the description's performance disclosure is a valuable supplement. No contradiction with annotations.

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 sentences long and every sentence earns its place: purpose, use case, and performance guidance. It is front-loaded with the primary action and includes the most important operational caveat without wasting words.

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 description covers the purpose, use case, and major performance characteristic, andthe schema fills in most parameter details. However, there is no output schema, and the description does not state what the tool returns (e.g., matching symbols, values, or matched rule details). This leaves some context missing for an agent that needs to handle the result.

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 schema already covers 78% of parameters, including enums and defaultsconstant. The description adds conceptual context for how rules work (price fields, indicators, formulas, ALL/ANY matching), which helps an agent understand the rule structure. However, it does not go much beyond the schema's own parameter descriptions.

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 operation: scan the venue's listed instruments for ones matching conditions, explicitly contrasting with looking at the open chart. It also gives a memorable use case ('which coins are doing X right now'). It does not name sibling tools like screener_backtest, but the resource and action are clear enough to distinguish from chart-oriented 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?

The description clearly identifies when to use this tool: when scanning for instruments matching conditions across the universe. It also warns that the operation is slow and recommends asking once with the right conditions rather than repeatedly. It does not explicitly mention when not to use it or alternatives, but the guidance is practical and context-rich.

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?

Beyond annotations (readOnlyHint, idempotentHint), the description discloses the full experimental design: selection-window ranking, subperiod checks, embargo, held-out performance reveal, doubled costs as a stress test, buy-and-hold comparison, and deflated Sharpe correction for multiple trials. This is rich behavioral context that annotations alone do not provide.

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?

Front-loaded with purpose and usage guidance, then detailed methodology. The third sentence is a dense list but each item earns its place; minor redundancy exists with the schema's symbols description that already mentions deflated Sharpe accounting. Efficient overall for a complex tool.

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 14-parameter research tool with no output schema, the description thoroughly explains methodology and purpose but leaves the output format implicit. An agent can infer that results include rankings and held-out performance, but explicit return-value documentation would make it complete.

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 86%, so the schema carries most parameter semantics. The description adds cross-parameter context (every strategy/symbol/timeframe combination is a trial, corrected by deflated Sharpe) but does not substantially elaborate individual parameter meanings beyond the schema. Baseline 3 is appropriate.

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+resource: runs one chronological research experiment across many built-in strategies, instruments, and timeframes. It explicitly distinguishes itself from backtest_run by naming the anti-pattern of testing one strategy on coin after coin, making sibling differentiation clear.

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?

Explicitly directs use to broad discovery and says to use it instead of many backtest_run calls, even naming the exact anti-pattern it replaces. The description gives a clear when-to-use instruction and identifies the alternative tool, matching the top-tier calibration.

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?

Beyond the readOnly/openWorld/idempotent annotations, the description discloses material behavior: plans are deterministic synthetic templates, and fills, stop/target ordering, MAE/MFE, and outcomes are settled on later historical candles with costs. It also warns that analogues are not proof of an edge. This adds genuine context rather than restating annotations.

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 sentences with no filler: primary action, behavioral mechanics, and usage caveat. The main verb and resource are front-loaded, and every sentence earns its place.

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 13-parameter tool with no output schema, the description captures the purpose, output concepts (fills, MAE/MFE, outcomes), and important caveats, while annotations cover safety and idempotency. It does not explicitly state that all parameters are optional or how defaults tie to the current chart state, but the schema and parameter defaults fill most of that gap. Strong but not exhaustive.

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 69%, and many parameters are already described well (bars, limit, feeBps, symbols, timeframe). The description adds conceptual framing around "current market state" and "costs" that helps make sense of ref, symbol, timeframe, feeBps, and slippageBps. However, it does not compensate for the undescribed enum parameters like side, setup, market, and exchange, so the added parameter-level value is only moderate.

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 opens with a specific verb and resource: "Retrieve compact historical trade analogues for the current market state." It further clarifies the mechanism with "deterministic synthetic templates" and later-candle settlement, which clearly separates it from sibling tools like backtest_run or screener_backtest. This is a precise, non-tautological purpose statement.

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?

"Use it to compare similar wins and failures, never as proof of an edge" provides a clear use case and a when-not caution. It does not name alternative sibling tools or specify when to prefer backtest_run or strategy_research, so it falls short of a 5. Still, the guidance is explicit enough to shape correct usage.

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