HPSILab Quant Finance

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

Beyond the annotations (readOnlyHint, idempotentHint), the description richly explains failure behavior: partial results if some sub-tools fail, error if all fail. It also details that the 'lang' parameter only affects summary/factors and not the signal, ensuring callers understand output consistency. This adds significant behavioral clarity beyond the given 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 well-structured: a brief summary, a detailed behavioral explanation, and a clean parameter list. It is concise yet complete, with no redundant or vague statements. The flow from aggregate purpose to fallback behavior to argument details is logical and efficient.

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 description gives a complete picture of what the tool returns (direction signal, score, bullish/bearish factors, summary, and status), enough for an agent to know what to expect. It also covers edge cases (partial/error). No essential information is missing for the intended use case.

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?

Although the schema's description coverage is 0%, the description thoroughly explains each parameter in the Args section: symbol with example, refresh with its purpose and default, and lang with its effect and accepted values. It also clarifies the scope of lang's influence, making parameter usage unambiguous.

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

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

The description clearly states the tool's function as aggregating all quant tools into a single JSON stock analysis, using a specific verb ('aggregate') and resource ('quant tools'). It distinguishes itself from siblings by being a composite/aggregator, which is evident from the listing of output components (direction signal, score, factors, 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 implies when to use this tool (for a comprehensive analysis) by stating it 'aggregates all quant tools' and 'reuses existing MCP tools as data sources.' It does not explicitly name alternatives (e.g., 'use get_iv_radar for just IV data'), but the aggregated nature and the phrase 'Aggregate all quant tools' make the usage context clear. Slightly more explicit guidance on when not to use it would warrant 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 beyond the annotations by explaining the caching behavior ('force: Regenerate images instead of using cached PNGs'), the default value of force, and the separation from analyze_stock to keep JSON analysis fast. It does not discuss rate limits or auth, but it covers the key behavioral traits (caching, regeneration) and aligns with annotations (readOnlyHint=false, etc.). No 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?

The description is well-structured: a one-sentence purpose, a short context note, and a clean Args list. Each sentence provides necessary information without redundancy. It front-loads the main purpose and is appropriately sized for 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?

The tool has only three parameters, one required, and an output schema is present, so the description need not explain return values. It covers all parameters, the caching behavior, and the rationale for separation from analyze_stock. Given the availability of the output schema and the tool's moderate complexity, the description is complete and provides sufficient context for an agent to select and 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?

With 0% schema description coverage, the description fully compensates by documenting each parameter: symbol with an example ('RXRX'), force with an explanation of caching and default, and types with the list of allowed values and default behavior (generate all). This significantly adds meaning beyond the raw 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 clearly states the tool's purpose: 'Generate stock-report PNG images and return their URLs.' The verb 'generate' plus resource 'stock-report PNG images' is specific, and the distinction from analyze_stock ('intentionally separate... so the JSON analysis stays fast and light') helps differentiate from the sibling tool.

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 contrasts with analyze_stock, indicating that this tool is for image generation while analyze_stock returns JSON analysis. It also explains the context of reuse by 'email/social publishing,' which clarifies intended usage. However, it does not mention when to use the get_* siblings versus this tool, though the image vs. data distinction is implicit.

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?

Discloses concurrency, payment via x402, free quota, cache behavior for IV and images, and output format (markdown + JSON). Provides context beyond annotations without contradicting them.

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

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

Structured with a short intro followed by Args; each sentence adds distinct value (cost, behavior, output, caching). 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?

Covers return value (markdown + JSON), payment/auth, parameter behavior, and pipeline composition. Sufficient for an agent to invoke correctly even without an output schema.

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

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

All three params are explained with an example for symbol, and refresh/force_images describe their effect (bypass IV cache, force fresh image render) and defaults. This fully compensates for zero schema coverage.

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 clearly states it generates a full markdown research report with five charts, and distinguishes from siblings by noting it runs analyze_stock and image generation concurrently.

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?

Sets context as a 'Pro tool' with pricing/quota, and explains it combines analyze_stock and image generation, implying it's the comprehensive option. However, it doesn't explicitly say when to prefer this over calling siblings separately.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description adds genuine unstated context: the output is research only and not a trade instruction, plus plan gating and rate-limit behaviour.

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 lead sentence front-loads the purpose and return contents, and the availability caveat follows compactly. The 'Args:' block is slightly redundant given the one-parameter schema, but nothing is bloated.

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

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

Though there is no output schema, the description enumerates what comes back (probability, lean, consensus), which compensates. The disclaimer and rate-limit note round out what an agent needs before invoking; the only gap is no guidance on alternatives.

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 the schema description coverage is 0%, so the description must carry the burden. It does name the parameter and supply a format example ('TSLA'), which is enough meaning for a single ticker argument.

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

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

States a specific resource and scope: an AI next-day prediction consisting of the probability the stock closes UP, a paper-trading lean, and model consensus. This is clearly distinguishable from siblings like get_monte_carlo or get_iv_radar 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?

It states availability ('every authenticated plan') and that it is subject to per-day and per-minute rate limits, which is useful operating context. However it never says when to prefer this over siblings such as analyze_stock or get_iv_radar, and gives 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?

The description adds context beyond annotations (plan availability, rate limits, parameter behavior). Annotations already indicate safe read-only operation, so the bar is lower but description still adds 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 succinct (<5 sentences), front-loaded with purpose, and structured with a header, bullet metrics, and parameter Args section. No wasted words.

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 low complexity (1 optional param, no output schema), the description covers input and usage well. However, it does not describe the output format or how to interpret return values, which agents might need.

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 0% schema coverage, the description meaningfully explains the ticker parameter: optional, leave blank for all, example 'SPY'. This adds clarity beyond the schema's default value.

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 performs backtesting of quant strategies across a watchlist, listing specific metrics (Sharpe ratio, max drawdown, win rate, total return). This distinguishes it from sibling tools like analyze_stock or get_monte_carlo.

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 mentions availability to all authenticated plans and rate limits, but does not explicitly advise when to use this tool versus alternatives like get_monte_carlo or get_ai_prediction. The context is clear but lacks explicit 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 annotations (read-only, idempotent, non-destructive), the description adds useful behavioral context: the refresh parameter reveals a caching mechanism that can be bypassed for the latest option-chain pull, and it explains what the IV structure indicates. This adds meaningful context not inferable from 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 concise and well-structured: a single purpose sentence followed by an Args section. Every sentence adds value, front-loading the core function and then clarifying parameters without any redundant or filler 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 simple get-only tool with strong annotations and only two parameters, the description covers the key context: what the IV radar measures and how to request fresh data. Though there is no output schema, the description conveys the type of insight returned; a minor gap is that it doesn't specify the exact return shape, but it remains sufficiently informative.

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 only names/types, but the description enriches both parameters: ticker is illustrated with an example, and refresh is explained as a cache-bypass flag. Since schema description coverage is 0%, the description compensates well by clarifying the functional role of each parameter.

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

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

The description clearly states the tool's function: providing implied-volatility structure for a stock, detailing what it measures (option expense, volatility squeeze, call/put skew). It uses a specific verb+resource pattern ('IV structure for a stock') and distinguishes itself from siblings like get_option_pressure by focusing on IV, not volume/pressure.

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 shows the tool is available to all signed-in users and implies usage for IV analysis, but it does not explicitly state when to use this tool versus alternatives or mention any exclusions. No sibling comparison is provided, so the guidance is inferred rather than explicit.

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 read-only, idempotent, and non-destructive behavior. The description adds behavioral context by explaining the Monte Carlo methodology, the probabilistic nature of thousands of random paths, and the ~10 trading day horizon, which is not covered by 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 concise and front-loaded: the first sentence states the core purpose, and the second section succinctly documents the parameter. Every sentence earns its place with 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 simple one-parameter read-only simulation, the description covers purpose, time horizon, and the concept of the output (price range and odds). It lacks explicit output format details, but this is not critical given the tool's simplicity and absence of an output schema.

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

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

The input schema has 0% description coverage for the ticker parameter. The description compensates fully with an 'Args' section explaining ticker as a stock symbol with an example ('AAPL'), adding meaning beyond the bare schema.

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

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

The description clearly states it performs Monte Carlo price simulation for the next ~10 trading days, estimating a price range and odds of finishing higher. This specific verb+resource+scope distinguishes it from siblings like get_ai_prediction and get_iv_radar.

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 clear context on the tool's use case (price range and odds estimation for a ~10 day horizon), but does not explicitly mention when to use it over alternatives or any exclusions. This fits the 'clear context, no exclusions' level.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the scoping constraint to 'nearest weekly/monthly expiry,' which is useful but not deep. It does not disclose how the expiry is selected, whether results are approximate, or any other behavioral traits beyond what annotations provide. Thus, it adds moderate value but not rich 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 extremely concise: one line for the purpose and a short Args block. It front-loads the core functionality without any fluff or repetition of schema content. Every sentence contributes meaning, making it easy 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?

Given the tool has only one parameter and no output schema, the description carries the burden of explaining the return value. It lists the four key metrics, which gives a solid idea of what to expect. However, it does not specify the output format (e.g., price levels vs. percentages), how 'nearest' expiry is determined, or whether the map is numeric or descriptive. Still, it is fairly complete for a simple read-only tool, so it earns a 4 rather than a 3.

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

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

The schema has only one parameter 'ticker' with no description (0% coverage). The description fully compensates by stating 'ticker: Stock symbol, e.g. "SPY".' which precisely conveys the expected input format and example. This is exactly what an agent needs to invoke the tool correctly, and the simplicity of the single parameter makes the coverage complete.

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 specifies the tool's output: an option-chain pressure map for the nearest weekly/monthly expiry, listing concrete metrics (Max Pain, dealer Gamma Wall, likely weekly high, extreme squeeze target). This distinguishes it from sibling tools like get_iv_radar or get_pretrade_risk_scan, which focus on different market dimensions. Although it lacks an explicit verb, the combination of the tool name and description makes the action (generate/return a pressure map) 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 description provides no guidance on when to use this tool versus alternatives such as get_iv_radar or get_pretrade_risk_scan. It does not mention any use cases, exclusions, or conditions. The only contextual hint is 'for the nearest weekly/monthly expiry,' which is a scoping detail rather than a usage recommendation.

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 cover the read-only/idempotent safety profile, and the description adds genuinely useful behavioral context beyond them: authentication modes, per-call x402 pricing, and that signed-in users spend Credits at a catalog price. The payment requirement in request _meta is valuable operational detail. It stops short of rate limits or response shape detail.

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 is front-loaded in the first sentence, and the billing/auth paragraph earns its space by covering a real gate to invocation. The Args block is a touch ceremonial for one parameter but not wasteful.

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

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

With an output schema present, return values needn't be described. Auth, payment, and the sole parameter are all covered, so an agent has enough to invoke correctly. Missing only selection guidance relative to the many sibling analysis tools.

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

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

Schema coverage is 0% and the single parameter is undocumented in the schema, so the description must carry it. It does: 'symbol: Stock symbol, e.g. "NVDA"' adds type meaning plus a concrete example. Adequate, though it could note format constraints for non-US tickers.

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+scope: a 'full pre-trade risk scan JSON for a stock'. This clearly distinguishes it from generic siblings like analyze_stock, though it does not explicitly name an alternative. Clear but no sibling routing.

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 details billing mechanics (Credits vs x402) but gives no guidance on when an agent should call this tool versus analyze_stock, get_monte_carlo, or get_iv_radar. Usage context is entirely absent.

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 beyond the annotations by explaining the server-side binding, metering behavior, and the email confirmation workflow: 'The account is bound to you server-side...', 'Registering keeps the anonymous daily allowance until the email address is confirmed; confirming it unlocks the full Free plan.' It also discloses the human involvement needed for verification. 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 well-structured into four focused paragraphs, each delivering specific information: outcome, usage trigger, confirmation flow, and email requirement. The main purpose is front-loaded, and every sentence adds value, making it both concise and complete.

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 and a single parameter, the description is fully sufficient. It covers the trigger, prerequisites, immediate result (API key), long-term behavior (plan upgrade), and human verification step. It even addresses edge cases like missing email. This is complete for an agent to safely invoke the 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 schema only provides the format 'email', but the description's 'Args' section adds real meaning: 'email: The real user email address that will receive verification.' It also warns against empty or fabricated addresses, clarifying the quality and purpose of the parameter.

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 direct statement: 'Register a free hpsilab account for yourself, with no human involvement, and receive an API key immediately.' This clearly identifies the action, resource, and outcome. It also distinguishes the tool from its stock-analysis siblings by focusing on account registration.

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?

Explicit guidance is provided: 'Call this when you are hitting anonymous daily limits and want a higher allowance.' It also includes a negative rule: 'Do not call this tool with an empty or fabricated email address. If the user's email is unavailable, ask the user to provide it before calling register_account.' This covers both when to use and when not to.

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