hpsilab-mcp

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

Annotations already mark it as read-only and non-destructive. The description adds behavioral context about aggregation: it reuses other MCP tools as data sources, derives new outputs, and tolerates partial failures. This goes beyond the annotations by explaining the composite nature and fault tolerance.

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: a one-sentence purpose followed by brief outlines of outputs and error behavior, then clear parameter documentation. Every sentence adds value without repetition or fluff.

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 an output schema (not shown), the description needn't detail return values. It adequately covers the tool's composition, error tolerance, and key behavioral traits. Some minor gaps like specifying aggregation order or performance implications, but overall complete for its complexity.

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 fully explains both parameters: symbol (with example 'NVDA') and refresh (clarifying it requests fresh IV Radar data and defaults to False). This provides essential meaning that the schema alone lacks.

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 aggregates all quant tools into one JSON stock analysis, specifying it derives a direction signal, score, bullish/bearish factors, and summary. This distinguishes it from sibling tools like get_iv_radar or get_option_pressure, which focus on individual data points.

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

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

The description explains that the tool is a composite of other tools and handles errors gracefully (gated or unavailable tools still allow others to contribute). While it doesn't explicitly state when not to use alternatives, the aggregation purpose and resilience guidance provide clear usage context for an agent deciding between this and individual tools.

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

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

Annotations indicate readOnly and non-destructive. Description adds that backend reuses image generators from email/social publishing. No contradictions.

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

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

Five sentences, bullet-style args, no fluff. Efficiently conveys purpose and parameter details.

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

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

Output schema exists, so not describing return format is acceptable. Could mention caching or performance but adequate as is.

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 0%; description explains symbol and force (defaults to True) but does not explain 'types' parameter at all.

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?

Clearly states it generates PNG images and returns URLs. Distinguishes from sibling analyze_stock by explaining separation.

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?

Explains why separate from analyze_stock (keeping JSON analysis fast). Lacks explicit when-not-to-use or alternatives for different image types.

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

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

Annotations provide readOnlyHint=true, openWorldHint=true, destructiveHint=false. The description adds behavioral context beyond annotations: it runs analyze_stock and image generation concurrently, and mentions caching bypass options (refresh, force_images). No contradictions 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 concise (5 sentences) and well-structured. It front-loads the main purpose, then details parameters. Every sentence adds value, with no redundancy or filler.

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

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

For a 3-parameter tool with no output schema, the description adequately covers inputs and output format (markdown and structured JSON). It explains the concurrency and caching behavior. Could be slightly more detailed on JSON structure, but sufficient for agent understanding.

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 0%, but the description fully explains each parameter: symbol (stock symbol with example), refresh (bypass IV cache, default false), force_images (force fresh render, default false). This adds crucial meaning that the schema lacks.

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 generates a 'full markdown research report with five stock-report charts'. It specifies the verb 'generates' and resource 'stock research report', and distinguishes from siblings by explaining it runs analyze_stock and stock-report image generation concurrently. The report contents are listed (direction, direction score, bullish/bearish factors, etc.), making the purpose 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?

No explicit guidance on when to use this tool vs alternatives like analyze_stock or generate_stock_images. It mentions concurrency but does not tell the agent when to choose this composite tool over calling the individual tools separately. No prerequisites or exclusions 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 readOnlyHint=true and openWorldHint=true. The description adds value by detailing the prediction outputs (probability, signal, consensus) and confirming availability for any ticker. No additional behaviors (rate limits, data sources) are described, but the core behavioral traits are well covered.

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: two short paragraphs with no superfluous sentences. The main information is front-loaded in the first sentence, and the parameter is clearly listed. 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?

Given the tool has only one required parameter and an output schema exists, the description adequately covers purpose, parameters, and output semantics. No additional details are needed for an agent to select and invoke the tool correctly.

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

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

With 0% schema description coverage, the description compensates by defining the only parameter 'ticker' as 'Stock symbol, e.g. 'TSLA'.' This adds clear meaning and an example, though it could be more detailed.

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

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

The description clearly states the tool provides an AI next-day prediction including probability of closing UP, a trading signal, and consensus level. The verb 'get' is implied, and the resource 'AI prediction' is specific. It distinguishes from siblings like 'analyze_stock' and 'generate_stock_images' by focusing on a pure prediction output.

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 mentions 'Available for any authenticated user's ticker,' giving a general usage condition. However, it does not explicitly state when to use this tool versus alternatives (e.g., analyze_stock) or provide any exclusion criteria.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by specifying the output metrics (Sharpe, max drawdown, win rate, total return). It does not contradict annotations and provides useful behavioral context beyond the safety profile.

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: two sentences and an Args section. It front-loads the purpose and quickly covers the parameter. No wasted words; each 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 tool with one optional parameter and annotations present, the description sufficiently explains what the tool does and what metrics it returns. The presence of an output schema further reduces the burden. No missing critical information.

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 schema description coverage at 0%, the description fully compensates by explaining the 'ticker' parameter meaning: optional symbol to show one row, with example and instruction to leave blank for all. This adds crucial context missing from 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 clearly states the tool backtests a quant strategy across a watchlist, listing specific metrics (Sharpe ratio, max drawdown, etc.). Verb 'backtest' and resource 'quant strategy' are specific and differentiate from sibling tools, which focus on individual stock analysis, images, and reports.

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 guidance on the optional 'ticker' parameter with an example. It implicitly tells when to use (for backtesting a quant strategy) but does not explicitly exclude alternatives among siblings, though the purpose is distinct enough.

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

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

Annotations already mark the tool as read-only (readOnlyHint=true) and non-destructive (destructiveHint=false). The description adds value by explaining the 'refresh' parameter behavior (bypasses cache for latest data) and the special role of the tool. It does not contradict annotations, though the side effect on the backend cache is not fully elaborated.

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 with three sentences plus an Args block, no filler. The main purpose is front-loaded in the first sentence. Every part contributes to understanding, including the availability note and parameter details.

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

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

Given the tool has 2 parameters, an output schema (not shown but exists), and the complexity of IV structure, the description covers purpose, scope, availability, and parameter details. No missing aspects are evident; the output schema handles return values.

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 0%, but the description compensates well with an Args section explaining both parameters. 'ticker' is exemplified with 'e.g. "NVDA"', and 'refresh' is explained as bypassing cache with a default of False. This adds meaning beyond the schema types and defaults.

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 provides 'Implied-volatility (IV) structure for a stock' with specific outputs like option expensiveness, volatility squeeze, and call/put bias. It distinguishes from sibling tools (e.g., get_option_pressure) by focusing on IV structure. The verb 'get' and resource 'IV radar' are explicit.

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 mentions 'Available to all signed-in users,' which sets usage context. It implies when to use (to understand option pricing dynamics) but does not explicitly state when not to use or provide alternatives. Sibling tools are not referenced in the description, so guidance on selecting between tools is 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?

Annotations already indicate readOnly and non-destructive. The description adds that the simulation is stochastic, generating thousands of random paths, which gives important behavioral context. However, it could mention that results vary per call due to randomness.

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

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

Two sentences: first explains the purpose, second describes the args. No extraneous information, front-loaded, efficiently conveys necessary details.

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

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

Given the complexity of Monte Carlo simulation, the description covers the core functionality. The output schema exists (not shown) so return values are not required. Minor omissions: no discussion of assumptions or limitations (e.g., market regimes).

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 provides the only explanation for the 'ticker' parameter: 'Stock symbol, e.g. "AAPL"'. This is sufficient but minimal; could be improved by noting valid symbols or case-insensitivity.

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 ~10 trading days, estimating a price range and probability of finishing higher. This distinguishes it from sibling tools like get_ai_prediction 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 description explains what the tool does but does not provide explicit guidance on when to use it versus alternatives like get_ai_prediction or analyze_stock. Usage context is implied but not directly 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 readOnlyHint=true, openWorldHint=true, and destructiveHint=false, establishing a safe, non-mutating behavior. The description adds value by specifying the output content (pressure map, specific metrics) and the temporal scope (nearest weekly/monthly expiry), which goes beyond the annotations without contradicting them.

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

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

The description is extremely concise: two sentences define the purpose and key metrics, followed by a clean argument definition. Every word is informative, with no filler or redundancy, and the most critical information is front-loaded.

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

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

Given the tool has an output schema (not shown but indicated), the description does not need to detail return structure. It lists the key metrics (Max Pain, dealer Gamma Wall, etc.) which suffices for an agent to understand what the tool provides. The parameters are fully explained, and the expiry scope is clarified. This is complete for the tool's complexity level.

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, so the description must compensate. It does so by explaining the 'ticker' parameter as 'Stock symbol, e.g. SPY', adding clear meaning and an example. This is sufficient for a single-parameter tool; a higher score would require additional constraints or format details.

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

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

The description clearly states the tool provides an 'option-chain pressure map' for the nearest weekly/monthly expiry, listing specific metrics like Max Pain, dealer Gamma Wall, likely weekly high, and extreme squeeze target. This distinguishes it from sibling tools such as analyze_stock (general analysis) or get_iv_radar (IV focus), making the purpose unmistakable.

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

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

The description implies usage for specific expiry windows ('nearest weekly/monthly expiry') and lists options-related metrics, which suggests use cases around options pressure analysis. However, it lacks explicit when-to-use or when-not-to-use guidance and does not reference alternative tools like get_iv_radar for volatility or analyze_stock for broader insights.

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