8-tool MCP server for US equity options intelligence: real-time IV radar, Monte Carlo price simulation, options pressure maps, equity curve backtesting, and quantum ML prediction signals for AI-driven trading research
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.4/5 across 10 of 10 tools scored. Lowest: 3.9/5.
Each tool targets a distinct purpose: individual quant analyses (AI prediction, IV, Monte Carlo, option pressure, equity curve, risk scan), aggregation (analyze_stock), output generation (images, report), and account registration. No two tools are likely to be confused.
All tool names follow a uniform verb_noun snake_case pattern (e.g., get_ai_prediction, generate_stock_images, register_account). The convention is applied consistently across the entire set.
10 tools is well within the ideal 3-15 range and covers the full stock-analysis workflow: data gathering, analysis, aggregation, and report generation. Each tool contributes distinct functionality without bloat.
The tool set comprehensively covers the domain of quant stock analysis: predictive models, backtesting, options/IV analysis, risk scanning, aggregated analysis, and visual/report outputs. No obvious dead ends or missing core operations for the intended purpose.
analyze_stockStock AnalysisAAggregate all quant tools into one JSON stock analysis.
The tool reuses the existing MCP tools as its data sources, then derives a
direction signal, direction score, bullish factors, bearish factors and
plain-English summary. If one underlying tool is gated, unavailable or
raises an error, the remaining tools still contribute to the final result
(status "partial"); if every underlying tool fails, the whole call fails
(status "error", isError=True) instead of a misleadingly "successful"
empty analysis.
Args:
symbol: Stock symbol, e.g. "NVDA".
refresh: Request fresh IV Radar data instead of using the backend's
fresh IV cache. Defaults to False.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | ||
| refresh | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, but the description adds substantial behavioral context: partial failure semantics ('status partial' if one source fails), the all-fail case producing an error, and the refresh parameter bypassing cache. These are valuable traits not derivable from annotations or 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 description is front-loaded with the purpose in the first sentence, followed by a behavioral paragraph, then a structured Args section. Every sentence contributes details about functionality, error handling, or parameters. It is thorough but not redundant, earning a high score.
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, the description need not restate return values. It covers aggregation behavior, error scenarios, and parameter semantics. The only minor gap is the vague phrase 'all quant tools'—exact underlying tools aren't enumerated, which could matter for understanding which data sources are included. Overall, it's nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden. It clearly explains both parameters: 'symbol: Stock symbol, e.g. NVDA' and 'refresh: Request fresh IV Radar data instead of using the backend's fresh IV cache. Defaults to False.' This is exactly what the schema lacks, providing the needed meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Aggregate all quant tools into one JSON stock analysis.' It then enumerates the derived outputs (direction signal, score, bullish/bearish factors, plain-English summary), which clearly distinguishes it from the sibling point-tools (e.g., get_iv_radar, get_monte_carlo) as a composite/aggregator 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 implies usage: it's for getting a consolidated view of all quant tools. However, it never explicitly states when to use this tool vs. alternatives, nor does it mention any exclusions or prerequisites. There is no direct 'use this when...' or 'instead of...' guidance, so the context is clear but not fully articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_stock_imagesStock Chart GeneratorAInspectGenerate stock-report PNG images and return their URLs.
This is intentionally separate from analyze_stock so the JSON analysis stays
fast and light. The backend reuses the same Growth Engine image generators
used by email/social publishing.
Args:
symbol: Stock symbol, e.g. "RXRX".
force: Regenerate images instead of using cached PNGs. Defaults to True
so manually requested images reflect the latest available data.
types: Optional subset of chart types. Allowed values are
"ai_prediction", "iv_radar", "option_pressure", "monte_carlo",
and "equity_curves". Omit to generate every chart type.
| Name | Required | Description | Default |
|---|---|---|---|
| force | No | ||
| types | No | ||
| symbol | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
generate_stock_research_reportStock Research ReportAInspectFull markdown research report with five stock-report charts. Pro tool ($0.35/call via x402 for anonymous callers; free within plan limits for signed-in accounts, subject to a monthly report quota).
Runs analyze_stock and stock-report image generation concurrently, then
renders a presentation-ready markdown report (direction, direction score, bullish /
bearish factors, source-tool status, and the five chart embeds). The markdown
is returned for display and the same data is mirrored in structured JSON.
Signed-in hpsilab users call this within their plan's free rate limits.
Anonymous / tokenless agents pay per call via x402 (USDC on Base) when
payments are enabled — send the x402 payment in the request _meta.
Args:
symbol: Stock symbol, e.g. "RXRX".
refresh: Bypass the backend's fresh IV cache for the IV-driven modules.
Defaults to False.
force_images: Force a fresh image render instead of reusing the backend's
image cache. Defaults to False.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | ||
| refresh | No | ||
| force_images | No |
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.
get_ai_predictionAI PredictionAAI next-day prediction: probability the stock closes UP, a plain buy/watch/sell-lean signal, and how strongly the models agree (consensus).
Available to every authenticated plan (Free / Pro / Enterprise); subject
to the caller's plan requests/day and requests/minute limits.
Args:
ticker: Stock symbol, e.g. "TSLA".
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (read-only, idempotent, non-destructive), the description discloses plan-based request limits and the three output components, adding useful behavioral context. It does not contradict annotations and enriches the understanding of what the tool returns.
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 sentences plus a parameter note—and front-loaded with the core purpose. It avoids redundancy but could be slightly more structured by separating output details from access info; still, no filler exists.
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 tool with no output schema, the description sufficiently covers the output types (probability, signal, consensus), the parameter, and access/rate-limit context. The return format is implied enough for an agent 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?
The schema provides only the ticker's type and title; the description's Args section adds a concrete definition and example ('Stock symbol, e.g. "TSLA"'), giving the parameter meaning. Since schema coverage is 0%, this compensation is valuable, even if simple.
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 identifies the tool as providing an AI next-day prediction with specific outputs (probability, buy/watch/sell signal, consensus), which distinguishes it from siblings like analyze_stock or get_monte_carlo. The verb 'prediction' and resource 'stock' 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 implies usage for obtaining next-day stock predictions, but does not explicitly state when to use this tool over alternatives or provide exclusions. It does add access context (available to all plans, rate limits), which helps but isn't direct tool-selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_equity_curveStrategy BacktestABacktest performance of the quant strategy across your watchlist: Sharpe ratio, max drawdown, win rate and total return per symbol.
Available to every authenticated plan (Free / Pro / Enterprise); subject
to the caller's plan requests/day and requests/minute limits.
Args:
ticker: Optional symbol to show just one row, e.g. "SPY". Leave blank for all.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | No |
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.
get_iv_radarImplied Volatility RadarAImplied-volatility (IV) structure for a stock: how expensive options are, whether volatility is being squeezed, and whether traders are paying up for upside (calls) or downside (puts). Available to all signed-in users.
Args:
ticker: Stock symbol, e.g. "NVDA".
refresh: Bypass the backend's fresh IV cache and request the latest
option-chain pull. Defaults to False.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | ||
| refresh | No |
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.
get_monte_carloMonte Carlo SimulationAMonte Carlo price simulation for the next ~10 trading days: thousands of random price paths estimate a likely price range and the odds of finishing higher.
Args:
ticker: Stock symbol, e.g. "AAPL".
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes |
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.
get_option_pressureOptions Pressure MapAOption-chain pressure map for the nearest weekly/monthly expiry — Max Pain, dealer Gamma Wall, likely weekly high, and an extreme squeeze target.
Args:
ticker: Stock symbol, e.g. "SPY".
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes |
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.
get_pretrade_risk_scanPre-Trade Risk ScanAFull pre-trade risk scan JSON for a stock. Pro tool ($0.15/call via x402 for anonymous callers; free within plan limits for signed-in accounts).
Signed-in hpsilab users call this within their plan's free rate limits.
Anonymous / tokenless agents pay per call via x402 (USDC on Base) when
payments are enabled — send the x402 payment in the request _meta.
Args:
symbol: Stock symbol, e.g. "NVDA".
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds valuable context by revealing this is a paid/pro tool with cost implications for anonymous users and a requirement to send x402 payment in the request _meta. This goes beyond the annotations and helps the agent anticipate real-world constraints.
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 with the main purpose stated first, followed by access/cost details and then an Args section. It is slightly verbose in repeating payment information, but every sentence adds relevant operational context. The front-loading of the core function aids quick comprehension.
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 tool with an output schema, the description covers the essential aspects: what it does, the symbol parameter, and important access/cost caveats. It lacks explicit alternative guidance, but the tool is simple enough that the provided information is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only specifies 'symbol' as a string with no description. The description compensates by explaining 'symbol: Stock symbol, e.g. NVDA,' providing a clear example and meaning. With schema coverage at 0%, this addition is essential and well-executed.
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 returns a 'Full pre-trade risk scan JSON for a stock,' which is a specific resource and output format. The name and title reinforce this, and it is distinct from sibling tools like get_ai_prediction or get_monte_carlo that serve different analytical purposes.
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 access and payment context (free within plan for signed-in users, per-call x402 for anonymous), but it does not explicitly state when to use this tool versus alternative risk/analysis tools. Usage is implied rather than clearly delineated, and no exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
register_accountRegister a Free AccountAInspectRegister a free hpsilab account for yourself, with no human involvement, and receive an API key immediately.
Call this when you are hitting anonymous daily limits and want a higher
allowance. You do not need a password, a wallet, or a web browser. The
account is bound to you server-side, so calls you make after this are
metered as your account even though you cannot change your own
Authorization header.
Registering keeps the anonymous daily allowance until the email address is
confirmed; confirming it unlocks the full Free plan. Ask the human you are
working with to click the link in the email that will arrive.
A valid user email address is required. 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.
Args:
email: The real user email address that will receive verification.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes |
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.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
