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

The annotations declare readOnlyHint=true, yet the description states 'A rule that fires is recorded so it does not fire again for the same bar' and describes dry_run as 'Evaluate without recording fires.' This directly contradicts the read-only claim and indicates a state-changing side effect.

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

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

The core action is front-loaded in the first sentence, and the later caveats about reason, warming-up, and missing volume are substantive rather than filler. It is longer than necessary but each part contributes to correct interpretation of results.

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

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

With no output schema, the description does a good job of explaining the tricky reason semantics and the volume-missing situation, and it makes the optional parameters understandable. It still does not describe the full response shape (how fired rules are identified), but the essential invocation and interpretation guidance is present.

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

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

Schema coverage is 100% and both parameters already have clear descriptions ('Only check rules for this ticker' and dry_run's explanation). The body of the tool description adds useful behavior context but no additional parameter-level syntax or formatting detail, so the baseline score applies.

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

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

The opening sentence states a specific action — 'Evaluate stored alert rules against current Stockbit bars and report which fired' — and clearly identifies the resource. This sets it apart from sibling alert_list, alert_create, and alert_delete, which manage rule definitions rather than execute checks.

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

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

The description gives clear context on when to call this tool: to evaluate stored rules and see which fired, with optional symbol scoping and dry_run behavior. It does not explicitly name alternatives or state when not to use it, but the purpose sentence makes the use case unambiguous.

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

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

The prose discloses rich behavior: the same grammar as pine_script, refusal to store unevaluable conditions, volume absence semantics, once-per-bar firing, and no background delivery. However, the annotations declare readOnlyHint=true while the description says this tool creates and stores an alert, which is a direct contradiction. Per the rubric, this must be scored 1 and flagged.

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 long but dense and purposeful: it front-loads the main action, then explains grammar/declaration rules, the volume edge case, and firing/delivery behavior. The volume paragraph is somewhat intricate, but it covers a non-obvious semantic that would otherwise cause incorrect expectations.

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 9-parameter tool with no output schema, the description covers input syntax, required series declarations, failure behavior, firing frequency, and delivery model. The only notable gap is the lack of any statement about what the tool returns on success (e.g., an alert ID), but this does not block 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 78%, so the schema already documents most parameters. The description adds meaningful semantics beyond the schema: left/right can reference series, price fields, or numbers; referenced series must be declared via overlays/panels; volume omission is treated as absent and makes conditions unjudgeable; and the default cooldown is once per bar.

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 first sentence states a specific verb (Create), a specific resource (price or indicator alert), a domain (IDX stock), and a storage location (this machine). This clearly distinguishes alert_create from its siblings alert_list, alert_delete, and alert_check.

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

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

The description explains the create-then-check workflow by noting that alerts are not delivered automatically and must be evaluated via alert_check, with no background daemon. It does not explicitly name alternatives to avoid, but the create vs. list/delete/check split is clear from 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 declare readOnlyHint=true and destructiveHint=false, directly contradicting a delete operation. The description itself gives no safety or side-effect context, making behavior ambiguous. This is an annotation contradiction.

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?

Single sentence, front-loaded with the verb and object, and no filler. Every word earns its place.

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

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

For a simple two-parameter tool, the schema coverage and description cover the core call correctly. However, the contradiction with annotations and the lack of any note about success/failure response leave an agent slightly under-informed.

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 already covers both parameters with 100% coverage. The description adds the semantic that disable_only is an alternative to deletion ('instead'), which clarifies the boolean's purpose beyond the schema's wording.

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

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

The description identifies the exact action (delete) and resource (alert rule by id), and even presents the disable alternative. This clearly differentiates it from create/list/check siblings despite not naming them.

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 phrase 'or disable it instead' gives a concrete choice between deleting and preserving-with-disable, which is actionable. It does not explicitly name sibling tools or state when not to delete, but the intended use 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 provide readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds local-machine scope and the last-fired output detail, but does not disclose ordering, pagination, or auth requirements.

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?

Single front-loaded sentence with zero filler; the key verb, object, scope, and output feature are all present.

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

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

For a simple read-only list with one optional, fully-documented parameter and rich annotations, the description is nearly complete. It could mention the optional symbol filter or what an alert rule contains, but the schema and sibling names cover those 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?

Schema description coverage is 100%; the sole optional parameter 'symbol' is documented as 'Only rules for this ticker'. The description does not add parameter-specific meaning, but baseline 3 is appropriate since the schema carries the full load.

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 ('List'), resource ('alert rules'), scope ('stored on this machine'), and output detail ('with when each last fired'). It clearly distinguishes from create/delete siblings.

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?

Clear context of what the tool does, with no exclusions. It doesn't explicitly name alternatives, but the list operation is unambiguous against alert_create/alert_delete, and the optional symbol filter is documented in the schema.

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 goes far beyond the annotations by disclosing confidence is not probability, stops at 90 by construction, missing pillars redistribute weight, floor-locked stocks degrade the flow pillar, and community sentiment is never scored. It also discloses cost (~27 upstream requests), which is highly relevant behavior for an agent deciding whether to call this 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 long but densely packed, with clear headed sections and the main purpose front-loaded in the first sentence. Each section justifies its existence: confidence caveat, pillar weights, limitations, floor-locked behavior, cost, and alternative routing.

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 composite-analysis tool with no output schema, the description covers what the tool returns, what it cannot do, edge-case behavior, cost, and when to use alternatives. An agent has enough context to decide whether to invoke it and to interpret its 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 100%, so the schema already documents all five parameters. The description still adds meaningful context by explaining the cost implication of bar count, how broker_period affects request count, that sentiment is counted but never scored, and how pillar weights interpret the 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 opening sentence names a specific verb ('Weigh'), a specific resource ('one IDX stock'), and a concrete output ('a single lean — bullish, neutral or bearish — with a confidence score and the evidence'). It is immediately clear this is a composite analysis tool and how it differs from data-only siblings like technicals or broker_summary.

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 says to use `technicals` or `timeframe_alignment` if the agent only wants the numbers, giving a clear alternatives condition. It also provides strong context on when the output is less trustworthy: no analyst consensus, valuation weak for certain sectors, floor-locked stocks unreliable, and sentiment never scored.

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

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

The description discloses a deliberately pessimistic execution model: signals read at bar close and filled next open, stop/target conflict resolves to stop, gaps fill at open, and IDX auto-rejection blocks fills. It also spells out Indonesian retail cost defaults, 100-share lots, warning semantics, and long-only constraints — all beyond what the readOnlyHint/openWorldHint annotations 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 dense and generally front-loaded, leading with the primary purpose and outputs before diving into execution details and defaults. The execution-model section is long and compressed into a single paragraph, yet every clause carries a meaningful constraint; minor structure improvements like bullets could improve readability.

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 24-parameter tool with no output schema, the description covers the core output shape, warnings, execution model, cost assumptions, walk-forward mode, and market constraint. It does not explain every parameter or the exact response envelope, but the rich schema plus this description give an agent enough to invoke it correctly.

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

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

Schema description coverage is 83%, so the baseline is high. The description adds real value on top by explaining that entry/exit conditions use the same grammar as alert_create and pine_script, that walk_forward costs no extra requests, and that include_equity/include_trades control output size. It does not fully document the custom condition expression format, but it references the canonical grammar source.

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?

Description starts with a specific verb and resource: 'Run a trading strategy over Stockbit's own daily history' and lists concrete outputs: trades, equity curve, metrics vs buy-and-hold. It also distinguishes itself from alert creation and TradingView strategies by framing backtested rules, live alerts, and strategies as one shared object.

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 strong in-tool usage guidance: use a preset or supply your own entry/exit grammar, set walk_forward for out-of-sample checks, and respect long-only constraints. However, it does not explicitly say when to choose backtest over sibling tools like strategy_compare, analyze, or workflow_run, leaving alternative selection mostly 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?

The description goes well beyond the annotations, disclosing that sell figures are negative, netValueIdr is a lopsidedness measure rather than bought volume, topDistributors is ordered largest seller first, null shares indicate an unreadable side, and limit applies per side. It also documents resolve_names best-effort failure modes and date rejection behavior, with no contradiction against the readOnlyHint or destructiveHint 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 long, but it is organized with clear sections like SIGNS and DATES, front-loaded with the core purpose, and every paragraph carries substantive operational detail. It sacrifices brevity for completeness, and a few rhetorical embellishments could be trimmed, but the structure keeps it navigable.

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 14 parameters and no output schema, the description covers sign conventions, edge cases, failure modes, naming behavior, date rules, and the meaning of result fields. An agent has enough information to call the tool correctly and interpret its response without needing external documentation.

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?

Even though schema coverage is 100%, the description adds real meaning beyond the schema: limit is explicitly contrasted with top, GROSS vs NET behavior is explained, period aggregation cost is noted, and resolve_names semantics are fully described. This gives the agent a much richer understanding of how parameters change both the request and the interpretation of results.

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, unambiguous statement: it is a typed accumulation/distribution reading for one IDX stock, computed from the same broker summary that broker_summary returns. It names the outputs — net buy/sell totals, top accumulators/distributors, concentration — and explicitly says it returns no verdict, score, or price forecast, which separates it clearly from related tools.

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

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

The description explicitly tells the agent when this tool is not enough and directs it to the bandar-check skill before drawing a conclusion. It also gives concrete invocation rules: omit from/to for the latest session, supply both for a range, a half-specified range is rejected, and market_board ALL behaves differently from REGULER.

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, openWorldHint=true, destructiveHint=false, and the description adds extensive behavioral context without contradicting them: unknown broker codes are rejected before any request, `period` is not sent but resolved to dates, rows are per stock per day, buy and sell rows are separate with positive numbers, absences mean the wire did not carry the field rather than zero, and `count: 0` with populated `rowsFrom` vs `rowsFrom: null` have different meanings. This goes far beyond what annotations alone 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?

The description is long but every sentence earns its place given the endpoint's many non-obvious behaviors: reversed lookup semantics, period resolution, repeated-parameter filters, side handling, and response shape quirks. It is front-loaded with the core purpose and sibling distinction, then organized under clear uppercase section labels, making it easy to scan. No filler or redundant 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?

There is no output schema, so the description must explain return values, and it does so thoroughly: row fields, `readFrom`, `rowsFrom`, `count: 0` semantics, `rowsFrom: null`, `dataKeys`, and the nested buy/sell containers. It also covers default window behavior, error handling for `period`, alias handling, and the measured date-resolution verification. For a 13-parameter tool with no output schema, nothing important 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 substantial extra meaning for nearly every parameter group: `broker_code` format and how to find it, `period` being resolved rather than sent, `from`/`to` required together, filters as repeated parameters with union semantics, omit behavior, and the critical warning never to infer direction from sign because both sides are positive. This is far more than the schema alone provides.

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 tells the agent exactly what the tool returns ('which STOCKS one broker traded, and how much of each') and explicitly contrasts it with broker_summary as the reverse lookup. This makes it instantly distinguishable from the sibling tool without needing to open schemas.

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

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

The description gives explicit when-to-use guidance: it names broker_summary as the forward lookup, explains how to chain the two, and tells the agent to use the `brokers` tool to resolve a name into a code. It also provides detailed window selection rules, including that `period` is resolved locally and the preset name never goes on the wire, and what happens when both `period` and `from`/`to` are omitted.

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?

Goes well beyond the annotations by disclosing side effects (writes a .svg file, may open the browser), the gating account requirement (Rp 10,000,000 balance and the error it produces), the output form (image plus savedTo path), and edge-case behavior (empty diagram on holidays is expected). 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?

The description is long but every sentence earns its place: core purpose first, then diagram semantics, output behavior, date rules, data_type, requirements, and an edge case. It is front-loaded with the most important facts and avoids fluff 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 complex tool with 17 parameters and no output schema, the description supplies the essential missing context: return value semantics (savedTo path), output format (SVG image), error conditions (account balance, holiday empties), and how it differs from its closest sibling. An agent has enough to invoke it correctly without further inference.

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; the description adds real value on top by explaining date format and override behavior, the IDR vs LOTS distinction, the impact of market_board=ALL ('changes the numbers a lot'), and the purpose of save_path. It doesn't explicitly narrate every parameter, but the additional clarifications are meaningful.

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: renders broker-to-broker flow as an SVG diagram, and clearly differentiates itself from broker_summary by explaining the difference in scope ('who they accumulated it from' vs. 'how much a broker accumulated'). The layout semantics (buyer left, seller right) further pin down what the tool produces.

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 tells the agent when to use broker_summary instead ('Use broker_summary for per-broker figures') and clarifies what this tool deliberately does not do ('does NOT return a table of numbers'). It also gives precise date selection rules (period preset OR both from/to, from/to override), data_type meaning, and the weekend/holiday expectation.

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 read, and the description layers on substantial behavior beyond that: the server aggregates multi-date windows in one request, half-specified ranges are rejected, sell-side rows already carry negative signs, absent values mean unknown rather than zero, and name resolution is best-effort with a cache. It also flags the 'unreadable' envelope so the agent understands totals may miss rows.

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 text is long but tightly sectioned (DATES, SIGNS, resolve), front-loaded with the core purpose, and every addition addresses a real failure mode an agent would otherwise hit. No filler or tautology.

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, this is unusually complete: it covers date edge cases, sign conventions, missing-data semantics, board selection, limit truncation, and the optional name enrichment behavior. An agent has enough to invoke it correctly and interpret the response.

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%, but the description goes well beyond it by explaining the date-pair constraint, sign conventions for output rows, market_board 'ALL' being several times larger, default limit vs API truncation, and resolve_names semantics. This gives the agent enough to choose and populate parameters correctly without inspecting the schema alone.

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 opening sentence names the verb/resource relationship ('Broker summary for an IDX stock') and enumerates the exact output dimensions: net buys/sells, lots, IDR value, and investor classification. Calling it 'the core bandarmology signal' gives the agent a clear inference target and separates it from generic quote/orderbook tools.

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

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

The description gives strong when-to-use context — bandarmology signal, no TradingView equivalent — and detailed call conventions (latest session if dates omitted, both dates required for history, weekend results are not errors). It does not explicitly name sibling alternatives such as broker_distribution or broker_activity and say when to choose them instead, 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 description goes far beyond the read-only annotation by disclosing authentication requirements, settlement bucket semantics, and that `settlementUnavailable` means a second request failed rather than no unsettled cash. It also transparently notes that field mapping is partly verified, that nonempty rows are projected, and that missing values are not zero. No contradiction with the annotations exists.

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 longer than typical, but every sentence earns its place by explaining a distinct nuance: cash vs. buying power, settlement behavior, auth requirement, and field-mapping caveats. It is front-loaded with the core purpose and well organized into paragraphs.

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 having no output schema, the description provides enough detail for an agent to interpret key response fields and avoid common misinterpretations. It covers authentication, edge cases, and data reliability, making it effectively complete for this parameterless read-only 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?

The tool has zero parameters, so the baseline is 4. The description does not need to explain parameters, and it instead explains output field semantics, which is appropriate here.

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 the resource: cash balance and buying power in a trading account, naming specific fields (`cashIdr`, `buyingPowerIdr`). It is not tautological and adds meaning beyond the tool name, but it does not explicitly differentiate itself from siblings like `portfolio`, `position`, or `financials`.

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 useful contextual guidance, such as using buying power rather than cash to judge affordability and requiring a trading session. However, it does not explicitly state when to prefer this tool over alternatives or when not to use it, so tool-selection guidance is mostly implied rather than direct.

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

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

Annotations already mark this as read-only and non-destructive, and the description adds useful behavioral context: the large HTML report is stripped and results are delivered as structured tables. It also explains that the integer selectors mirror Stockbit's UI toggles. There is no contradiction with annotations.

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

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

The description is a single dense sentence with no filler. It front-loads the output format and then clarifies the parameter semantics, making every part useful in a compact form.

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 four-parameter read-only tool with no output schema, the description gives the return shape (structured tables) and basic selector semantics, but it lacks actual selector values and default behavior. It is sufficient for a basic symbol-only call but incomplete for correct optional-parameter usage.

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?

Only symbol is described in the schema (25% coverage), so the description partially compensates by stating that data_type, report_type, and statement_type are integer selectors matching Stockbit's UI. However, it does not enumerate valid values or explain what each selector controls, which remains a significant 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 identifies the resource as financial statements and clarifies that the output is structured tables after stripping the HTML report. It is distinguishable from siblings like ratios, keystats, and technicals, though it lacks an explicit verb such as 'retrieves' or 'returns'.

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

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

No when-to-use guidance or alternative routing is provided. The description neither names sibling tools nor states conditions under which financials is preferred over ratios, keystats, or other related tools. Usage context is only implied by the tool name and the phrase 'financial statements'.

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 readOnlyHint, openWorldHint, and destructiveHint=false, and the description adds no behavioral detail beyond that. It does not mention return format, data range, units, or any operational caveats, so the description carries little transparency burden and adds no extra behavioral 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?

The description is a single front-loaded sentence with no filler. The parenthetical 'valuation, size, performance metrics' efficiently communicates the core output categories without redundant wording.

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

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

The tool is simple with one well-documented parameter and a readOnly annotation, so the description does not need extensive detail. However, with no output schema and several similar sibling tools, the absence of more specific metrics or a differentiation hint leaves a meaningful ambiguity 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?

The input schema already fully documents the single parameter 'symbol' as an 'IDX ticker,' with 100% schema description coverage. The tool description adds no additional parameter meaning, so the baseline of 3 is appropriate.

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

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

The description identifies the resource as 'a company' and the nature of the data as 'valuation, size, performance metrics,' which conveys what the tool returns. It lacks an explicit verb like 'retrieves' or 'provides,' and it does not explicitly differentiate itself from similar siblings like financials or ratios, but the parenthetical categories give useful scope.

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

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

No guidance is given about when to use keystats versus related tools such as financials, ratios, or quote. The description implies a data-retrieval purpose but provides no context for selection, no alternatives, and no 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?

Although the description discloses timing, token storage, browser-session behavior, proof/rotation, and process termination, it contradicts the annotations. The annotations state destructiveHint=false, yet the description says the tool can sign the profile out, clear the browser's Stockbit session, and with reap_orphans end every process holding the profile, including chart windows still in use. Per the rubric, a direct annotation contradiction forces a score of 1 regardless of otherwise rich disclosure.

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 long but every sentence carries necessary safety, sequencing, or side-effect information. It is front-loaded with the core action and the mandatory 'ASK THE USER FIRST' instruction. Despite its length, there is no filler or repetition; the density is justified by the tool's complexity.

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

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

Given the tool's complexity, multiple boolean parameters, external browser side effects, and no output schema, the description is complete. It covers the async return timing, the token destination, the status check follow-up, environment-variable refusal, non-trading PIN exclusion, and all parameter edge cases. Nothing needed for safe 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 coverage is already 100%, and the description adds substantial meaning beyond the schema: confirm must be user-approved in words, force bypasses an existing stored session, switch_account implies force and signs the user out, fresh_profile does not fix chart tools, and reap_orphans can kill healthy processes. This goes well beyond baseline parameter documentation.

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

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

The description opens with a specific action and resource: 'Open a browser window so the user can sign in to Stockbit.' It also clearly separates this from the trading-account login by stating no tool accepts a PIN, which distinguishes it from trading-related siblings. This is unambiguous and immediately usable.

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 when-to-use and when-not-to-use guidance: ask the user first and pass confirm: true, call status afterward, do not call again while a login is in progress, use switch_account for a different account, and use the terminal command for the trading PIN. It also names refusal conditions and the force/switch_account interaction. This is comprehensive alternative-handling.

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 destructiveHint and readOnlyHint annotations, the description discloses irreversible side effects, the need to re-enter a PIN for trading, clearing of website cookies and shared token caches, and the separate browser profile copy. This gives the agent a full picture of consequences the annotations alone 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?

Every sentence earns its place: the purpose is front-loaded, the mandatory user confirmation is highlighted first, and each subsequent sentence explains a necessary consequence or parameter behavior. It is long but tightly packed with safety-critical 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 destructive, three-parameter, no-output-schema tool, the description fully covers prerequisites, parameter choices, hidden side effects, and irreversibility. Nothing an agent needs to safely invoke it 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?

While schema coverage is 100%, the description adds significant meaning: scope 'main' also clears website cookies and token cache, 'trading' ends the session at Stockbit, and remove_browser_profile deletes a second copy of credentials. This goes well beyond the schema's short parameter descriptions.

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

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

The description opens with the specific, actionable statement 'Clear stored Stockbit credentials from this machine', establishing the exact verb and resource. It further differentiates the tool from siblings like login by describing scopes and destructive effects.

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 usage guidance: 'ASK THE USER FIRST, then call with confirm: true' and explains what each scope does. It does not explicitly contrast with sibling login, but the purpose and invocation conditions are clear enough for an agent to decide when to call 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 mark readOnlyHint=true and destructiveHint=false, but the description adds substantial behavioral detail beyond that: the server caps `limit` at 50, ignores `page`, returns a `view` echo reflecting what was served, rejects unknown view members with 400, and has meaningful state semantics for `iepIev` and `foreign.isShown`. It even explains when empty results are expected. No contradiction with annotations.

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

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

The description is long, but nearly every sentence earns its place by revealing hard-won behavioral facts that are not available from the schema or annotations. It is front-loaded with the core purpose and sibling distinction, then moves into parameter semantics and timing edge cases. Slightly dense, but not 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?

For a tool with no output schema, the description is unusually complete: it covers the full `view` vocabulary, server rejection behavior, limit cap, ignored `page`, zeroed pagination block, foreign session timing, pre-opening semantics, and normal empty results. An agent has everything needed to call this tool correctly and interpret its response.

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 schema already documents both parameters. The description goes well beyond that by fixing the `view` vocabulary to eight accepted members, warning that ten IEP/IEV spellings were refused, and stating that `limit` is honored but capped at 50. It adds behaviorally important semantics like the echo behavior and the meaning of omitted `view`.

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?

Opens with a specific, unambiguous statement: it is the market-wide ranking behind Stockbit's Movers dialog. It names the sibling it is not (top_movers), explains the operational difference (hotlist vs market-wide, 9 vs 50 symbols), and closes with a direct routing instruction. No ambiguity remains about what resource this tool addresses.

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 contrasts with top_movers: 'the hotlist served NINE symbols while this served FIFTY' and states 'For a market-wide ranking, this is the one to use.' It also tells the agent when an empty list is normal, and describes the closed vocabulary of `view` values. This gives clear selection criteria versus the sibling.

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?

On top of readOnlyHint/openWorldHint annotations, the description discloses that the tool is cached for only 5 seconds and explains why staleness matters. The 'PENDING VERIFICATION' note is an unusual but valuable disclosure about reliability.

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 sentences each carry distinct information: purpose, usage, cache behavior, and confidence status. The most decision-relevant fact (what session it is) is front-loaded, and there is no redundancy.

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 parameterless status tool with no output schema, the description provides the full set of possible return states, timezone/hours, and a caution about stale values. An agent has everything it needs to decide when and how to use 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?

There are zero parameters and the schema already covers this fully; the description simply confirms 'Takes no arguments'. Per the baseline for no parameters, this is sufficient and adds no unnecessary detail.

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 leads with a precise statement of what the tool reports — the current IDX trading session among six enumerated states — and names the resource ('the IDX trading day'). This is specific enough to distinguish it from generic 'status' or 'trading_status' siblings, even without naming them.

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

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

It explicitly instructs when to call it ('BEFORE concluding that an empty movers list, a still order queue or a silent tape means something is broken') and gives operational context about WIB hours and holidays. It also warns about the 5-second cache, which tells the agent to re-call it frequently.

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 and destructiveHint false, but the description adds substantial behavioral context: this is Indonesian-language community/media content, not market data; the projection drops link/image/publisher fields so `raw` must be read; date parameters are calendar-checked; and pagination is cursor-based with nuanced `nextCursor` semantics. There is no contradiction with annotations.

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

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

The description is long but every sentence earns its place: purpose, sibling relationship, content caveats, parameter semantics, cursor pagination, and empty-result interpretation. It is front-loaded with the core purpose and routes to the correct sibling early, avoiding buried critical details.

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

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

For a tool with no output schema, the description is remarkably complete. It explains returning fields that are absent from the projection (`raw`, `source`, `nextCursor`), how to continue pagination, how to recognize a genuine zero result, and why a null cursor does not mean the stream has ended. An agent has enough context to call and interpret this 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%, yet the description still adds meaning beyond the schema: `symbol` presence controls per-symbol vs market-wide routing; omitting `limit` uses Stockbit's default page size; `from_date`/`to_date` are inclusive and calendar-validated; and `last_stream_id` is explicitly tied to the `nextCursor` returned from a prior page. The cursor behavior is far richer than the schema's one-line description.

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

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

The opening line names the resource ('news posts') and the two scopes ('market-wide or for one symbol') with a concrete verb. It explicitly relates to the sibling `stream` by stating that news is the stream with STREAM_CATEGORY_NEWS, which distinguishes it from adjacent tools.

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

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

The description gives explicit routing rules: use `news` with a symbol for per-symbol news and without one for market-wide news, and direct the agent to `stream` with a custom category for anything else. It also frames appropriate usage as sentiment/pointer content and explicitly warns against quoting prices, ratios, or earnings figures from posts.

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 critical behavioral warnings beyond the annotations: mixed share/lot units in one payload, foreign flow values lacking a session date, the 18:00 WIB publication caveat, and the per-board market_data split. This is exactly the kind of context that prevents silent wrong answers.

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 overly long and disorganized, with all-caps warnings and a typo ("also also"). While the opening sentence is sharp, the rest reads as a dense block of caveats that could have been structured more concisely for an agent to parse quickly.

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 having no output schema, the description covers the key return fields, unit hazards, board split, and the foreign-flow date trap. An agent has enough information to invoke the tool correctly and interpret the response safely.

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 already documents the only parameter, symbol, with "IDX ticker". The description repeats that this is for a symbol and mentions symbol in warnings, but adds no new syntax or semantic detail beyond the schema, so baseline 3 applies.

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

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

The first sentence, "Full order-book depth ladder for a symbol," clearly identifies the resource and content being returned. It lacks an explicit verb and does not differentiate itself from siblings like quote or price_chart, but the core purpose 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?

No explicit guidance is given for when to use this tool versus alternatives. The references to technicals, price_bands, and market_movers are warnings about unit and date discrepancies, not instructions for choosing among tools.

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

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

With readOnlyHint/openWorldHint/destructiveHint already present, the description still adds substantial behavior: the `request` echo distinguishes empty results from non-applied filters, `sideRaw` preserves raw wire values, auth is required, and field mapping was partly verified with missing values treated as not-zero. This is far beyond what annotations 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?

The description opens with the main purpose and immediately gives the critical filter instruction. The caveats and verification notes are dense but each earns its place; the final verification paragraph is longer than strictly necessary but still useful.

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 there is no output schema, the description does a strong job of explaining return semantics: statuses covered, filter echo, side vs sideRaw, readFrom mapping, and missing-value behavior. It also warns about partly verified fields and the auth requirement, so an agent has enough context to call and interpret it correctly.

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

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

The input schema already covers the only parameter `symbol` at 100%, so the description doesn't need to add much. It repeats the filter-to-one-stock behavior and implies the request echo, but that's about the response, not the parameter itself. 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 identifies the resource as current orders on the book and enumerates the statuses it covers, which makes the tool's function clear. It doesn't use an explicit verb like 'retrieve' or 'list', and it doesn't distinguish itself from the sibling 'orderbook', but the content is specific enough not to be confused with portfolio or quote 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?

It gives concrete instructions: pass `symbol` to filter, omit for all open orders, and use `sideRaw` when `side` is absent. It also states the prerequisite trading-session requirement. It does not explicitly state when to prefer this tool over siblings like `orderbook` or `position`, 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?

Going well beyond the annotations, the description explains a subtle behavioral trait: same candle shapes can be different patterns depending on prior trend. It also clarifies that `confidence` measures textbook proportionality, not probability or predictive success, and warns it is not backtested. This is valuable behavioral context that the schema and 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?

The description is dense but well-structured: a clear one-line summary is followed by the most important interpretive caveat, then the confidence semantics. Every sentence earns its place, and the most actionable guidance is front-loaded.

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 8 parameters, no output schema, and a nuanced detection model, the description covers the key decisions an agent needs: what patterns are, how context affects them, what confidence means, and where to go for predictive analysis. It does not describe the full output shape or enumerate the 16 pattern IDs, which would make it fully 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 coverage is high at 75%, and the description adds meaningful semantics for `ignore_context` by explaining that it shows raw shapes regardless of prior trend. It also clarifies what `confidence` means, which relates to `min_confidence`. However, the description does not add detail for the undocumented `to` and `from` date parameters, or explain how `bars` and `since` interact.

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 the tool's function: detecting candlestick patterns on an IDX stock's daily bars, listing 16 classic formations and the prior trend used for interpretation. It differentiates itself from the sibling `backtest` by explicitly stating that pattern confidence is not predictive and that predictive questions should go to `backtest`.

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 strong usage context: it explains how prior trend affects pattern meaning, how to override it with `ignore_context`, and explicitly directs users to `backtest` when they care about forward-looking performance. It does not enumerate all alternative sibling tools or state when not to use this tool versus technicals, 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, but the description adds substantial behavioral detail: summary-request failure produces `totalsUnavailable` rather than an unreadable portfolio, 1 lot = 100 shares, `derived` values are computed arithmetic, the trading session is required, and field-mapping status is disclosed with `readFrom`. No contradiction with annotations.

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

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

The description is dense but every sentence earns its place: purpose, use case, failure semantics, unit conventions, authentication requirement, and data provenance. It is front-loaded with the crucial watchlist distinction and does not waste words on annotation 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?

Even without an output schema, the description covers return semantics (holdings, totals, `totalsUnavailable`, `derived`, `readFrom`), failure behavior, units, authentication, and data verification status. An agent has enough to invoke the tool and interpret its 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?

The tool has zero parameters and the input schema is empty, so there is no parameter-semantics burden for the description to carry. The baseline of 4 applies; the description instead adds useful context about output fields and failure behavior.

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 the tool as returning the user's actual stock holdings at Stockbit Sekuritas, including average price and current value. It explicitly distinguishes itself from `watchlist` as account vs. list, eliminating ambiguity among siblings.

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: read before any opinion touching position sizing, concentration, or adding to a position. It also names `watchlist` as the alternative and explains why it is not the same, satisfying the when/not/alternative expectation.

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

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

Annotations already mark it read-only, non-destructive, and open-world. The description adds real value beyond that: `holding: null` is a normal response, a login session is required, and field mapping is only partly verified with `readFrom` naming actual mapped fields. No contradiction with annotations.

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

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

The description is front-loaded with the core purpose, then covers the critical null case, the auth requirement, and data reliability caveats. Each sentence adds actionable information, and the structure follows the natural decision order for an agent.

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

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

For a one-parameter, read-only position lookup with no output schema, this description is thorough: it explains the main result fields, the special `null` case, the required session, and the reliability of the mapped data. An agent has enough context to call it correctly and interpret a normal null result.

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

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

The single parameter is fully described in the schema (`IDX ticker, e.g. BBRI`) with 100% coverage, so the description does not need to add parameter details. It adds the context that the symbol is a single holding lookup, but that does not go beyond the schema's baseline.

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 exactly what the tool returns for one symbol — quantity held, average price, and current value — and explicitly contrasts it with the sibling `portfolio`, calling out when it is cheaper. An agent can tell this apart from `portfolio` and other market 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?

It gives a clear selection rule: use this instead of `portfolio` when the question is about a single stock, and it notes the session prerequisite. It does not explicitly spell out when not to use it, but the single-symbol framing plus the sibling comparison provides sufficient 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?

Even though annotations already declare readOnlyHint=true and destructiveHint=false, the description adds substantial behavioral context: it has no side effects, performs no account reads, floors lot sizes, checks the IDX price grid, rejects off-grid limits, and does not place orders. It also discloses commission defaults and the `feeSource` behavior. This far exceeds the baseline set by the annotations.

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

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

The description is front-loaded with the core purpose and remains information-dense without redundancy. Each sentence contributes a distinct constraint, default, return value, or routing instruction. Given the 10-parameter complexity and absent output schema, the length is justified and well-organized.

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 return contents: position value, actual risk after flooring, round-trip commission, break-even price, and 1R/2R/3R targets. It also covers prerequisites, parameter relationships, grid-check behavior, fee defaults, and the boundary between planning and permission. 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 coverage is 100%, so the baseline would be 3, but the description meaningfully enhances parameter understanding. It explains the mutual exclusivity of `risk_idr` versus `account_idr` + `risk_pct`, the requirement that `stop_price` be below `entry_price`, the flooring behavior of lot sizes, the source of `ara`/`arb` from `price_bands`, and the default/override semantics of fee parameters. This goes well beyond the raw schema 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 opens with a specific, actionable statement: 'How many lots to buy, given what you are willing to lose.' It clearly identifies the tool as pure arithmetic that 'reads no account, checks no buying power, and places nothing,' and differentiates it from order execution by naming `order_preview` as the real-check alternative. This is a clear verb+resource pairing that distinguishes it from siblings.

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 when-to-use and when-not-to-use guidance: 'This is a plan, not a permission. Use `order_preview` for the real checks — buying power, tradability, and the caps in the trading policy.' It also explains the conditional parameter paths (`risk_idr` OR `account_idr` + `risk_pct`) and points to `price_bands` and `trading_info` for required inputs, leaving no ambiguity about how to select and 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?

Beyond the readOnlyHint/openWorldHint annotations, the description discloses important behavior: missing fields are reported as null and named in `missing`, never as zero, because zero is a real value for foreign net flow. It also explains the semantic meaning of ARA and ARB, which helps an agent interpret results correctly. This is exactly the kind of nuance 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 compact sentences: the definition comes first, an illustrative ARA/ARB interpretatoin sentence second, and the null-vs-zero caveat last. Every sentence earns its place and there is no filler.

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

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

For a one-parameter, read-only tool with full schema coverage, the description is largely complete and explains the key behavioral gotchas. It could be slightly more explicit about the exact response shape, but it discloses the most important missing-field behavior and where the data comes from.

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 already documents the single `symbol` parameter as 'IDX ticker, e.g. BBRI' with 100% coverage, so the baseline of 3 applies. The description adds no extra parameter-level detail beyond reinforcing that the data is per-stock.

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 the resource: IDX ARA/ARB auto-rejection bands plus the session's foreign flow for a stock. It is specific and meaningful, but it lacks an explicit action verb like 'get' or 'retrieve'. It also only indirectly distinguishes itself from the orderbook sibling by noting the data comes from the orderbook response.

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

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

The description gives clear context: use this tool to access ARA/ARB and foreign flow data for a stock, and notes that these fields already arrive inside the orderbook response at no extra request cost. It does not explicitly state when to prefer price_bands over orderbook or list exclusions, but the context is still strong.

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

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

Annotations provide readOnlyHint, openWorldHint, and destructiveHint, and the description adds substantial beyond-annotation context: the tool always writes a .svg and reports savedTo, opens a browser by default, draws only on this render without writing to the Stockbit account, and reports annotationsDrawn/annotationsNotDrawn rather than silently dropping input. This is far more transparent than the annotations 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?

The description is long but dense and front-loaded: purpose first, then usage routing, then side effects and result semantics. Every sentence conveys useful operational information, though a shorter version could integrate the annotation-counting explanation more tightly.

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

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

For a tool with 13 parameters and no output schema, the description covers the key missing context: SVG output, savedTo reporting, local file side effect, browser-opening behavior, auto-detected levels versus user annotations, and failure reporting. An agent has enough to call it correctly and interpret the result.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by clarifying the roles of `annotations`, `show_levels`/`autoLevels`, and `open_in_stockbit`, and by explaining how annotation failures surface in the result. It does not redundantly re-list every property, so it earns above baseline.

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

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

The description opens with a precise verb and resource: 'Candlestick chart for an IDX stock, ALWAYS rendered as an SVG.' It clearly distinguishes itself from siblings by saying 'Use `technicals` for the numbers; this is the picture,' which lets an agent pick the right tool without inferring from 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 description explicitly names the main alternative ('Use `technicals` for the numbers; this is the picture') and gives concrete guidance on when to use annotations for user-drawn evidence. It also explains the open_in_stockbit behavior so the agent can decide whether to suppress that side effect.

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 and destructiveHint=false, so the safety profile is established. The description adds useful behavioral detail by specifying the output components and the side-effect-free resolution of an internal company id, which is beyond what annotations 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?

Two concise sentences with no filler. The primary purpose is front-loaded, and the secondary behavior (internal company id resolution) is appended as a short, useful note.

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 one required parameter, no output schema, and simple read-only behavior. The description lists the key returned fields and the extra resolution behavior, which is enough for an agent to call it correctly. It does not discuss error cases or invalid symbols, but these are not critical for a low-risk quote endpoint.

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 provides 100% coverage for the single required symbol parameter, including an example ('BBRI') and the IDX/index distinction. The description itself does not add much parameter-level detail, but the schema carries that weight adequately.

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 provides a real-time quote for an IDX symbol, listing exactly what is returned: last price, change, and best bid/offer. It also mentions the additional behavior of resolving the symbol's internal company id. This differentiates it from siblings like orderbook or price_chart.

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

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

The description gives clear usage context: use this when a current quote snapshot for an IDX symbol is needed. It implies this is not the tool for order depth, historical charts, or fundamentals, though it does not explicitly name alternatives or 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 declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description only restates the output concept ('financial ratios') without adding behavioral context such as the ratio categories covered, data source, time period, or how open-world results are organized.

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 five words and front-loads the essential concept immediately. Every word 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 should explain what the agent will receive; it does not. There is no mention of the ratio set, formatting, or any caveats, leaving an agent to discover the output contract only after 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 the symbol parameter is documented as 'IDX ticker', so an agent knows what value to supply. The description adds no extra parameter context, but none is necessary given the complete schema.

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

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

The description states the resource ('financial ratios') and the subject ('a company'), so an agent can broadly infer it returns ratio data for a ticker. However, it has no explicit verb like 'calculates' or 'retrieves', and it doesn't clearly differentiate from siblings such as financials or keystats beyond the word 'ratios'.

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

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

No guidance is given about when to choose ratios over financials, technicals, keystats, or quote. There are no exclusions, prerequisites, or conditions, so the agent must guess which tool fulfills a ratio-related request.

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?

Even with annotations already declaring readOnlyHint, the description adds substantial behavioral context: rate limits, timing estimates, six-hour bar caching, timeout risks when max_symbols is raised, result miss categories, data-absence semantics for volume, and truncation reporting. This is exactly the kind of operational detail that prevents an agent from misinterpreting scan output or misconfiguring a costly sweep.

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 front-loaded with the core purpose, then organized into clear cost and result-semantics paragraphs. Every sentence earns its place by warning about timeout risk, caching behavior, miss interpretation, or truncation — all critical for correct invocation.

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

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

For a complex 11-parameter tool with no output schema, the description supplies what an agent most needs to call it correctly: universe selection hint, cost and timeout ceilings, caching guidance, data-availability caveats, and explicit miss/truncation semantics. Combined with the rich input schema, this is sufficiently complete for safe and effective 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 already 73%, but the description adds meaning beyond the schema: max_symbols is tied to a concrete timeout/cost ceiling, overlays like sma200 carry disproportionate cost, and left/right are illustrated with examples like close and sma20. The description does not add much for op, panels, or overlays beyond the schema enums, so it does not fully close every parameter 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 opens with a specific action and resource: 'Run a condition across many IDX stocks at once.' It also distinguishes the tool from alert_check by framing scan as 'alert_check for stocks you have no rules for,' giving an agent an immediate way to separate it from a key sibling.

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 positions scan relative to alert_check and gives operational guidance: sweep broadly once, then iterate because of caching. It also notes that the watchlist universe is 'usually the one you want.' However, it does not explicitly contrast scan with other sibling screening tools like screener or technicals, so it stops short of full exclusion guidance.

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

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

Annotations already mark the tool as read-only and non-destructive, and the description reinforces this by stating 'Running a screen is a read: nothing is created, edited or saved.' It also adds useful context about the IDX-specific metric catalogue and notes that the `catalogue` payload is large. No contradiction with annotations.

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

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

The description is front-loaded with purpose and usage, followed by read-only behavior and mode pointers. It is about five sentences and includes a slightly promotional TradingView comparison that does not directly aid invocation, but the rest of the content 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 6-parameter tool with no output schema, the description covers the core modes: list, run, `catalogue`, and `presets`, and describes the return concept as 'matching stocks with their metric values.' It does not detail pagination, `limit` semantics, or combined-mode behavior, but the schema fills parameter details and annotations cover safety.

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 each parameter is already documented. The description adds a usage pattern connecting `template_id` and `type`, and mentions that omitting `template_id` lists screens, but this largely mirrors the schema text rather than adding new semantic meaning.

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 the tool as Stockbit's stock screener and states two concrete operations: listing saved screens and running one to get matching stocks with metric values. It does not explicitly distinguish this tool from sibling tools like `scan` or `watchlist`, so it falls just short of a top score.

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 calling patterns: no arguments to list saved screens; pass `template_id` and matching `type` to run one; use `catalogue` to see what can be screened on; use `presets` for built-in screens. It lacks direct when-not-to-use guidance relative to sibling tools, but the mode-based guidance is clear and 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?

Beyond the readOnly/openWorld annotations, the description reveals non-obvious behavior: the endpoint rejects requests without a year, back_year's meaning is unknown and passed through unchanged, and the response shape is unverified. It also clarifies that empty or null data means Stockbit has no series, not an error or a zero value.

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 longer than average, but it is dense with important warnings and caveats. The core purpose is front-loaded, and each paragraph addresses a distinct operational concern. It could be tightened slightly, but the length is justified by the amount of non-obvious context.

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 explicitly states that the response shape is unverified, tells the agent to read field names from the raw data, and explains how to interpret empty/null data. Combined with the year and back_year guidance, the agent has everything needed to call and interpret this 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?

While the schema already documents all parameters, the description adds decisive semantics: year is the end of the ten-year lookback, not a count; omitting it sends the current year; back_year must not be interpreted as meaningful; and data is returned raw without renaming. These caveats materially change how an agent should set and interpret 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 first sentence clearly defines the tool's purpose: month-by-month seasonal price behavior for one IDX stock across a fixed ten-year lookback. It also explicitly disclaims being a forecast, which helps set expectations. However, it never names or contrasts sibling tools like technicals or patterns, 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?

The description gives clear context: use this when you need calendar-month seasonal price behavior for one IDX stock. It also provides useful exclusions, such as 'not a forecast' and 'says nothing about why a month was strong.' It lacks explicit 'use instead of X' routing to sibling tools, so it does not fully earn 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 description goes far beyond the readOnly/destructive annotations by explaining the health state machine, that failing means present-but-rejected by Stockbit, that live:true rotates the token family and ends the user's website session, and that absent server.update fields mean unknown rather than current. No annotation contradiction: the annotations describe the default read-only path, and the description explicitly qualifies the live option.

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 long but densely packed. Each paragraph covers one distinct behavior or caveat, front-loads the primary call guidance, and uses structured markers like live:true, server.update, and STOCKBIT_NO_UPDATE_CHECK. Nothing reads as 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?

Without an output schema, the description compensates by naming the returned blocks — sessions, health, market, server.update, nextStep — and explaining failure semantics, side effects, and environmental controls. An agent has enough to invoke status correctly and interpret the answer.

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

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

The single parameter is already fully documented in the schema, including default value, side effects, and the ask-first caveat. The description reinforces the usage guidance but mostly repeats the schema's live/health trade-off, so it adds little new parameter-level meaning.

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 opening question defines the tool as a health/readiness diagnostic, and the second sentence lists exactly what it reports: version, Node, session storage, token lease, trading mode, IDX clock, and nextStep. It also distinguishes itself from siblings by naming market_session as the tool for public-holiday handling.

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 says to call this FIRST whenever anything looks wrong and after login to confirm it took. It also gives clear when-not guidance: prefer health over live:true, only pass live:true with explicit user request, and delegate public-holiday logic to market_session. This is ideal 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 state readOnlyHint=true and destructiveHint=false, and the description adds valuable non-obvious behavior: bars are fetched once for all nine strategies so cost equals a single backtest, and results are ranked above buy-and-hold rather than by raw return. It also warns that picking the winner on one window is a selection, not a finding. No contradiction with annotations.

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

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

The description is three focused sentences, each earning its place: the action/cost, the ranking rationale, and the selection-bias warning. It is front-loaded with the primary behavior and contains 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?

The core contract is well covered: what it runs, what it costs, how it ranks, and what to do next. However, there is no output schema and the description does not specify the result structure beyond 'rank them,' so an agent cannot know exactly what fields to expect. For an 8-parameter tool this is mostly but not fully 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?

The description reinforces the meaning of `strategies` ('all nine' by default) and explains that costs like stop-loss/take-profit are included in the ranking metric. However, it does not clarify `to`/`from` formats, `initial_capital`, or `stop_loss_pct` defaults. With schema coverage at 50%, the missing parameter semantics are only partially compensated.

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: 'Run every built-in strategy over ONE stock's history and rank them.' It clearly differentiates from the sibling `backtest` tool by framing strategy_compare as a comparison/screening tool, and the closing caveat about selection vs. finding reinforces its distinct role.

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

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

The description explicitly tells the agent when to take the result seriously: 'Run `backtest` with walk_forward on the winner before believing it.' It also explains that the ranking is by excess return over buy-and-hold, not raw return, which prevents misuse on rising windows. This gives clear selection and follow-up guidance relative to `backtest`.

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

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

Annotations already mark this read-only and non-destructive, and the description goes far beyond them: category is sent verbatim, report_type is ignored for non-report categories, date validation fails loudly, the cursor has specific semantics with nextCursor null meaning the walk cannot continue, and empty items with non-null source is a genuine zero not a retry trigger. This is exceptional behavioral disclosure.

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 long but densely informative; every sentence covers a distinct behavior or constraint. It is well-organized by topic: content type, category semantics, report_type behavior, date handling, and paging. The most important caveat (not market data) is front-loaded.

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

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

This is a high-complexity 10-parameter tool with no output schema, so the description carries the full burden for response semantics. It extensively explains paging, cursor behavior, empty results, and the meaning of nextCursor. Given the complexity, 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 coverage is 100%, so the baseline is 3, but the description adds substantial meaning: it maps category enum values to UI tabs, explains watchlist_ids come from watchlist tools and are numeric, states date format and validation failure behavior, and documents the cursor relationship between last_stream_id and nextCursor. This far exceeds what the schema alone provides.

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

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

The description states a specific verb and resource: it posts from Stockbit's social stream with concrete content examples (news, trading ideas, reports, charts, polls, predictions). It clearly distinguishes this from market data tools by warning it is community/media-written text, not market data. The symbol/no-symbol distinction further clarifies the two main modes exactly.

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 usage guidance: use for sentiment and source pointers, never for quoting prices/ratios/earnings. It explains when to omit vs provide a symbol, how category selects tabs, and how report_type applies only to reports. This is actionable enough for an agent to choose and invoke it correctly.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, but the description adds substantial behavioral context beyond that: data is computed from daily bars, readings are the latest defined value of each series, upstream paging happens 12 sessions at a time, and pagesFetched reports query cost. No contradiction exists between description and 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 tightly packed sentences with no filler: the first defines scope and indicators, the second gives usage guidance and return semantics, and the third covers performance and output metadata. It is appropriately sized and front-loaded with the most important 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 4-parameter read-only tool with no output schema, the description covers the essential selection criteria, return nature ('latest defined value', 'Returns NUMBERS'), and cost signal (pagesFetched). It is slightly light on the exact response envelope, but the schema and annotations cover the invocation side well, making this sufficient for correct 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?

Schema description coverage is 100%, so the baseline is 3. The description adds meaningful semantics around bars by explaining the pagination behavior and performance cost, which complements the schema's note that bars is ignored when from is given. It does not deeply elaborate to/from beyond schema, but the schema already documents those well.

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-resource pair ('Technical indicator readings for an IDX stock'), enumerates the exact indicators (SMA/EMA, RSI, MACD, Bollinger Bands, ATR, support/resistance), and explicitly contrasts itself with price_chart. An agent can immediately tell what this tool computes and how it differs from visual charting.

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 usage guidance: use it when you need numbers for reasoning versus price_chart for a picture. It also warns that deep history is paged and a large bars value is slow, helping agents decide on parameter magnitude. This is strong when-to-use and when-not-to-use guidance.

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

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

The description goes far beyond the annotations, disclosing data provenance (daily source, resampled weekly/monthly), absence of 4H/1H/15m and intraday OHLC, the ~500-session reach, and why monthly RSI(14) becomes null. It also directs the agent to read the `limits` field, making failure behavior explicit. No contradiction with annotations.

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

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

The description is dense but each sentence carries material data-availability information; there is no filler. It front-loads the core purpose, though the four sentences could be tightened slightly 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 read-only analysis tool with a 2-parameter schema and no output schema, this description covers almost everything an agent needs: input semantics, data limitations, null behavior, and the `limits` field. It stops short of describing the overall response shape, but the stated outcome is sufficient for selection.

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; the description adds useful semantics beyond the schema by explaining that `bars` folds daily sessions and that monthly needs all of them (500). It also introduces `limits` as an output field, giving the agent context on what the parameters affect.

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 by framing the tool's purpose as determining whether daily, weekly and monthly views of a stock agree and what each timeframe can support. This is specific to a resource and distinct in intent from sibling price/indicator tools, though it lacks an explicit imperative verb like 'compute' or 'return' and does not name sibling differentiations.

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 conveys implied usage: use it when time-frame agreement and data support matter, because it clarifies that weekly/monthly are resampled and intraday is unavailable. However, it does not explicitly state when to prefer this tool over siblings like technicals, price_chart, or quote, nor give 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?

Beyond the readOnly/openWorld/destructive annotations, the description discloses important behavior: the service ignores limit, always returns the same nine-symbol universe, returns an empty list when the market is closed, and is not buggy despite appearing so. This is rich, non-obvious context that materially changes how an agent should interpret results.

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 and logically organized, but it is longer than needed. The empirical measurement narrative and bug-report digression could be condensed into a few crisp statements without losing the critical warnings.

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

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

For a tool with no output schema, the description covers the main behavioral risks: limited universe, ignored limit, empty response on closed market, and sibling expectations. It stops short of describing the exact return row structure, but the mention of nine symbols and descending changes gives enough context for correct 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?

The schema already documents both parameters, including that limit is ignored. The description adds further semantic weight by explaining that every tested limit value still returned the same nine symbols, making the ignored-limit behavior concrete and hard to miss. It does not add much about the type parameter, but the schema covers it well.

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 the resource as "Stockbit's HOTLIST" and immediately signals it is NOT a market-wide ranking, naming market_movers as the alternative. However, it never explicitly states an action like "returns top gainers/losers/most active," relying partly on the tool name and schema enum for that detail.

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 usage guidance: "Use market_movers for the market-wide one." It also tells the agent when an empty list is expected, explains why disagreement with market_movers is normal, and warns against interpreting the hotlist as exchange-wide movers.

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 and destructiveHint=false. The description adds value by specifying that the tool is an offline configuration read, does not validate the session, and that real-money execution is permanently unavailable. These details go beyond the structured 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?

The description is three sentences with no redundancy. The primary purpose is front-loaded, followed by a key caveat and a clarifying note. Every sentence contributes essential information, making it a model of concision.

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 parameterless, read-only tool with no output schema, the description conveys the essential semantic content: what the tool reports (paper-simulation policy and session presence), that it is offline, and that it does not validate the session. It leaves minimal ambiguity for an agent deciding to call it, though it could potentially mention the return format.

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 zero parameters, so schema coverage is vacuously 100%. The baseline for 0 parameters is 4, and the description appropriately does not attempt to explain parameters. It adds meaning by describing what the tool reads, which is sufficient in the absence of 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 the resource as 'Local paper-simulation policy and securities session presence' and clarifies it is an offline configuration read. It clearly indicates what information the tool provides and distinguishes it from real-money trading, though it lacks an explicit action verb like 'returns' or 'gets'.

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 usage context: it is for local paper-simulation status, not real-money execution, and it does not validate sessions. However, it does not explicitly name sibling alternatives or state when to prefer this tool over others like 'status' or 'market_session', leaving the routing partially 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 mark the tool as read-only and not destructive, and the description adds significant behavioral context: volume is reported in shares rather than lots, and the `volumeShares` field name prevents accidental comparison with daily-bar volume. It also discloses the dual-mode behavior of listing versus reading contents, going well 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 every sentence earns its place: it states the resource, gives the two call modes, mentions the direct alternative, and adds a units warning that prevents a real comparison pitfall. The information is front-loaded and well organized.

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 small parameter surface, no required parameters, and read-only annotations, the description covers everything needed for correct invocation. It explains the output domain (watchlists and their symbols), the volume units caveat, and the relationship to `scan`; there are no significant missing behavioral or return-value details.

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. The description clarifies that omitting `id` lists watchlists and passing it reads contents, but this is largely already present in the schema's id property description. The `limit` parameter is left entirely to the schema, so the description adds no meaningful new 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 clearly identifies the resource (the user's own Stockbit watchlists and the symbols in one) and states the action: with no arguments it lists watchlists, and with `id` it reads a list's contents. This is specific enough to distinguish the tool from siblings like `portfolio`, `position`, and `scan`.

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 call patterns: no arguments to list, `id` to read contents. It also names the direct alternative, `scan`, and explains when that is relevant by saying it can sweep the watchlist universe with universe=watchlist, which helps an agent choose between the two tools.

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

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

Annotations already declare readOnlyHint=true/destructiveHint=false, so the read-only safety profile is covered. The description adds useful domain context (workflows are fixed multi-step routines) but does not clarify other behaviors such as whether output is exhaustive or whether listing workflows has any side effects.

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: the first names exactly what is returned, the second explains the concept and when to use it. There is no filler or repeated schema/annotation content.

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 list tool the description is nearly complete: it states the output and intended use case. It could be slightly stronger by pointing to workflow_run as the execution companion, but that is a minor 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?

The tool takes zero parameters and the schema confirms this, so no parameter detail is needed. The description's mention of output ('what each one needs') is the only relevant input/output guidance and is sufficient.

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: 'List the saved multi-step workflows and what each one needs.' It also contrasts with single-reading tools, which prevents confusion with the many single-purpose siblings like quote or technicals.

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

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

It explicitly states when to use it: 'use it when the user wants a routine ... rather than a single reading.' It does not name workflow_run as the execution alternative, but the workflow-run explanation makes the intended context clear.

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

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

The description richly discloses behavior beyond the annotations: it returns each step's output in order with timing, aborts on a failing step unless the step is optional, records optional-step errors and continues, and reports skipped items in capped fan-out scenarios. This is far beyond the minimal readOnlyHint/destructiveHint 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?

All four sentences earn their place: the first defines the tool, the second explains return behavior and failure semantics, the third clarifies fan-out behavior, and the fourth gives a usage prerequisite. The most critical information is front-loaded.

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 present, the description carries the burden of explaining the return shape, which it does clearly: step outputs in order, timing, failure details, and skipped-item counts. Combined with the annotation safety profile and complete parameter schemas, an agent has enough to invoke it correctly.

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

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

Schema coverage is 100% with clear examples for both 'name' and 'input', so the baseline is 3. The description adds value by directing the agent to pull the name from workflow_list and framing 'input' as the workflow's required inputs, which explains the meaning of the nested object beyond the schema's generic example.

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

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

The description opens with 'Run a saved workflow by name,' a specific verb and resource, and distinguishes itself from sibling workflow_list by noting it bundles several tools into one call. An agent can immediately tell this executes a workflow rather than listing workflows.

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 instructs the agent to 'Use workflow_list first to see names and required inputs,' giving a clear prerequisite and sequencing. It does not go as far as stating explicit alternatives or when not to use the tool, but the context is clear that this is for running a pre-defined multi-step workflow.

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