Basis

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

Adds substantial context beyond the annotations: nothing is armed until the link is opened and confirmed, market alerts can run in an open tab while background/event alerts need a signed-in Basis account, and the link expires after seven days. It does not reconcile this with destructiveHint=true, leaving a mild gap about server-side state created at prepare time.

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?

Five front-loaded sentences: purpose, usage, the exclusivity rule, the delivery instruction, then behavioral caveats. Dense but every sentence carries information an agent needs for this 14-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?

Despite 14 parameters, nested objects and no output schema, the description covers selection logic, the returned link and expected one-line summary, the confirmation gate, and account/expiry constraints. Nothing essential for correct invocation 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 description coverage is already 86%, so the baseline is 3. The description adds a genuinely useful cross-parameter constraint absent from the schema: pass exactly one of price, conditions, drawingId or eventTrigger, plus notes on frequency defaults and Founder-only custom timeframes.

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 concrete verb and resource: prepare an alert (price, indicator, drawing, news, calendar, whale-group) and return a one-click link. The enumerated alert families let an agent tell it apart from siblings like drawing_add (which supplies drawingId) or news_recent (which merely reads news).

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 with concrete trigger examples (level breaks, RSI crosses 70, high-impact ETF headline) and states the exactly-one-of price/conditions/drawingId/eventTrigger routing rule. It does not, however, say when NOT to use it or name a sibling to prefer for adjacent needs.

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 only declare flags (readOnlyHint=false, destructiveHint=true, openWorldHint=true, idempotentHint=false); the description adds genuinely useful context the annotations cannot: the return is a private review link rather than a public one, chart annotations are included, and the agent has no publish authority. It doesn't explain what state the destructive-hinted write actually creates or affects, so not a 5.

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?

Five short sentences, front-loaded with the action and its private nature, then the usage gate, then the constraints. Every sentence carries load-bearing information about scope, workflow, or safety; 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?

No output schema exists, so the description correctly carries the return-value burden ('Returns a private review link, NOT a public link'). Combined with the human-approval workflow and privacy constraints, an agent has enough to call it correctly, though the enum/optional parameters (market, exchange, timeframe, symbol) get no mention.

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 78%, so most of the 9 parameters are already documented in the schema (body, title, caption, levels, indicators all have descriptions). The description adds only thematic constraint ('Do not include private account information') rather than field-level semantics, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and composite resource: 'Prepare a PRIVATE sharing package of the current chart image, editable analysis and social caption.' This clearly distinguishes it from siblings like chart_image, chart_link, or alert_link, which produce images or links without the review/publish workflow.

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 scopes usage with 'Only use when asked for something shareable,' and describes the follow-on flow (the person must open, edit/review, and publish) plus the exclusion 'you cannot publish or post on their behalf.' It doesn't name a specific sibling alternative for the non-sharing case, so it stops short of a 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?

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 declare a safe, idempotent, closed-world read, so the bar is lower. The description adds real content-level behavior: the data provenance (published Fed/BLS calendars vs reconstructed conventions) and the coverage start date, which the annotations cannot convey.

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?

Dense and front-loaded: scope, then contents, then exclusions, then the sibling pointer. Every clause carries information, though the telegraphic 'Dates only: NOT...' style and the trailing routing sentence make it slightly less scannable than it could be.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description correctly discloses the return shape ('dates only, not actual/forecast/previous values') and the temporal coverage boundary. Minor gap: no pagination or result-size behavior for wide date ranges.

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 both from/to parameters are documented in the schema with date/timestamp format and UTC convention. The description adds nothing about parameter syntax or defaults, so 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 resource (past calendar dates) with enumerated contents (FOMC rate decisions, US CPI, non-farm payrolls, options expiry, CME settlement) and an explicit coverage window (February 2025 on). An agent can distinguish this from calendar_upcoming and news_history without opening any 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?

Names the sibling alternative and the condition selecting it: 'Use calendar_upcoming for future events.' It also states exclusions (no actual/forecast/previous values, no historical funding or halving feed), which prevents mis-selection for value or funding queries.

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 safety profile (readOnly, idempotent, openWorld, non-destructive), so the bar is lower. The description adds genuinely useful context the annotations cannot: every row carries provenance (live, official schedule, published rule, estimate, user) and the rationale that a block-height-projected halving is less certain than a convention-fixed expiry. It stops short of describing pagination or row shape.

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-loaded with the resource and its contents, then the provenance rule, then the usage directive. The mid-sentence event catalogue is dense but every item earns its place by defining scope; the provenance sentence is somewhat long but carries the tool's main behavioral insight.

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?

There is no output schema, so the description must partially carry return semantics — and it does explain that each row states its date source, plus the confidence framing. It still omits row fields (event name, date, impact label) and pagination behavior, but for a read-only calendar listing with fully documented params this is close to 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 100%, so the schema already documents days, limit, impact and symbol including defaults and caps. The description only loosely reinforces this by mentioning 'the next funding settlements for a contract' (tying to symbol) and by implying a forward horizon (days); it adds no syntax or format detail beyond the schema. Baseline 3 is correct.

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?

Names a specific forward-looking resource (scheduled events) and enumerates the concrete event classes covered — FOMC, CPI, NFP, funding settlements, halving, difficulty retargets, options expiry, CME settlement. The closing line 'nothing else here looks forward' implicitly separates it from the calendar_history sibling without needing to open either 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?

Gives an explicit usage trigger: 'Use it before saying anything about what happens next', which tells the agent exactly when this tool is the right choice. It does not name calendar_history as the retrospective alternative nor state any exclusions, so it falls short of a 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 contributes the workflow constraint (use before unseen parameters) and hints at the payload's shape, but says nothing about lookup misses, whether a missing id errors or returns empty, or whether kind is needed to disambiguate.

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 what and closed with the when. The enumeration of entity types is dense but every item adds discrimination value; nothing is 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 only two parameters, no output schema and full annotation coverage, the description does enough: it tells the agent what fields come back for each entity type and when to call. The one substantive gap is the id/kind relationship, which the description leaves implicit.

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 50%: `kind` is documented in the schema, but `id` carries no description. The description partially compensates by naming the four kinds that populate `kind`, yet it never explains whether `id` is globally unique or scoped per kind, which is the key ambiguity for a lookup taking both.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Full detail for one catalogue entry') and then enumerates exactly what that detail covers across the four entity types (indicator params/defaults, formula signature, strategy params, drawing anchors/text/style). An agent can distinguish this from the sibling catalog_search without opening either 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?

'Call this before passing parameters you have not seen' is a concrete trigger condition that tells the agent when this tool is mandatory rather than optional. It doesn't explicitly name catalog_search as the discovery-side alternative, so the routing story is implied rather than stated.

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

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

The annotations already establish read-only, idempotent, non-destructive, closed-world behavior. The description adds useful operational context beyond that: guessed drawing-tool ids are refused, exact counts live in the system prompt catalogue, and reusing verified types is preferred. It does not describe return shape or pagination, which keeps it below a 5.

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 purpose is front-loaded and the sentences mostly earn their place by covering scope, exclusions, usage, and edge cases. It is slightly dense and run-on in the opening list, but not verbose for a tool with this much routing and safety guidance.

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 three optional parameters, rich annotations, and no output schema, the description covers scope, alternatives, safe usage, and empty-query behavior well. It could be more explicit about the shape of returned catalogue entries, but it gives enough context for an agent to invoke 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 description coverage is 100%, so all three parameters are already documented. The description adds some meaning with 'An empty query lists a kind; no kind searches them all,' but does not add detail about limit behavior or query matching beyond the schema. This is the expected baseline when the schema carries 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 uses a specific verb and resource: it searches the Basis catalogue for indicators, formula functions, strategies, strategy-expression series, and drawing tools. It explicitly distinguishes this from callable agent functions and points to tools_load for function groups, so an agent can differentiate it from siblings without reading 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?

It gives explicit when-to-use guidance: before assuming something exists, always before drawing a new type, and reuse a verified type instead of re-searching. It also names tools_load as the alternative for callable function groups and explains the empty-query/no-kind behavior, leaving little to inference.

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 only declare the generic safety profile (not read-only, not destructive, not idempotent). The description adds real behavior: studyId accepts common names, omitted params fall back to defaults, and the call mutates the chart being built. It stops short of noting duplicate/repeat-add behavior, which matters given idempotentHint=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?

Compact and front-loaded: the action leads, then parameter syntax, then the completion path. Every clause carries information, though the final sentence packs two alternative next steps and is slightly denser than needed.

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?

No output schema exists, but the tool returns little the agent needs to see described; the description covers the mutation, parameter sourcing, and next-step tools. The one gap is what happens on repeated adds, which is relevant given idempotentHint=false.

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% and the nested params object is undocumented, but the description compensates well: studyId takes an id or a common name with concrete examples ('ema20', 'bollinger'), catalog_describe enumerates valid parameters, and missing params use defaults. The internal shape of the params object is still only discoverable elsewhere.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Put an indicator on the chart') and frames it as a mutation of the chart being built. Combined with the sibling names (chart_toggle_indicator, chart_update_indicator, chart_remove_indicator), an agent can tell this is the additive variant without opening any 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?

Gives clear workflow routing: call catalog_describe to discover parameters, then finish with chart_link, or analysis_prepare when a sharing draft needing human review is wanted. It does not explicitly contrast with chart_toggle_indicator/chart_update_indicator, so the when-not case is left to inference.

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?

Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false, so the mutation profile is covered. The description adds value the annotations cannot: this mutates a chart 'you are building' and feeds a downstream publishing workflow. It does not resolve the tension between the word 'Delete' and destructiveHint=false (permanence, reversibility, or whether the underlying indicator definition survives), which is the one behavioral gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences, front-loaded with the action, then the prerequisite, the alternative, and the follow-up. No sentence is filler; the exclusion is placed immediately after the action it disambiguates.

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 chart-mutation tool with no output schema, the description covers purpose, prerequisite, alternative, and downstream workflow. It leaves only edge-case behavior (invalid instanceId, whether the removal is reversible, whether chart_state must be re-read afterward) unstated.

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?

One required parameter with 0% schema description coverage, so the description must compensate. 'Use chart_state to find its instance id' tells the agent exactly how to obtain a valid instanceId, which the schema does not; it stops short of documenting the id's format or behavior on an invalid id.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Delete an indicator instance from the chart.' It explicitly distinguishes itself from the two nearest siblings, chart_toggle_indicator (hide) and by implication chart_add_indicator, so an agent can pick it without opening any 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?

Gives the lookup prerequisite ('Use chart_state to find its instance id'), names the alternative for the near-miss case ('To temporarily hide it instead, use chart_toggle_indicator'), and states the follow-up flow (chart_link, or analysis_prepare for a draft needing review). When-to-use, when-not-to-use, and alternatives are all present.

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 already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=false, so the mutation/safety profile is covered. The description adds only that it edits 'the chart you are building' and the follow-up workflow, but discloses nothing about failure on invalid input, persistence, or state effects. With annotations carrying the safety burden, a 3 is appropriate.

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 action, no filler. The second sentence is slightly dense with two downstream tool options packed into one clause, but overall it is tight and 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 setter with no output schema and full annotation coverage, the description supplies purpose, value format, and post-step workflow. Remaining gaps (invalid-value handling, interaction with other chart state) are minor for a tool of this complexity.

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% (the 'timeframe' string is undocumented), so the description must compensate, and it does with format examples (15m, 1h, 4h, 1d). It doesn't enumerate the full accepted set or note case/edge behavior, but it materially teaches the expected value shape 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?

States a specific verb (Change) and resource (chart timeframe) and immediately gives concrete format examples (15m, 1h, 4h, 1d). The 'timeframe' resource is unique among the chart_* siblings (set_instrument, set_type), so an agent can distinguish it without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives real workflow guidance: 'Changes the chart you are building; finish with chart_link, or analysis_prepare for a sharing draft.' This names downstream alternatives and the condition for each (sharing draft needing human review). It lacks any explicit when-not-to-use or prerequisite, so it falls short of a 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 non-readOnly, non-destructive, non-idempotent behavior. The description adds real value beyond them: invalid ids are refused and the refusal enumerates all valid ones, giving the agent a recovery path, plus the downstream workflow. It does not clarify mutation semantics beyond that, but the annotation bar is already met.

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 what the tool does, then error behavior, then workflow. No filler, though the final sentence packs two follow-on paths that could be slightly clearer.

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 annotations and no output schema, this covers purpose, failure behavior, and follow-up adequately. The one gap is the incomplete enumeration of valid chartType values, though the described refusal partially mitigates it.

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?

One parameter at 0% schema coverage, so the description must compensate. It names several valid chartType values but hedges with 'and others' and never enumerates the full set, leaving the agent dependent on trial-and-error (the described refusal) to discover valid ids.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource — changing how price is drawn — and enumerates representative values (candles, heikin ashi, line, renko, footprint). This is clearly distinguishable from sibling chart setters like chart_set_instrument and chart_set_timeframe, which affect different chart properties.

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 concrete workflow context: finish with chart_link, or analysis_prepare when a sharing draft needs human review. It routes the agent to the correct follow-on siblings, though it never states when NOT to use this tool or what it competes with directly.

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?

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, and the description usefully confirms this is a mutation of "the chart you are building" plus that the indicator is preserved. However, it does not disclose how the toggle's target state is determined (the agent must infer a blind flip), which is the key behavioral question for a non-idempotent toggle.

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 short sentences with no filler; the purpose is front-loaded ahead of the workflow guidance. The clause about chart_link/analysis_prepare is slightly dense but earns its place by routing the next action.

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 mutation tool with no output schema, the description covers purpose and next steps, but leaves two things an agent needs: the meaning of instanceId and how the hide/show state is selected. These gaps are narrow but real.

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% for the single required parameter, and the description says nothing about instanceId — whether it identifies the chart instance or the indicator instance is left entirely undefined. With only one parameter the impact is bounded, but the description does not compensate for the schema gap as it should.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a concrete verb pair and resource ("Hide or show an indicator") and immediately distinguishes the operation from removal with "without removing it", which separates it from chart_remove_indicator. It stops short of naming siblings explicitly (chart_remove_indicator, chart_update_indicator), so it is clear but not maximally differentiating.

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 states a use case ("useful for comparing a chart with and without something") and gives explicit follow-on workflow guidance: finish with chart_link, or analysis_prepare for a sharing draft needing human review. What's missing is guidance on the hide-vs-show decision itself, so the agent isn't told when it should hide versus show.

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 and destructiveHint=false, so the write-but-not-destructive profile is covered. The description adds genuine workflow context that annotations cannot: changes affect the chart being built, and the session should finish with chart_link or analysis_prepare for a human-reviewed draft. It does not disclose whether edits are reversible or overwrite existing params, which keeps it from a 5.

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 front-loaded sentences, each carrying a distinct instruction: purpose, prerequisites, alternatives, and follow-up. No repetition and nothing wasteful.

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?

No output schema exists, and the description covers the full call lifecycle for a low-complexity mutation: how to obtain inputs, the sibling boundary, and the recommended completion step. Nothing required 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 0% and params is an unexplained nested object, so the description must compensate. It does so well by routing to chart_state for the instanceId and catalog_describe for supported parameter shapes, giving an agent a path to the missing semantics even though no inline format is stated.

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 ('Edit the parameters of an existing indicator instance') and immediately distinguishes itself from siblings chart_remove_indicator and chart_toggle_indicator by naming what each does instead. An agent can pick the right tool without opening any 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?

Gives explicit prerequisites (call chart_state for the instance id, catalog_describe for supported parameters) and names the alternatives for delete and show/hide cases with the condition that selects them. This is a textbook when/when-not routing paragraph.

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 readOnly, idempotent, openWorld, non-destructive, so safety is covered. The description adds meaningful behavior beyond that: rule-independent breadth is returned regardless of rules, 24h liquidity semantics are included, and 'Near misses never satisfy all rules' discloses strict AND matching that would otherwise surprise an agent reading a ranked list.

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 tight sentences with the purpose and output shape front-loaded, then routing, then defaults, then a caveat. Nothing is padded, though the quoted '"scalp"' rendering is slightly awkward and the final caveat sentence could be folded into the routing sentence.

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 12-parameter, rule-building scan with no output schema, the description covers purpose, output categories, default behavior, and the strict-match caveat. It stops short of characterizing the ranked-candidate fields or how breadth/liquidity are reported, which leaves some ambiguity about what a caller actually receives.

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 67%, and the description fills the most consequential gaps: style defaults (scalp=5m, daytrade=15m) and the instruction to omit longRules/shortRules to fall back to transparent RSI/EMA defaults. It says nothing about limitPerSide, universeSize, manualSymbols, quote, or the rule-object syntax, which remain schema-only.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Run one symmetric long/short scan over the same top-volume universe') plus the outputs (breadth, 24h liquidity semantics, ranked directional candidates). It explicitly separates itself from screener_run and from the derivatives/order-flow deep-dive tools, so an agent can route without opening 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?

Gives explicit sequencing ('Use this first... then deep-dive only the shortlist'), an alternative with its selecting condition ('For explicit user filters use screener_run instead'), and a default path for a general scalp request (style:"scalp" with longRules/shortRules omitted). When-to-use, when-to-use-something-else, and the default invocation are all covered.

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 it is a non-destructive, non-read-only mutation; the description adds genuinely new behavior: the result echoes the drawing back for verification, anchors are validated against a ref window, and coordinates must be copied from tool results rather than prose. It does not mention that repeated identical calls are not idempotent (annotations flag idempotentHint=false), which is a minor omission.

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?

Well front-loaded: what it draws, then coordinate format, then point-count rules, then provenance discipline, then next steps. Five dense sentences where every rule earns its place, though the provenance/verification material could be tightened without losing meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 27-parameter, no-output-schema drawing tool, the description covers the semantics an agent must get right: coordinate source, point cardinality, layout vs measured anchors, and verification of the echoed result. Residual gaps are stylistic parameters rather than correctness-critical ones.

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 44% across 27 parameters, so the description has to compensate and largely does for the critical ones: points format ({time, price}, seconds matching candle timestamps), anchor provenance rules, and which anchors count as layout versus measured. Many cosmetic toggles (arrowStart, showStats, extendLeft, labelVertical, etc.) remain undocumented in both description and schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource set: 'Draw measured geometry or explain it with text, note, callout or emoji', which lets an agent separate annotation work from siblings like drawing_freehand, fibonacci_draw or position_draw_on_chart. The measured-vs-decorative split is explicit in the first sentence.

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 concrete when-to-use rules: one point for a horizontal line, two for a trendline or box, and an explicit follow-up chain ('finish with chart_link, or analysis_prepare for a sharing draft'). Sibling routing (prefer position_draw_on_chart for entry/stop/target) lives only in the schema text, so the description itself stops just short of full alternative coverage.

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 flag destructiveHint=true and idempotentHint=false, so irreversibility is partly covered; the description adds the non-obvious behavioral detail that the user is prompted before deletion and that the shape is unrecoverable. That confirmation flow is information the annotations do not convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the verb, and no filler. Slight redundancy between 'cannot be undone' and 'not recoverable' costs a point.

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?

No output schema exists and none is needed for a delete; the description covers irreversibility, the confirmation requirement and workflow continuation, which is strong for a simple 2-parameter mutation. It falls short only on parameter meaning and a success/failure signal.

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 the description adds nothing about either parameter. It does not explain that 'id' identifies the drawing or what the optional 'symbol' scopes, so the zero-coverage schema is left uncompensated.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Delete a drawing') that is unmistakably distinct from siblings like drawing_add, drawing_freehand and drawing_style. The opening sentence alone tells an agent exactly 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?

Gives clear operational context: deletion requires the user to be asked first, and names follow-up routes (chart_link for a finished chart, analysis_prepare for a shared draft). It does not spell out when *not* to use it versus e.g. drawing_style, but the workflow guidance is actionable.

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 establish that this is a non-read-only, non-destructive, non-idempotent operation. The description adds useful behavioral context by noting that strokes form a 'single undoable composition' and that changes affect the chart being built, though it does not discuss validation or error 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 compact and front-loaded: purpose first, then shape semantics, mode guidance, and workflow. Every sentence contributes practical information without repetition or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex 26-parameter drawing tool with no output schema, the description covers the core composition model, shape semantics, modes, and next steps. It still leaves significant gaps around many optional parameters and detailed behavioral expectations, so it is only adequate rather than 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?

With only 31% schema description coverage across 26 parameters, the description must compensate. It adds helpful semantics for the core required strokes parameter and shape behavior ('stroke accepts arbitrary chart points; line accepts two endpoints; ellipse and rectangle accept two opposite corners') and for the brush/highlighter modes, but it leaves many styling and annotation parameters unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: 'Create one or more precise freehand strokes as a single undoable composition.' It clearly establishes the drawing purpose, but it does not explicitly distinguish this tool from close siblings such as drawing_add or fibonacci_draw.

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 concrete mode guidance ('Use highlighter for translucent emphasis and brush for circles, paths and marks') and a follow-up workflow ('finish with chart_link, or analysis_prepare'). However, it does not state when to choose this tool over sibling drawing tools or when not to use 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?

Annotations declare readOnlyHint=false and destructiveHint=false, so the safety profile is already covered; the description adds real value beyond that by explaining that unspecified properties are preserved (i.e. this is a patch, not a replace) and by warning against copying stored styles or hex colours. It doesn't say what happens with an unknown/stale id, which keeps it from a 5.

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 the partial-update rule, then the concrete example, then the workflow. The middle sentence about telling drawings apart is somewhat discursive ("a reader has only the picture to tell them by") but still carries the design rationale for colour choice, so little is truly wasted.

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 24-parameter mutation tool with no output schema, the description covers the essentials an agent needs: partial-update semantics, the minimal payload pattern, id sourcing, and the finishing workflow. It is thinner on the long tail of styling flags, but those are largely self-describing and non-destructive.

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 42% across 24 parameters, so the description has to carry weight; it does so for the highest-risk ones by explaining the semantic meaning of "up"/"down" colours (bullish/bearish assertions, not measurements) and by giving a concrete minimal text-edit payload. The remaining booleans (arrowEnd, showStats, showLabels, extendLeft/Right, textBold, etc.) get no explanation in either the schema or the description, so it only partially compensates.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Edit only the requested properties of an existing drawing") plus the key semantic that distinguishes it from drawing_add: it is a partial update and "all others are preserved." An agent can tell this apart from the sibling creation/freehand tools without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-do-what: send just {id,text,fontSize} for a text edit, never re-send the stored style, get the id from chart_state. It also names downstream steps (chart_link, or analysis_prepare for a review draft), so the agent knows both the precondition and the follow-on.

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 it is a mutation (readOnlyHint=false) that is neither idempotent nor destructive. The description adds valuable workflow context: it changes the chart being built, should be finished with chart_link or analysis_prepare, and automatic anchor modes select exact CLOSED-candle wick coordinates. It does not mention rate limits or auth, but with annotations covering the safety profile this is a solid addition.

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 purpose, then usage rules, then workflow guidance. Each sentence serves a purpose, though it is somewhat lengthy; it could be tightened slightly without losing 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?

For a complex 29-parameter tool with no output schema but clear annotations, the description covers purpose, usage constraints, anchoring behavior, and workflow. The main gap is incomplete parameter semantics, but the core operational guidance an agent needs to invoke it correctly is present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With schema coverage at 34%, the description must compensate for many undocumented parameters. It does explain the most critical ones (anchorMode, ref, lookback) and the coordinate requirement, but leaves over twenty style and display parameters (fill, color, width, levels, opacity, text options, etc.) without added meaning beyond their names or enums.

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: 'Draw a Fibonacci study directly on the chart'. It enumerates the supported variants (retracement, extension, channel, time, fan, circle, spiral, arc, wedge), making it clearly distinguishable from generic siblings like drawing_add 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: prefer swing timestamps/prices from market_candles rather than visual guesses, use anchorMode high-to-low/low-to-high with ref and lookback for highest-high/lowest-low retracements, and do not substitute window start/end times. It also names the finish steps (chart_link or analysis_prepare) and when to choose each.

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, idempotent and non-destructive, so safety is covered. The description adds real value beyond that: it is 'free and always answers,' requires no paid membership, and returns only what a non-member 'may see,' implying tiered/limited output. That access-model context is useful and not present in the structured fields.

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, but the opening is dense and mixes a product pitch ('What Basis Founders adds to this connection') with the actual function. The membership-marketing framing competes with the functional content, so the front-loading is weaker than it could be even though no sentence is redundant.

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 zero params and no output schema, the description does the necessary work of naming what the return contains (tracked whale counts, combined book, top coin) and when to call it. Coverage is adequate for a no-argument preview tool, though it leaves the exact shape of the returned totals implicit.

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 takes zero parameters, so the schema is empty and the baseline is 4. The description correctly implies a no-argument call whose output is a fixed preview payload, and adds nothing misleading about inputs.

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 what the tool surfaces (screened Hyperliquid whale counts, their combined book, the coin most hold) and frames it as a founders-membership preview, but it never gives a clean verb+resource statement of the action and blurs purpose with marketing copy. It only loosely differentiates from the hyperliquid_whale_read sibling, relying on a routing sentence rather than a clear 'this tool does X' claim.

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 triggering conditions ('whale positions, whale or gamma levels, more than 30 days of derivatives history, or a stock or commodity on Hyperliquid or Binance'), which is strong when-to-use guidance. However it names no alternatives and offers no when-not-to-use exclusion, so an agent is not told which sibling to prefer for overlapping whale queries.

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 readOnly/idempotent/destructive=false, so the description is free to add genuinely new behavioral facts: all output series are returned (not one), each is reduced, the forming bar is excluded by default, and handles behave differently under dataMode. Missing any note on cost/latency of computing a full catalogue run, which would matter for openWorldHint=true.

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, each carrying a distinct fact — scope, return shape, input mode, and the forming-bar default — with the most decision-relevant information (what you get back) front-loaded. 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 an 11-parameter tool with no output schema, the description adequately conveys the output contract and the two input paths. It leaves the dataMode trade-off and enum semantics entirely to the schema, which is acceptable given 73% coverage but not fully self-contained.

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 73% schema coverage the schema does much of the work, but the description adds real meaning: symbol vs ref as alternative data sources, plot as 'usually omit' because other series give the reading meaning, and includeForming's default. reduce and exchange/timeframe are left to the schema enums.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Run any indicator in the catalogue') and immediately clarifies the return contract: every output series (Donchian's three bands, MACD's line/signal/histogram) plus conventional levels. This distinguishes it from chart_add_indicator and chart_toggle_indicator, which mutate the chart rather than compute series.

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?

'Pass a symbol to load and compute in one call, or a handle to reuse data' gives a clear selection rule between the two data paths, and the forming-bar sentence sets an explicit default. It stops short of naming a sibling to use instead (e.g. catalog_search to obtain studyId) or saying when to prefer chart_add_indicator, so no true 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 cover the safety profile (readOnly, idempotent, non-destructive), yet the description still adds substantial non-obvious behavior: bars are deliberately withheld, a forming bar may be present, and defaults fall back to the current chart. It also disambiguates the return semantics (lastClosedCandle as one exact OHLC bar vs. whole-window high/low with highAt/lowAt timestamps).

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-loads the core contract (handle, not bars) in the first sentence and packs each subsequent clause with a distinct caveat. The back half is dense semicolon-separated jargon, but nearly 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?

With no output schema, the description carries the full burden of describing the return value and does so: handle, summary, lastClosedCandle, window extreme fields with timestamps, from/to boundaries, and the bars/closedBars relationship. An agent has enough to call it and interpret the result 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%, so the baseline is 3; the description goes beyond it by explaining the closed-vs-forming bar implication of `bars` and by clarifying that unspecified market/symbol/timeframe default to the chart. It does not touch `withDerivatives` or the enum choices, leaving a small 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?

States a specific verb and resource ('Load price history') and immediately defines the distinctive output contract: a handle plus summary, not the bars. That contract separates it from the compute siblings in a way an agent can act on without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly directs the agent to pass the handle to the compute tools rather than expecting bars back, and gives a concrete sizing rule ('request N+1 for N closed bars and check closedBars'). It stops short of naming the specific sibling (e.g. indicator_compute) or stating when not to use it, but the routing guidance 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 already declare the tool as read-only, idempotent, non-destructive and open-world. Beyond that, the description clarifies that funding is a transfer between longs and shorts rather than a trading commission, explains handle reuse via ref, and lists the returned data including decimal and percentage rates, settlement interval and optional payment scenario.

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 purpose and scope, followed by concise clarifications about ref reuse, the nature of funding, and return values. Every sentence contributes useful information without 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?

Given the seven optional parameters, 86% schema coverage and rich annotations, the description is largely complete. It explains the core purpose, ref behavior, funding semantics and key return values, though it does not describe the return shape for open interest and positioning in detail.

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 high at 86%, so the schema already carries most parameter meaning. The description still adds useful semantics for ref by saying it reuses a fresh derivatives handle, and it clarifies the payment-scenario context relevant to side and notionalQuote. It does not add much detail for the remaining 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: reading current perpetual funding, open interest and positioning directly by symbol. It also distinguishes this from candle-based workflows by saying it works 'without loading candles first,' which helps separate it from siblings such as 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?

It gives clear usage context: use this for direct by-symbol derivatives reads and avoid loading candles first. It also explains that an optional ref reuses a fresh derivatives handle. However, it does not explicitly name alternatives or state when not to use the 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?

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 declare readOnly/idempotent/non-destructive/openWorld, so safety is covered. The description adds genuinely useful context beyond that: ordering (newest first), the archive coverage boundary ('starts when Basis began collecting'), and the warning that an empty page does not prove no news occurred.

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 short, front-loaded sentences with zero filler; the core purpose and the sibling routing come first, and the caveats follow.

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 does its part by describing the return shape (headlines, newest first, source links, no full article text) and the coverage caveat. It is nearly complete for a read tool; only the parameter-name error in the pagination guidance keeps it 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?

Schema coverage is 50% and the description does not fill the gap; instead it refers to pagination via 'nextBefore' while the actual parameter is named 'before', which is actively misleading. It adds no format or usage detail for asset, limit, or topic beyond what the schema already specifies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (read archived crypto headlines) with scope details (newest first, source links) and explicitly distinguishes itself from the sibling news_recent. An agent can pick it apart from news_recent without opening either 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?

Explicitly names the alternative and the selection condition ('Use news_recent for live headlines') and adds a negative use case ('No full article text'). However, the pagination instruction points at 'nextBefore', a parameter that does not exist in the schema, which weakens the otherwise strong 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 cover the safety profile (readOnly, idempotent, openWorld, non-destructive), so the bar is lower. The description adds genuinely useful context beyond them: the impact score is a 'keyword heuristic, not a judgement about the market,' and headlines carry an age field. These disclose behavior an agent would otherwise misinterpret.

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 the core purpose, followed by the impact caveat and the hours hint. No filler sentences; every clause carries 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?

No output schema exists, so the description usefully previews the return shape (headlines, impact score, touched assets, headline age). For a 4-parameter, no-required-field read tool this is nearly sufficient; the only missing piece is guidance on minImpact's filter levels.

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 75% — asset, hours, and limit are documented in the schema; only minImpact has an enum but no description. The description reinforces hours semantics ('today'/'last 24 hours') and explains the impact heuristic, but says nothing about minImpact thresholds or the limit parameter, so it does not fully compensate for the 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?

States a specific verb+resource: 'Recent crypto headlines with an impact score and the assets each one touches.' The 'recent' framing implicitly separates it from the news_history sibling, but the description never names news_history or news_detect_assets, so differentiation is left to inference.

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?

Offers a concrete usage cue — 'Pass hours for "today" or "the last 24 hours"' — which is a real hint about parameterization. However, it gives no guidance on when to choose this over news_history or news_detect_assets, and no exclusions or prerequisites are 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?

Annotations already declare readOnly, idempotent and non-destructive, so safety is covered. The description adds genuine value on the read side: what is returned (timestamp, spread, largest displayed levels, bounded depth coverage) and what is out of scope (hidden stops, guaranteed support). No cost, rate-limit or auth context, which keeps it at 4 rather than 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the verb and scope, then routing, then return shape. Every clause carries information and nothing is repeated.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries return values itself and does so adequately (timestamp, spread, largest levels, depth bound). Exclusions preempt the most common misreading of order book data as support/resistance. The only gap is the spot-vs-perpetuals wording, which is minor against an otherwise complete picture.

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 80%, so the schema largely documents levels, market, symbol, exchange and the notionalQuote VWAP caveat, giving a baseline of 3. The description's 'largest displayed levels' and 'bounded depth coverage' loosely frame the levels parameter but add no syntax or format detail. Minor inconsistency: the description says 'perpetuals' while the market enum also permits 'spot'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Read current displayed resting bid/ask limit orders') and scopes it to four named venues. It explicitly distinguishes itself from the sibling orderflow_read, so an agent can route correctly without opening either 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?

Gives positive triggers ('resting liquidity, order book/DOM and buy/sell walls'), a named alternative with the condition that selects it ('NOT orderflow_read, which reads executed trades'), and exclusions ('Not historical depth, hidden stops or guaranteed support'). Nothing is left to inference.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety bar is low; the description still adds real behavioral context: the metric is measured from the venue aggressor tag rather than inferred from bar direction, and the caller must report coveredMinutes rather than the requested minutes. It stops short of describing payload shape or any limits on repeated reads.

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 critical disambiguation (executed vs resting) is front-loaded, and every following sentence carries routing, measurement-provenance, or window-selection information. Dense but with 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?

No output schema exists, but the description names the payload contents (buy/sell volume by aggressor, delta, footprint by price level, POC, absorption/stacked imbalance) and the coveredMinutes caveat. For a 10-parameter, all-optional tool this is enough 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 90%, so the baseline is 3; the description earns above that by explaining parameter relationships the schema does not: candleTime reads exactly that bar and overrides the minutes window, and timeframe only applies with candleTime (defaulting to the chart timeframe). Defaults for market/symbol resolving to the chart are implied rather than spelled out.

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 resource and scope: executed (not resting) trades, split by aggressor side, with delta, footprint, POC and absorption. It explicitly contrasts itself with the sibling orderbook_read, so an agent can distinguish the two without opening either 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?

Names the alternative (orderbook_read) for resting liquidity/walls and gives the selecting condition: 'use it when the question is who is being aggressive, which candles cannot answer.' It also distinguishes two modes of use, single-candle via candleTime versus the trailing `minutes` window.

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 a pure, idempotent, non-destructive read (readOnlyHint/idempotentHint/destructiveHint), so the safety profile is covered. The description adds real value by disclosing the shape of the result set (it computes fees, funding, breakeven, liquidation estimate and warnings), which matters because there is no output schema. It doesn't discuss assumptions or edge cases of the estimates (e.g. that liquidation is approximate).

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 purpose and the sibling routing at the end. The long output enumeration is dense but earns its place given the absence of an output schema. No filler sentences.

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 12-parameter calculation with 5 required inputs and no output schema, the description fills the biggest gap by naming the returned metrics, and the annotations cover the safety profile. Remaining gap: it doesn't clarify the required stop/entry/side relationship or what the warnings represent, which an agent would need to invoke it confidently.

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%, so most inputs (equity, feeBps, leverage, fundingRate, riskPercent, holdingHours, fundingPerDay, maintenanceMarginRate, targets) are already documented in the schema. The description adds no parameter-level meaning — the nouns it lists map to outputs, not inputs — so it neither compensates for the uncovered fields (entry, stop, side beyond the enum) nor adds syntax guidance.

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 ('risk-first position sizing') and enumerates the concrete outputs it produces (quantity, notional, margin, leverage, fees, funding, breakeven, liquidation, R multiples, warnings). It also explicitly contrasts itself with the sibling position_plan_on_chart, so an agent can pick between them without opening either 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?

Provides an explicit routing rule: 'Use position_plan_on_chart instead when the user should see the plan on the chart.' That cleanly separates the two sizing tools. It stops short of stating prerequisites (e.g. stop must differ from entry, stop side relative to entry) or when this tool is the wrong choice for other reasons.

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 non-read-only, non-destructive, non-idempotent, closed-world. The description adds context beyond that: no equity/risk input, no sizing, no order placement, and the important default that without timestamps the box spans recent closed candles rather than future bars or an executed trade. It stops short of saying what happens on repeated calls (e.g. duplicate boxes accumulating).

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 the identity and primary action, then alternatives, then the default-time semantics, then follow-up steps. Dense but each sentence carries distinct information, though the final sentence is doing a lot of work in one clause.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter mutation tool with no output schema, the description covers scope, safety-adjacent behavior, default time semantics and the workflow handoff. The remaining gap is which optional parameters (symbol, timeframe) need to be supplied versus defaulted.

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 33%, and side/symbol/timeframe have no descriptions anywhere. The description partially compensates by explaining the omitted-timestamp behavior and default barsWide span, but it does not clarify symbol or timeframe handling.

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 ('long/short position drawing tool') and enumerates what gets drawn (entry, stop, target box). It explicitly contrasts with the sibling position_plan_on_chart, so an agent can separate the two 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?

Gives an explicit when-not-and-alternative: use position_plan_on_chart only when quantity and risk calculations are also wanted. It also names the follow-up tools (chart_link, or analysis_prepare for a sharing draft needing human review), which is real routing information.

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 a non-read-only, non-destructive operation, and the description usefully adds that it changes the chart being built and that the drawing persists plan details for later analysis. It also explains timestamp behavior for illustrative scenarios, though it does not discuss undo or overwrite 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 front-loaded with the core action and follows with persistence, timestamp caveat and workflow guidance. It is dense but every sentence contributes relevant information for a complex chart-mutating 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 complex 19-parameter tool with no output schema, the description adequately covers purpose, chart side effects, drawing persistence and follow-up steps. It could be stronger with more detail on returned calculation results or error conditions, but the essential behavioral context is present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 19 parameters and 68% schema description coverage, the schema carries most parameter meaning. The description adds useful context about risk-first planning, retained drawing fields and timestamp omission behavior, but does not clarify the remaining undocumented parameters such as side, entry, stop, symbol and timeframe.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: calculate a long/short position and draw entry, stop and first target on the live chart. The combined calculate-and-draw purpose is clear, but it does not explicitly distinguish itself from siblings such as position_calculate or 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 useful follow-up workflow guidance by naming chart_link and analysis_prepare as next steps. However, it does not explicitly say when to use this tool instead of position_calculate or position_draw_on_chart, nor does it state 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?

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), yet the description still adds real simulation semantics: fill timing at next-bar open, one-bar holding, and that costs track actual turnover so a carried position is not charged a fresh round trip. It omits practical cost concerns such as runtime for large lookback × universeSize combinations.

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 tight sentences with the core mechanic front-loaded, followed by the routing discriminator and the cost-model caveat. Nothing is redundant with the title or schema.

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 tool with no output schema, the description explains the strategy construction well but never indicates what comes back (equity curve, returns, hit rate, per-trade list) or how lookback and universeSize affect runtime and result length. Adequate but leaves a real gap around the return value.

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 nearly every parameter is already documented in structured data; the description's only added meaning is that slots are equal-weight (maxPositions) and that costs are per side applied to turnover (feeBps/slippageBps). It adds nothing about rules, universeSize, or manualSymbols 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 and resource — historically replaying a cross-sectional screen at every bar — and spells out the mechanics (equal-weight long/short, entry at next bar open, held to the following bar open, then re-screened). This is clearly distinguishable from screener_run (single point-in-time screen) and backtest_run (single-symbol).

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 says when to use it ("when the question is whether repeatedly trading screener matches worked") and names the wrong alternative in generic terms ("a single-symbol backtest of coins that match today is not a substitute"). It stops short of naming the sibling tools backtest_run or screener_run, so routing is inferred rather than 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?

Annotations already cover safety (readOnly, idempotent, non-destructive), so credit goes to what the text adds: a cost hint that it 'fetches history for every instrument in the universe', plus the note that several params default to the current chart's setting. It does not describe pagination or performance limits on large universes.

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 the core purpose and followed by progressively more specific guidance; each sentence carries information. Slightly padded by restating schema defaults ('Defaults to the chart') inline, which lengthens the prose without new meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 13-parameter tool with a nested rules grammar and no output schema, the description never says what a match actually contains (symbol + which values, how the matched rule is reported). Rules-construction and universe sizing are well covered, but the shape of results remains an inference for the agent.

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 85%, so the baseline would be 3, but the description adds real semantic value the schema lacks: the limit vs universeSize distinction ('limit controls returned matches, universeSize controls how many markets are searched') and a concrete worked example for rules with an indicator operand. The above/crossesAbove operator guidance also disambiguates an enum the schema leaves bare.

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 (scan) and resource (the venue's listed instruments), and explicitly contrasts scope with 'looking at the open chart', which separates it from the chart_* and indicator_compute siblings. The phrase 'which coins are doing X right now' nails the intent in an agent-legible way.

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 clear invocation context ('which coins are doing X right now') and a decision rule for the trickiest choice: 'Use above for a current state; crossesAbove only for a fresh crossing.' It never names a sibling alternative (e.g. screener_backtest, daytrade_opportunity_scan) or states when not to use it, so it stops short of a 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?

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.