Clear Tape

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

Annotations already declare the safe, read-only, idempotent profile, and the description adds real context beyond them: the computation uses the same function as the linked calculator page ('not estimated'), and it discloses the result shape (inputs, results with units, formula, page link) plus an educational disclaimer. It doesn't cover failure modes or bounds, keeping it short of 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 definition so the agent grasps the operation before the input requirements. Slightly dense with the provenance and return-format clauses, but every sentence 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?

No output schema exists, yet the description covers the return payload (inputs, each result with its unit, the formula, the page link), the input fallback rule, and provenance. Nothing needed to invoke the tool 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 100%, so the baseline is 3, but the description adds the semantic relationship between parameters — entry combined with multiple×ATR, and the long/short sign flip — that the per-field schema text does not express. It also reinforces that ranges is an alternative to atr rather than a supplement.

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 ('A volatility (ATR) stop') and spells out the exact formula — entry minus/plus a multiple of ATR — which cleanly separates it from sibling calculators like calculate_position_size or calculate_risk_reward. An agent can tell instantly what this tool computes.

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

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

It gives an input-selection rule ('Give atr, or at least five recent daily ranges') but never states when to reach for this tool versus the sibling risk calculators (position_size, risk_reward) or what regime it fits. Usage is implied by the tool's purpose rather than explicitly routed.

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, idempotent, non-destructive profile, and the description adds real value on top: it is a deterministic computation from the same function as the linked public page rather than an estimate, and it discloses the return contents (inputs, results with units, formula, page link). The educational disclaimer is also useful context.

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 compact sentences, front-loaded with the primary result and the optional one, with no filler. Slightly dense in the first sentence but 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?

With no output schema, the description compensates by naming what comes back (inputs, results with units, formula, page link) and by flagging the optional riskPct behavior. Only the input-validation story (loss must be between 0 and 100) is left entirely to the schema, which is acceptable given the 100% coverage.

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 loss, riskPct and lang are fully documented with bounds and defaults at baseline 3. The description restates the drawdown and fixed-risk-per-trade concepts but adds no syntax or semantics beyond the schema.

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

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

States a concrete computation: the gain needed to recover from a drawdown, plus optionally the consecutive-losing-trade count at a fixed risk. Verb and resource are specific, though the optional losing-streak output overlaps conceptually with the sibling calculate_losing_streak and the description does not address that boundary.

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

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

Usage is only implied: supplying riskPct triggers the losing-streak result, otherwise only the recovery gain is returned. There is no when-to-use/when-not guidance and no routing to or away from the sibling calculators, so an agent must infer the context.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds genuine behavior beyond that: results are computed with the same function as a named public calculator rather than estimated, and the response includes inputs, unit-labeled results, the formula, and a page link. It also discloses the 'educational, not investment advice' disclaimer that 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 sentences, front-loaded with the computed outputs so an agent immediately knows what it gets. The calculator-provenance and disclaimer sentences earn their place given the absence of an output schema, though the two provenance clauses could be tightened into one.

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 return-value burden and does so adequately: inputs echoed, results with units, the formula, and a page link. Combined with 100% schema coverage and rich annotations, an agent has enough to call and interpret it, though the absence of any usage routing keeps it short of 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 winRate as percent, avgWin/avgLoss as positive same-unit amounts, and lang as en/zh. The description only restates the inputs ('from a win rate and average win and loss') and adds no constraint or unit detail beyond the schema — 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?

Names the exact metrics produced (expectancy per trade, per 100 trades, payoff ratio, break-even win rate, profit factor) and the exact inputs (win rate, average win/loss). This clearly differentiates it from siblings like calculate_kelly_criterion or calculate_risk_reward, which take different inputs and yield different outputs.

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

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

Usage is only implied by the input/output framing — an agent can infer this is the tool for expectancy math, but the description never states when to prefer it over siblings (e.g. kelly criterion, risk-reward) or any exclusions. No explicit routing guidance is 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?

Annotations already establish readOnly, idempotent, non-destructive and closed-world behavior, so the bar is lower. The description goes beyond them by disclosing that the value is computed deterministically with the same function as the public Clear Tape page rather than estimated, that it is an educational output, and what the payload contains — meaningful context for a computation 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?

Three tight sentences that front-load what is computed, then provenance, then return contents. The closing disclaimer is the only arguably optional line, but it is short and compliance-relevant rather than 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, and the description compensates by listing the return payload (inputs, each result with its unit, the formula, the page link). Combined with the provenance note and the educational disclaimer, an agent has everything needed to call and interpret this tool.

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

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

Schema description coverage is 100%, including units, ranges and the fraction semantics (25 = quarter Kelly), so the schema carries the parameter burden. The description only echoes win rate and payoff ratio as inputs without adding format or edge-case meaning, 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 verb and resource — full/fractional Kelly risk per trade from win rate and payoff ratio — plus the derived outputs (edge per 1R, break-even win rate). The tool's identity is unambiguous among the calculate_* siblings, but the description never names a sibling or explains how it differs from calculate_position_size / calculate_expectancy beyond the concept name.

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

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

Usage is only implied by the purpose: an agent can infer it is for Kelly-based sizing questions, but there is no explicit when-to-use, no prerequisite statement, and no routing against the other risk calculators. The 'educational, not investment advice' line sets a scope boundary but is not an invocation guideline.

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, closed-world), so the description's job is to add context — and it does: it states the computation is exact rather than estimated, cites the same function used on Clear Tape's public page, and enumerates what comes back. It does not discuss accuracy limits or edge-case behavior (e.g. streak larger than trades), but the added provenance context is genuinely useful.

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 core computation is front-loaded in the first sentence and the return contract and disclaimer follow in order. The three-result enumeration is slightly dense but each clause carries information; there is little 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 compensates by describing the return payload (inputs echoed back, each result with its unit, the formula, and the page link). Combined with a fully documented input schema (including ranges and the lang enum), an agent has everything required to call and interpret this tool.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds a meaningful modeling assumption not in the schema: that trades are independent and that the streak is evaluated over those independent trades. That framing matters for interpreting winRate and trades correctly and goes beyond the field-level docs.

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

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

The description names a specific verb and resource and enumerates the exact outputs: probability of at least one losing streak of a given length, expected longest streak, and the 95% bound. It is clearly distinct from sibling calculators like calculate_drawdown_recovery or calculate_kelly_criterion.

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

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

Usage is only implied by the tool's subject matter (streak-risk planning for a given win rate and trade count). The description offers no when-to-use/when-not guidance and never names an alternative sibling calculator, so the agent must infer the context. The 'educational, not investment advice' line is a disclaimer rather than 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 safety (readOnly, idempotent, non-destructive, closed-world), and the description adds real context beyond them: results are deterministic and identical to the linked calculator page rather than estimated, and the output carries units and the formula. The educational/not-advice disclaimer is an extra scoping note absent from 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?

Front-loaded with the core definition, then result shape, then the disclaimer. Four sentences with little waste, though 'linked in the result' and the trailing educational note are slightly loose together.

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 describing the return payload (inputs, each result with its unit, formula, page link), and the deterministic-source claim answers the obvious trust question. Missing only guidance on failure cases, such as stop equal to or on the wrong side of entry.

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 five parameters, including the lang enum and the long/short relationship between entry and stop, are already documented in the schema. The description only gestures at 'the inputs' without adding new 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 computation: shares to buy or short such that a stop-out loses a given percentage of the account, which is distinct from sibling calculators like calculate_risk_reward or calculate_atr_stop. The verb+resource pairing is clear, though it never names a sibling to route against.

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

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

Usage is implied by the input set (account, risk %, entry, stop) and the disclaimer that it is educational, but there is no explicit when-to-use, no prerequisites, and no naming of alternatives such as calculate_risk_reward or calculate_atr_stop for related 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 already declare this a safe, idempotent, closed-world read, so the description is not burdened with safety disclosure. It adds genuine behavioral context beyond the annotations: the result is deterministically computed by the same function as a known calculator page ('not estimated'), and it discloses the shape of the return (inputs, each result with its unit, formula, and page link).

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 computed outputs, followed by provenance and return format. Minor redundancy: the page link is referenced twice ('linked in the result' and 'the page link'), and the educational disclaimer is boilerplate, but overall it is tight.

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, and the description compensates by stating what is returned (inputs, each result with its unit, the formula, the page link). With 100% parameter coverage and a closed-world read annotation, an agent has enough to call and interpret 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 the schema already documents entry, stop, target, exit, and lang with units and constraints. The description only echoes that exit is optional and an R multiple, adding little beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description names a specific verb and a concrete set of outputs (risk/reward ratio, breakeven win rate, optional R multiple), which is far more specific than a tautology. It is clearly a calculator, and the outputs differentiate it in substance from siblings like calculate_kelly_criterion or calculate_position_size, though it never names an alternative explicitly.

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

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

Usage is implied by 'of a planned trade,' which signals a pre-trade evaluation context, but there is no explicit when-to-use, when-not-to-use, or routing to a sibling calculator. An agent can infer the scenario but must guess about overlap with calculate_expectancy or calculate_position_size.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world behavior, so the description is freed to add value — and it does: results are deterministic (same function as the public calculator page, 'not estimated'), the page link is embedded in the result, and the response includes inputs, per-result units and the formula. The disclaimer further sets expectations.

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 what is computed, then provenance, then the return shape, then the disclaimer — no filler. The disclaimer sentence is mild boilerplate but earns its place for a financial-adjacent 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?

With no output schema, the description steps in well by enumerating what comes back (inputs, each result with its unit, the formula, the page link). Combined with full parameter documentation and safety annotations, an agent has enough to call and interpret it; only error/edge-case behavior (e.g. stop equal to entry) is left unaddressed.

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 every parameter including defaults, bounds and per-side vs per-order semantics. The description only loosely echoes the inputs ('commissions, bid-ask spread, slippage') without adding format or interpretation detail, 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 precise computation — the round-trip cost of a trade broken into commissions, bid-ask spread and slippage — and gives result units (USD, R multiple, share of target move, share of position, annualized). This is a distinct resource among the sibling calculators (position size, Kelly, drawdown), so an agent can disambiguate 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?

Usage is implied rather than stated: the tool is for estimating the all-in cost of a trade, and the closing note frames it as educational rather than investment advice. There is no explicit when-to-use/when-not guidance or routing to sibling calculators such as calculate_risk_reward or calculate_expectancy.

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, non-destructive and closed-world, so the description only needs to add what they cannot. It does: content is 'worded exactly as on its strategy page', it is educational rather than investment advice, and it enumerates what is deliberately absent (signals, prices, performance), which sets expectations a caller cannot get from the schema alone.

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 no-id case first, then the with-id case, then the exclusions, so the most common path is read first. It is a dense single paragraph with no filler sentences, though the detail list is long enough that a caller must read carefully to the end.

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 carries the full burden of describing returns, and it does: the list view's fields (style, holding period, entry/stop/exit) and the detail view's fields (rules, parameters, data needs, terms, variant differences, strengths, weaknesses, suitability, sources). An agent knows what it gets in both modes.

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 enums are self-describing, so the baseline is 3. The description still adds real meaning by explaining the semantic consequence of the id parameter (omit to list all, supply to get one system's full written rules) and by naming the four preset families the enum values cover, which the schema does not.

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 verb and resource and splits the behavior cleanly by input: listing eleven preset systems (with their style, holding period, entry/stop/exit one-liners) when no id is given, versus one system's exact written rules when an id is supplied. That distinction separates it at a glance from the sibling calculate_* and lookup_glossary_term tools.

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

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

The no-id vs with-id branches tell the agent exactly which form to call for a list versus a deep dive, and 'Rules only: no signals, no prices, no performance figures' explicitly rules out nearby intents that a sibling calculator would serve. It stops short of naming an alternative tool to use instead, so it is clear context rather than 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 readOnlyHint, idempotentHint, non-destructive and closed-world, so safety is covered; the description goes beyond them by disclosing fuzzy-matching behavior and the exact return contents (definition, other-language term, close matches, links). It does not mention rate limits, but none appear relevant for a static 70-term glossary.

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, zero filler, with the core capability and the bilingual scope front-loaded before the matching and return details. Every clause carries information an agent can act on.

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

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

With only two simple parameters and no output schema, the description compensates by enumerating the return payload (definition, cross-language term, close matches, links), leaving no significant gap for correct invocation.

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

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

Schema coverage is 100% and lang is enum-documented, so the baseline is 3; the description adds real meaning about the term parameter by noting English or Chinese input, pinyin matching and misspelling tolerance, which tells the agent what forms are acceptable.

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?

Specific verb (looks up) plus resource (trading term in a bilingual glossary) with concrete scope (~70 terms) and representative examples like "R multiple" and "止损". It is cleanly distinguishable from the sibling calculate_* tools because it retrieves definitions rather than computing values.

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

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

The matching description (names, abbreviations, pinyin, misspellings tolerated) clearly signals the situations this tool handles and implicitly when it is the right choice versus the calculator siblings. It stops short of an explicit when-not-to-use or named alternative, so it is strong but not exhaustive.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds useful context beyond that: the result format (titles, summaries, links) and the content boundary (education only, no market data), but says nothing about result limits or how ranking works. With annotations carrying the safety story, this is adequate but not rich.

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 with zero filler; the searchable content scope is front-loaded, the return shape follows, and the exclusion is a compact final clause. Nothing repeats the schema or the 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 three-parameter read-only search tool with no output schema, the description supplies what the schema cannot: which corpora are indexed, the shape of a result, and the bilingual behavior. Only minor gaps remain, such as pagination or ordering behavior, which are unlikely to block a correct call.

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%: lang, limit and query all carry their own descriptions with defaults, ranges and an example. The description only echoes the bilingual capability already stated in the lang param, adding no syntax or format detail beyond the schema. 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?

Names a specific verb (searches) and resource (Clear Tape's free trading education), then enumerates exactly which content is covered: Learn articles, Academy lessons, strategy pages and calculators. It also states output shape (titles, one-line summaries, links) and excludes market data, so an agent can separate it from the calculate_* and lookup_glossary_term siblings without opening a schema.

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

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

Usage context is clear: keyword lookup over educational content in English or Chinese, with an explicit exclusion ("No market data"). It does not, however, route the agent between this tool and the closest alternative, lookup_glossary_term, so the caller must infer that boundary.

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