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

Goes well beyond the annotations by disclosing the HPSILAB_API_KEY requirement, account-governed quota and ticker coverage, and a 5–15 s latency from multi-model aggregation — all decision-relevant for an agent planning a call. Annotations already declare readOnly/idempotent/non-destructive, and nothing here contradicts 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?

Front-loads the one-line purpose, then when-to-use, then the alternative — a good order with no filler prose. The full 'Returns' key listing duplicates the existing output schema and is the one block that does not earn its space.

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-symbol aggregator, everything an agent needs is present: what it computes, when to call it, what it costs in latency/quota, and confirmation of the auth prerequisite. Return values are independently covered by the output schema, so the duplicated listing is excess rather than a gap.

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

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

With a single parameter at 100% schema description coverage, the schema already carries the uppercase-ticker format, pattern and examples. The description adds no parameter-level guidance of its own (e.g. market/exchange limitations), so the baseline 3 for schema-driven parameters applies.

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

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

States a specific verb and resource ('Run a full institutional-grade quantitative analysis for a single stock') and explicitly positions itself as the aggregator of AI prediction, IV radar, options pressure, Monte Carlo and backtesting. It names the dedicated sub-tools it supersedes, so an agent can distinguish it from get_iv_radar, get_monte_carlo, etc. without opening any schema.

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

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

Gives an explicit 'Use this tool when' list tied to user phrasings ('stock analysis', 'market view', 'trading signal') plus the inverse rule: prefer the dedicated sub-tools when only one data dimension is needed, to reduce latency and token usage. Both the when and the when-not are stated with named alternatives.

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

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

Beyond annotations, it discloses that images are served as public URLs, expire after 24 hours, and may need to be opened directly in a browser if client rendering fails. This adds useful operational context consistent with openWorldHint=true and readOnlyHint=false, though it does not mention generation cost or latency.

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

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

The description is front-loaded with purpose, then structured into usage guidance, parameters, notes, and returns. It is generally efficient, though the Returns section is somewhat redundant because an output schema exists, and the parameter section largely repeats schema 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?

Given the moderate complexity, rich schema, annotations, and existing output schema, the description provides enough context to invoke the tool: chart types, public URL behavior, expiry, caching/force, and return keys. Its main gap is the lack of explicit sibling routing and clarification of how the types enum maps to the returned chart URLs.

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 force, types, and symbol are already well documented. The description repeats the allowed types and default behavior for force/omit, but it does not resolve the naming mismatch between the types enum (ai_prediction, iv_radar, option_pressure, monte_carlo, equity_curves) and the returned chart URL keys (price_chart_url, iv_surface_url, options_flow_url).

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: generating hosted chart image URLs for a stock, including price chart, IV surface, and options flow heatmap images. It clearly differentiates the tool from siblings that retrieve chart data (e.g. get_iv_radar, get_option_pressure) by focusing on image URL generation, though it does not explicitly name those 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 usage bullets: when a user asks to 'see', 'show', or 'visualize' a chart, when adding visuals to analysis, and when sharing chart links. It does not state when NOT to use it or when a sibling data-retrieval tool is preferable, so it stops short of full alternative routing.

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

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

Annotations already cover the safety profile (destructiveHint=false, openWorldHint=true, readOnlyHint=false), so the bar is lower, yet the description still adds material context: ~10–20 s latency, HPSILAB_API_KEY requirement, and that quota/coverage are governed by the account. It also flags that analyze_stock is preferable for programmatic use. The one gap is that it never explains why the tool is non-read-only (the report generation consumes quota/API access), leaving readOnlyHint=false only loosely reconciled.

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 one-sentence purpose, then organized under labeled headings, so an agent can skim to what it needs. The Returns section largely restates the output schema, which is minor redundancy, but the section list and latency figure both earn their lines.

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

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

For a single-parameter, high-latency aggregation tool, the description supplies everything an agent needs: what comes back, how long it takes, auth requirements, quota caveats, and when to prefer siblings. Because an output schema exists, it need not spell out return values, and the brief Returns block is sufficient corroboration rather than a substitute.

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

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

There is exactly one parameter and schema description coverage is 100%, including the pattern, examples, and an explicit 'Do NOT pass company names' warning, so the schema already does all the work. The description only implies a single-ticker scope and refers to 'normalized ticker' in the Returns block; it adds no format or validation detail beyond the schema. Baseline 3 is appropriate.

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

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

States a specific verb and resource ('generate a structured, institutional-style markdown research report for a single stock') and then enumerates the six sections it contains, which is a level of detail no sibling provides. The output artifact (markdown string, ~800–1200 words) is unambiguous, so an agent can distinguish this from analyze_stock or the individual data tools 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?

Contains explicit 'Use this tool when' and 'Do NOT use this tool when' blocks, and routes to named alternatives with the condition that selects them (analyze_stock for a quick verdict, get_iv_radar / get_monte_carlo for a single dimension, citing lower latency). This is exactly the when/when-not/alternative structure that earns a top score.

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

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

Annotations already declare the tool as read-only, idempotent, open-world, and non-destructive. Beyond that, the description discloses the ensemble composition (gradient-boosted trees, LSTM, VQC), feature inputs, and returned fields like confidence and regime, which is useful behavioral context. It does not cover latency, data freshness, or failure modes.

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 a clear purpose sentence, followed by well-structured use-case bullets and a labeled returns section. It is somewhat verbose in listing return keys even though an output schema exists, but the content remains relevant and easy 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 one-parameter, read-only prediction tool with annotations and an output schema, the description covers purpose, use cases, model basis, and output semantics thoroughly enough to invoke it correctly. It lacks explicit sibling routing and operational caveats like data freshness or limitations, which keeps it from a 5.

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

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

There is only one parameter and the schema description coverage is 100%; the schema already documents the ticker format, pattern, examples, and per-ticker accuracy caveats. The description adds no parameter-specific guidance beyond implying a stock ticker, so the high-coverage 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 first sentence states a specific verb and resource: get an AI/ML directional prediction for a stock's next-session move. The use-case bullets further scope it to next-day direction, ensemble votes, and IV comparison, which distinguishes it functionally from broader siblings like analyze_stock. It does not explicitly name sibling tools, so it falls short of a 5.

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

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

The description provides an explicit 'Use this tool when' section with three concrete conditions: wanting a probability estimate, needing ensemble votes, or comparing confidence to IV pricing. It gives clear use context but does not state when not to use it or explicitly name alternatives such as get_iv_radar or get_monte_carlo.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety bar is largely covered. The description adds one piece of genuine context not in the annotations — that the data is backtested/simulated rather than live — but nothing about data history depth, rate limits, or freshness. The lengthy Returns block restates the output schema rather than adding behavior.

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

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

The when-to-use list is well front-loaded, but roughly half the text is a field-by-field Returns breakdown that duplicates the already-present output schema. That section is padding the agent does not need, diluting an otherwise tight definition.

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 a single required param, full schema coverage, an output schema, and rich annotations, the description covers the essential selection question: what the tool yields and why you'd call it. The only notable omission is any pointer to a contrasting sibling 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?

Only one parameter, and its schema description is fully covered (uppercase ticker, no company names, with examples). The description adds no format or normalization detail beyond that, 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 and resource: retrieve backtested equity curves and performance metrics for rule-based strategies on a single stock. That scope is clearly distinct from prediction- or options-oriented siblings, though no sibling tool is named to sharpen the contrast.

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?

A dedicated 'Use this tool when:' block gives three concrete scenarios (strategy evaluation, risk-adjusted metrics comparison, historical context for a multi-leg options position). It gives strong positive guidance but never states when not to use it or points to an alternative like analyze_stock or get_monte_carlo.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description adds meaningful interpretation beyond that: IV rank thresholds ('≥80 = expensive, ≤20 = cheap'), regime categories, and the sign convention for risk reversal. It does not mention data staleness, source, or rate limits, so it stops short of full behavioral disclosure, but it is substantially richer 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 front-loaded with purpose, then use cases, then an exclusion, then returns—a logical structure. It is somewhat long because the 'Returns' section repeats keys that likely appear in the output schema, though the added interpretation thresholds justify most of that length.

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 single-parameter schema, the existing output schema, and the fully populated annotations, the description covers purpose, when/when-not to use it, and how to interpret the returned metrics. An agent has everything needed to call the tool correctly and understand its output semantics.

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 schema itself specifies uppercase ticker format, a regex pattern, and examples while explicitly forbidding company names. The description only adds 'for a single stock,' which clarifies that one symbol is accepted but is marginal against the fully documented schema. Baseline 3 is correct when the schema does the heavy lifting.

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

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

The description opens with a specific verb and resource: 'Retrieve implied-volatility (IV) metrics for a single stock.' It explicitly distinguishes itself from a sibling by warning 'Do NOT use this tool if you already called analyze_stock.' An agent can identify the tool's exact scope 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?

Three explicit 'Use this tool when' bullets cover cheap/expensive assessment, volatility regime framing, and skew analysis. The 'Do NOT use' clause names the alternative (analyze_stock) and the precise condition that selects it, leaving nothing 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 cover read-only, idempotent, non-destructive and open-world, so the description's added value is the model disclosure: GBM calibrated on historical log-return drift and volatility, explicitly *not* implied volatility, with 5,000 paths. That is genuinely useful context (and quietly explains why this differs from get_iv_radar), but it omits cost/latency, data requirements (e.g. how much history is needed), and behavior on an unknown or thinly traded ticker.

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 usage bullets are well front-loaded, but the description then embeds a full 15-line 'Returns' section that duplicates field-by-field what the existing output schema already declares. That block consumes more than half the text without adding information an agent can't get from structured data, so the otherwise clean structure is diluted.

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

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

Given a single required parameter, full schema coverage and an output schema, the definition covers everything needed to invoke it correctly: model assumptions, fixed horizon, path count, and when to choose it. Missing only secondary details such as error behavior for invalid symbols and whether repeated calls return identical paths, which the idempotentHint implies but doesn't confirm.

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

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

There is only one parameter and schema coverage is 100%, with the schema itself spelling out uppercase ticker format, a regex pattern, examples, and the 'no company names' rule. The description adds nothing about `symbol`, so this sits at the baseline where the schema does all the work.

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 Monte Carlo price-path simulation') plus the scope ('next 10 trading days') in the first line. The three 'Use this tool when' bullets distinguish it from point-estimate siblings like get_ai_prediction and analyze_stock by explicitly framing it as a probabilistic range rather than a single number.

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 'Use this tool when' block gives three concrete selection conditions, including the key contrast 'a probabilistic price range rather than a single point estimate', which implicitly routes point-estimate requests elsewhere. It stops short of naming a concrete alternative sibling or a 'do not use when' case, so it is clear context but not 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 it as read-only, idempotent, open-world, and non-destructive, so the safety profile is covered. The description adds domain meaning to the returned fields, but it does not disclose operational traits such as data freshness, market-hours behavior, or rate limits beyond what the annotations and output schema 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 front-loaded with purpose and use cases, then structured return-value details. The returns section largely duplicates the existing output schema, so it is not maximally concise, but the overall structure is clear 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 a single required parameter, full schema coverage, rich annotations, and an output schema, the description is more than sufficient for correct invocation. It covers purpose, use cases, and return semantics without leaving material gaps.

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

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

There is only one parameter, and the input schema covers it at 100% with a pattern, examples, and a clear warning against using company names. The description does not add any symbol-format guidance beyond the schema, so the 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 states a specific verb and resource: retrieving options-market positioning and dealer-hedging pressure zones. It explains the concrete outputs (max pain, gamma walls, expected move), making the tool clearly distinct in practice. However, it does not explicitly differentiate itself from sibling tools such as get_iv_radar or analyze_stock.

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 'Use this tool when' bullets give clear triggering conditions for max-pain, gamma walls, and expected-move analysis. It does not mention when not to use the tool or name a sibling alternative, so it falls short of the top score.

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 readOnly/idempotent/non-destructive annotations: discloses the HPSILAB_API_KEY requirement, that a paid plan is needed and Free accounts get a 403 without being charged, that each call deducts Credits and an empty balance yields 402, and instructs the agent to confirm with the user before spending credits. It also pre-explains degraded behavior when the user has no watchlist (available=false, null fields, relay the reason rather than treat as an error).

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, usage rules, and the exclusions are front-loaded and earn their place, as do the two important caveats (riskDeltas are not portfolio deltas; liquidity threshold text drift in pre-2026-10-12 deployments). However, the Returns block reproduces an output schema that already exists, at great length — nearly half the description restates field-by-field output structure.

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

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

For a single-parameter but behaviorally complex tool, everything an agent needs is present: cost/auth gating, failure modes, the version-drift caveat on liquidity thresholds, and the explicit handling of unavailable exposure/correlation sections. The output schema carries return shapes, yet the description's clarifications about historically-named fields add real value rather than redundant detail.

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

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

Only one parameter and schema coverage is 100%, so the schema already states the uppercase ticker pattern and forbids company names. The description adds little beyond the example call get_pretrade_risk_scan("NVDA") — no further semantics about normalization or symbol resolution, which is the baseline case.

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

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

Names a specific verb and scope ("pre-trade risk scan for a single stock") and enumerates its components: volatility/beta/VaR/drawdown vs SPY, regime, forward return distribution, sizing checks, and watchlist-based exposure/correlation. It also makes the scope boundary explicit — riskDeltas compare SPY vs stock, and only exposure/correlation use the portfolio — which an agent could not infer from the name.

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

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

Provides an explicit "Use this tool when" list of four scenarios and a "Do NOT use this tool for" list that routes to named siblings: get_monte_carlo for standalone price simulation and analyze_stock for a general directional read. Both the positive and negative conditions are stated, not implied.

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

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

Beyond the annotations, the description discloses key side effects and lifecycle details: a verification email is sent, the account starts unverified with no trial Credits, confirmation grants a one-time 100-Credit trial, and the account is bound server-side. It also explains retry behavior and refusal when an email belongs to another account.

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 organized into clear sections, but it is longer than strictly necessary. The returns block repeats information that an output schema likely already contains, and some verification-email details appear in multiple places.

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 auth-related complexity, side effects, and the presence of an output schema, the description is complete. It covers prerequisites, post-success API key handling, account verification state, retry semantics, and failure cases.

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 single `email` parameter is already well documented. The description reinforces that the user's own address should be used, but it does not add substantial syntax or constraint detail beyond the schema.

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

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

The description states a specific verb and resource: registering a free HPSILab account and receiving an API key. It also distinguishes this tool from all sibling stock-analysis tools by noting it is the only tool that works without HPSILAB_API_KEY.

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 bullets, including the no-key signup case and the fresh-key-for-existing-account case. It also states when not to use it: never to work around another tool's error, and only when the user asks.

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