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

Annotations already declare destructive/openWorld/non-idempotent, and the description adds real value on top: fully local execution, no API key, Docker image override, report offloading to report_path when too large, and a warnings mechanism when the lot grid is unknown. It does not contradict openWorldHint=true since it discloses the Binance exchangeInfo lookup. Slightly short of 5 only because it never states failure/timeout or resource expectations.

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

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

Front-loaded with purpose and preferred usage, but the instrument/lot-size paragraph is very long and largely restates what the `symbol` schema property already says verbatim, so the description carries duplication. Dense and useful, yet not every sentence earns its place.

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

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

For a 10-parameter tool with nested objects and no output schema, the description does enumerate the return payload (summary, trades, applied_inputs, applied_overrides, applied_runtime, elapsed_seconds) and explains the offload behavior and warnings. That covers most of what an agent needs, though the enumerated report fields are not typed and richer return detail would help.

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 cross-parameter precedence semantics the schema does not: syminfo wins over symbol, symbol wins over the CSV sidecar, and inputs keys are the second argument of input.*() calls. That resolution logic is genuinely useful beyond the per-field schema text.

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

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

States a specific verb and resource ('Run a real, deterministic backtest of a PineScript v6 strategy') and immediately distinguishes itself from its closest sibling by naming backtest_pine_grid for sweeps. An agent can separate this from transpile_pine or the grid variant without opening any schema.

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

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

Explicitly says to prefer this over estimating P&L by reasoning, lists concrete triggering requests ('backtest this Pine', 'is this strategy profitable', 'reproduce my TradingView results'), and routes sweeps to backtest_pine_grid. Both the when-to-use and the alternative are stated.

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

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

Annotations already declare destructive/non-idempotent/open-world, so the bar is lower; the description still adds real context beyond them: transpiles Pine once, compiles C++ and backtests per combination, spawns docker containers with per-container startup overhead, applies a hard max_combinations cap, and offloads oversized sweeps to report_path. It never explains why the tool is flagged destructive (arbitrary container execution) or what failure modes look like, which keeps it off a 5.

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

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

Front-loads the when-to-use clause and then the mechanics, so the most decision-relevant content comes first. However, the instrument/lot-size passage (TradingView vs Binance step, 90.6%/97.5% statistics) is verbose and duplicates the schema's symbol description, costing it a point on economy.

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

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

For a 16-parameter, nested-object tool with no output schema, the description covers the return shape (ranked {inputs, overrides, summary, elapsed_seconds} plus best), the sort_by ordering, the report_path offload path, and the instrument-resolution behavior. Nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description clarifies the grid semantics (cartesian product of inputs x overrides, instrument applied to every combination) and the max_combinations default, but the long lot-size/instrument paragraph is largely verbatim duplication of the `symbol` schema description rather than added 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?

Names a specific operation (run a parameter sweep over PineScript inputs/overrides) and explicitly contrasts itself with the sibling backtest_pine for single-configuration runs. An agent can distinguish it from every other sibling without reading either schema.

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

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

Opens with an explicit trigger ('when the user wants to optimize, sweep, tune, or compare...'), names the exclusion ('rather than test a single configuration'), and routes to the alternative ('for one fixed configuration use backtest_pine'). Also gives operational guidance (concurrency 2-4 is usually plenty) and points to list_engine_params via the schema for the override catalog.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely useful operational context: results are cached 5 minutes in-process and the call is free, which tells the agent about latency and rate-limit risk that 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?

Front-loaded with purpose, then filters, then caching/cost note in a tight two-sentence block. The filter enumeration is somewhat duplicative of the schema but stays short and readable.

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 say what a result row contains (symbol, base/quote asset, status, market) and it does not; it also omits the 'limit' parameter and its default of 200. Caching and cost are covered, but the return shape is left unspecified.

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 every filter (query, quote_asset, base_asset, status, contract_type) is already documented in the schema, and the description largely repeats those examples. It adds no new semantics such as matching rules beyond substring, or the meaning of the required 'market' param relative to 'contract_type'.

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

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

States a specific verb and resource ('List/validate symbols') plus the scope ('Binance public API') and the downstream purpose ('for OHLCV fetching'), which ties it to the sibling fetch_binance_ohlcv. It does not explicitly name a sibling it excludes, but the intent is unambiguous.

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 'for OHLCV fetching' implies this is the lookup step before fetching candles, and 'contract_type (futures only)' hints at a market precondition. There is no explicit when-to-use statement, no when-not, and no alternative tool named.

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

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

Annotations declare the safety profile (openWorld, idempotent, non-readOnly), so the bar is lower, and the description still adds real substance: the exact lookup mechanism, that no layers are downloaded, and that auto_pull triggers docker pull inline. It doesn't cover auth requirements or rate limits, but the mutation semantics behind readOnlyHint=false are explained.

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

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

Front-loaded with the core purpose and the method, then escalation behavior, then the disambiguating note about MCP version independence. Dense and mostly waste-free, though the version note lengthens it without being strictly required to invoke the tool.

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

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

With no output schema, the description compensates by naming the return fields (up_to_date + recommend_pull) and explaining the side effects of auto_pull. The independence note removes a genuine ambiguity about what 'up to date' covers, so an agent has everything needed to call it correctly.

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

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

Schema description coverage is 100% and both parameters are already documented in the schema, including the image default and auto_pull semantics. The description largely restates that behavior rather than adding new syntax or format guidance, 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?

States a specific verb+resource ('check whether the local pineforge-release Docker image is up to date with the registry') and explicitly scopes the comparison method (per-platform manifest digests, no layer downloads). An agent can distinguish this from pull_engine_image and from MCP-version concerns without opening the schema.

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

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

Gives clear context for when to call it (staleness check) and describes the auto_pull=true escalation path. It does not explicitly name pull_engine_image as the alternative for a pure pull, so the routing guidance is implicit rather than stated.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive). The description adds substantial behavioral detail beyond that: the resolution order (exact, longest prefix, alias), the return shape and status vocabulary, and the semantics of via_transpiler vs unsupported. It doesn't discuss rate limits or latency, but for a local lookup those are moot.

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

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

Front-loads the core question, then the two usage scenarios, then matching/return details. Dense but every clause carries content. Slightly long, with the long parenthetical enumerations making it a touch harder to scan.

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

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

For a single-param, no-output-schema lookup tool, the description covers purpose, timing, matching algorithm, and full status vocabulary including the via_transpiler/unsupported boundary. An agent has everything needed to call it and interpret results.

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

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

Schema coverage is 100% and the schema already documents the single 'feature' parameter with its own examples. The description restates the input domain (identifier or namespace) and supplies the resolution matching rules, which adds meaning beyond the schema. Baseline is 3, raised to 4 for the matching 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?

States a precise question it answers ('does PineForge support X?') for a specific input type (Pine v6 identifier or namespace) with concrete examples. Clearly distinguishable from siblings like transpile_pine or check_tradingview_parity.

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

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

Gives two explicit when-to-use scenarios: (a) before relying on an unsure function, (b) to diagnose a compiled-but-wrong backtest. Also implicitly routes away from engine-running siblings by noting it runs locally with no engine run.

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

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

Annotations only declare the safety profile (readOnly, idempotent, non-destructive, openWorld); the description adds substantial behavior on top: bar-fetch limits (100,000 bars), no quota/history window, the magnifier rule counting 1-minute bars in that limit, an error when an explicit input disagrees with an XLSX Properties value, warning semantics for a missing lot size, lot/tick-size resolution order, and that the run uses the pineforge-release Docker image with no network. This is far beyond what the 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?

Purpose and required inputs are front-loaded, which is good, but the body devolves into a single dense paragraph of semicolon-joined clauses covering lot size, tick size, table fallbacks, and magnifier edge cases. Much of this is edge-case detail that is hard to parse and dilutes the call-critical guidance.

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

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

For a 16-parameter tool with no output schema, the description still enumerates the return payload (tier, each check with value/thresholds, matched/unmatched counts, first mismatches with hints, timezone check, applied_instrument, warnings), so an agent knows what comes back. Nothing essential for a 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 cross-parameter semantics the schema does not: syminfo overrides everything ('syminfo gives your own values and goes over all of it'), magnifier bars are counted in the same limit, and a magnifier-declaring script run without magnifier bars warns. It also clarifies the XLSX-vs-explicit-input conflict.

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 gives a specific verb+resource+scope: 'Check how closely PineForge reproduces a TradingView backtest, trade by trade.' This is clearly distinct from backtest_pine (which runs a backtest) and transpile_pine (which converts code), so the agent can route without opening a schema.

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

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

It states the required shape of the request (a Pine v6 script plus a TradingView 'List of trades' CSV or base64 XLSX) and routes the bar-source choice ('pass ohlcv_csv or ohlcv_csv_path for any market; without them, BINANCE:<SYMBOL> ...'). However it never explicitly contrasts itself with aligned siblings like backtest_pine or states when not to use it, so it stops short of full when/when-not guidance.

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

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

Annotations declare a destructive, non-idempotent write, and the description richly corroborates that: it writes a CSV, creates a side-car <output_path>.instrument.json, paginates requests above 1000 bars, and enforces that output must live inside the MCP cwd unless PINEFORGE_ALLOW_ANYWHERE=1. These are side-effect and constraint details the annotations cannot convey.

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

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

It is dense and information-rich rather than padded, front-loading the core action and output format before the instrument-file and path details. The instrument.json sentence is long and parenthetical, which slightly hurts scanability, but every sentence carries real information.

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

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

With no output schema, the description carries the return burden and does note that the result's `instrument` field reports what was recorded. Combined with the CSV format and path constraints, it is nearly complete, though it could say more about error behavior on invalid symbols or ranges.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds real meaning beyond the schema: the CSV header layout, timestamp = open time in UNIX ms UTC, pagination above 1000 bars, and the cwd constraint on output_path. It stops short of explaining how start_time and end_time interact beyond what the schema already says.

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 (fetch) and resource (OHLCV candles from Binance) and its output (a backtest-ready CSV), and it clearly distinguishes itself from siblings like binance_symbols (used to validate) and backtest_pine/backtest_pine_grid (which consume the recorded instrument). An agent can route to it without opening another schema.

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

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

Usage context is clear: it feeds backtesting tools, and binance_symbols is named in the schema for symbol validation. It doesn't explicitly state when-not to use it or name alternatives to fetch data, so it falls just short of full routing guidance.

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

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

Annotations already declare readOnly/idempotent/non-destructive/no-open-world, so safety is covered. The description adds behavior beyond that: unknown ids return an error marker listing valid ids, and the operation is local, free, and runs no engine. It does not describe result size or pagination, but for a small lookup that is a minor gap.

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

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

Front-loads the return shape, then usage, then edge-case behavior, with no filler sentences. It is a dense single paragraph rather than being broken up, but every clause carries information.

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

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

With no output schema, the description compensates by spelling out exactly which arrays come back (supported, partial, via_transpiler, unsupported) and how errors surface. Combined with usage triggers and cost/runtime notes, an agent has everything needed to call and interpret it.

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

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

Schema description coverage is 100% and the single parameter already carries examples, so the schema does the heavy lifting. The description reinforces the parameter with its own example ids, which is useful but largely duplicative of the schema — baseline 3 is appropriate.

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

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

States a specific verb (returns) and resource (full detail plus supported/partial/via_transpiler/unsupported feature lists for ONE coverage topic id). It explicitly scopes to a single topic and names the sibling list_coverage_topics as the source of ids, so it is distinguishable from siblings without opening a schema.

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

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

Gives an explicit trigger ('when you are about to work in a feature area and need to know precisely which functions are implemented vs skipped') with concrete examples (request.security, ta.*, strategy risk knobs). It also routes the agent to list_coverage_topics for obtaining valid ids, covering the alternative path.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), but the description adds operational context they cannot: cheap, free, local, no engine run, no I/O. It also defines the status vocabulary's real meaning (via_transpiler works end-to-end; unsupported means refused/no-effect/halting at value read), which is behavior an agent cannot infer from the schema.

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

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

The action-relevant instruction is front-loaded and every sentence carries routing or caveat value. The long inline parenthetical explaining the legend and status semantics is somewhat heavy for a description, since the tool itself returns that legend, but it prevents misinterpretation of the 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 steps in and describes the return payload precisely: topics with status plus summary, the legend, and the coverage version. Combined with the routing to two sibling tools, an agent has everything needed to call and interpret this tool.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate — baseline 4 applies. No parameter-level guidance is needed or missing.

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

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

States a specific verb and resource ('Lists every coverage topic with a one-line status... plus the legend... and the coverage version') and frames the server's constraint (PineForge implements a SUBSET of Pine v6). An agent can immediately distinguish this from get_coverage_topic (per-area drill-down) and check_pine_feature (single identifier lookup).

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?

Opens with an explicit trigger ('START HERE before writing, porting, or backtesting a Pine v6 strategy') and gives the rationale (avoids a strategy that compiles but silently misbehaves). It then names both alternative siblings and the exact condition that selects each one.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds the non-obvious fact that it 'Does not run the engine' plus the return shape ({key, type, enum?, description}). That is meaningful context beyond the safety profile, though it doesn't mention anything about staleness or caching of the catalog.

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

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

Front-loaded with the core purpose and the practical 'Does not run the engine' caveat. The middle sentence enumerates all 9 strategy_overrides and 5 runtime_args keys, which is dense but arguably earns its place as the tool's actual payload; it is the one spot that reads as bulky.

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 fully compensates by naming both return groups, distinguishing strategy() header fields from run_backtest_full args, and giving the per-entry shape. An agent has everything needed to call and consume 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The description instead spends its words on return-value semantics, which is appropriate for a no-arg discovery call.

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 ('Returns the full catalog of engine knobs') and scopes it precisely to the consumers, backtest_pine / backtest_pine_grid. An agent can distinguish this from siblings like check_pine_feature or transpile_pine without opening the schema.

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

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

Explicitly says 'Use this to discover what knobs the engine exposes before issuing a backtest,' which names the moment of use and the downstream tool. It lacks an explicit when-not clause (e.g., when the caller already knows the knob names), 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 openWorldHint=true and idempotentHint=true, covering network access and repeat-safety. The description adds real context by naming the mechanism (`docker pull`) and targeting a local machine image, but says nothing about Docker prerequisites, download size/time, or failure behavior.

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

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

Two short sentences with no filler; the action is front-loaded and the usage hint follows immediately. Nothing extraneous.

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, no-output-schema tool with annotations covering safety and network scope, the description provides enough to invoke it correctly. Minor gaps: no mention of Docker being required or what a failed pull looks like.

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 single `image` parameter already documents its default in the schema. The description adds no syntax, format, or override guidance beyond that, so the baseline of 3 applies.

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

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

States a concrete verb and resource: runs `docker pull` for the pineforge-release runtime image. An agent can distinguish this from sibling `check_engine_image` (which presumably only verifies) without opening the schema.

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

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

"Useful before the first backtest_pine call" gives a timing hint, but it is hedged ("useful") and never names the alternative `check_engine_image` or states when the pull is unnecessary. Usage is implied rather than prescribed.

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?

Adds real behavioral context beyond the annotations: no API key, no network, source never leaves the machine, and the return is text C++. That is more than the hints convey. However the 'no network' claim sits uneasily against openWorldHint=true, and readOnlyHint=false is not explained for what reads as a pure code-generation operation, leaving some ambiguity.

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

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

Three short sentences, front-loaded with what it does, then the local/no-key guarantees, then the routing to the alternative. No filler and nothing buried.

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

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

No output schema exists, and the description compensates by stating the return is the generated C++ as text. Combined with the version requirement (v6) and the Docker dependency, an agent has what it needs 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 100%, so both parameters (source, image) are already documented in the schema, and the description adds no format or syntax detail beyond it. Baseline 3 applies when the schema does the heavy lifting.

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

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

States a specific verb (transpile) and resource (PineScript v6 source) and names the concrete output (a C++ translation unit). It explicitly distinguishes itself from the sibling backtest_pine, so an agent can pick the right tool without opening either schema.

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

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

Explicitly routes the agent to backtest_pine when it also wants to run the strategy, which is clear alternative-selection guidance. It stops short of stating prerequisites that its own siblings imply, such as needing the engine image present (check_engine_image/pull_engine_image), so it is not a full 5.

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