HPSILab Quant Finance
Server Details
Quant finance tools: stock analysis, options IV, Monte Carlo, AI prediction, risk scan, backtests.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- haiyunsky/hpsilab-quant-finance-mcp
- GitHub Stars
- 1
- Server Listing
- HPSILab - Quant Finance MCP Server for Stock Analysis and Options Analytics
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.
Tool Definition Quality
Average 4.3/5 across 8 of 9 tools scored.
Each tool has a clearly distinct purpose: analyze_stock aggregates, generate_stock_images creates images, generate_stock_research_report produces a report, and the get_* tools retrieve specific quant metrics. No two tools serve the same function, reducing confusion.
Tool names follow a verb_noun pattern in snake_case, which is clear. However, verbs vary (analyze, generate, get) which is a minor inconsistency but still logical given the actions.
Nine tools cover a broad range of quant finance operations without being excessive. The count is well-suited for a specialized server focused on stock analysis and trading.
The tool surface includes analysis, images, reports, predictions, backtests, IV data, simulations, option pressure, and risk scans. While fundamental data or news sentiment is missing, the core quant features are well-covered.
Available Tools
9 toolsanalyze_stockARead-onlyInspect
Aggregate 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 |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses aggregation, direction derivation, partial failure mode, and error handling beyond what annotations provide (readOnlyHint). 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?
Front-loaded with main purpose, then details. Slightly verbose but every sentence adds value.
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 tool purpose, parameters, edge cases, and output behavior. Output schema exists so return format not needed.
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?
Adds clear explanations for both parameters (symbol example, refresh cache behavior) despite 0% schema coverage, fully compensating.
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 aggregates all quant tools into one JSON analysis, distinguishing it from sibling tools which are individual quant functions.
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?
Implies use for comprehensive stock analysis from multiple tools, but lacks explicit 'when to use' vs siblings. Partial failure handling is noted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_stock_imagesARead-onlyInspect
Generate 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.
| Name | Required | Description | Default |
|---|---|---|---|
| force | No | ||
| types | No | ||
| symbol | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true and destructiveHint=false. The description adds context about the backend reuse of image generators and the default force behavior for fresh data, which goes beyond 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 succinct and well-structured: a one-sentence core purpose, a brief rationale, then parameter details. Every sentence adds value with no 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 output schema existence and annotations, the description covers purpose, usage context, and most parameters. It lacks details on possible errors or output format, but output schema fills the latter gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It adequately explains 'symbol' and 'force' (including default rationale) but does not mention the 'types' parameter, leaving a gap.
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 verb (Generate) and resource (stock-report PNG images) and distinguishes from analyze_stock by explaining the separation for performance.
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 why it is separate from analyze_stock but does not explicitly state when to use this tool vs. other sibling tools like generate_stock_research_report. Implied usage is present but no explicit when-not or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_stock_research_reportARead-onlyInspect
Full 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and destructiveHint=false, and the description adds behavioral details such as concurrent execution of analyze_stock and image generation, return of both markdown and JSON, and caching behavior for refresh and force_images. 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 with a brief overview upfront followed by parameter details. It is moderately concise, but some introductory text could be more terse. However, it earns its length by providing essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the return format (markdown for display, JSON for data) and the content of the report. It covers all necessary details for an agent to understand inputs, costs, and outcomes, making it complete for a complex report generation 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 input schema has 0% description coverage, so the burden falls on the description. It provides clear explanations for all three parameters: symbol (ticker), refresh (bypass IV cache), and force_images (force new renders), including defaults. This fully compensates for the schema's lack of descriptions.
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', specifying the output format and content. It distinguishes from sibling tools like analyze_stock and generate_stock_images by being the combined report generator.
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 when to use the tool: for signed-in users within plan limits and for anonymous agents with pay-per-call. It provides context on costing and plan quotas, but does not explicitly list alternative tools or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_ai_predictionARead-onlyInspect
AI 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already show readOnlyHint=true, openWorldHint=true, destructiveHint=false. The description adds that the tool is non-destructive and available to all authenticated plans, subject to plan limits. This supplements the annotations without 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 concise, front-loading the key outputs, and efficiently uses an 'Args' section to specify the single parameter. Every sentence provides useful information without 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 tool with one simple parameter and no output schema, the description sufficiently explains the input, outputs, and access constraints. The agent has all needed information to decide to use and 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?
With 0% schema description coverage, the description fills the gap by defining the ticker parameter as a stock symbol and providing an example ('TSLA'). This adds meaningful guidance beyond the parameter name alone.
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 with three specific outputs: probability of stock closing UP, a buy/watch/sell-lean signal, and consensus strength. It distinguishes itself from sibling tools like analyze_stock and get_monte_carlo by focusing on a concise prediction.
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 availability to all authenticated plans and subject to plan limits, giving usage context. However, it does not explicitly state when to use this tool versus alternatives like get_equity_curves or get_iv_radar, though the distinct purpose implies appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_equity_curvesARead-onlyInspect
Backtest 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds transparency about rate limits and plan restrictions, and lists output metrics. 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?
The description is concise, with purpose first then parameter details. No unnecessary words, though the rate limit info could be more prominent.
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 tool with one parameter and safe annotations, the description covers purpose, metrics returned, authentication, and parameter usage. Missing details like time period or strategy name, but adequate overall.
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% (no property descriptions), but the description fully explains the ticker parameter: optional, example 'SPY', leave blank for all. This compensates completely.
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 quant strategy performance across a watchlist, listing specific metrics (Sharpe ratio, max drawdown, win rate, total return). This distinguishes it from siblings which focus on stock analysis, AI predictions, or 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 implies usage for viewing equity curve performance but does not explicitly state when to use this tool versus alternatives or note when not to use it. The availability and rate limit info is not comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_iv_radarARead-onlyInspect
Implied-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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds behavioral context: details on what the tool computes (volatility squeeze, call/put bias) and the refresh parameter's effect on caching. 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?
Two compact paragraphs: first defines purpose, second details parameters. No unnecessary words, every sentence adds value. Efficient and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking output schema, description gives sufficient context about the computed metrics (expensiveness, squeeze, bias). Annotations indicate openWorldHint, so exact return shape is not fixed. Covers key aspects for an agent to use 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?
Schema has 0% description coverage, but description explains both parameters: ticker as a stock symbol example, and refresh as a cache bypass option. This compensates for the schema gap effectively.
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 the tool retrieves implied-volatility structure for a stock, explaining what it measures (expensiveness, volatility squeeze, call/put bias). This specific verb+resource distinguishes it from siblings like get_option_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?
Description mentions availability to signed-in users but provides no guidance on when to use this tool versus alternatives like get_option_pressure or get_pretrade_risk_scan. Usage is implied but lacks exclusions or context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_monte_carloARead-onlyInspect
Monte 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive behavior. The description adds context: the simulation runs thousands of random paths over ~10 trading days and outputs a price range and probability. 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 extremely concise: one sentence describing the tool's purpose and one line for the parameter. Every word adds value, and it is front-loaded with the key action.
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 simple schema and available annotations, the description conveys the tool's function and input. It mentions outputs (price range and odds), but lacks explicit return value structure. Still adequate for selection and basic invocation.
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%, but the description adds an 'Args' section explaining 'ticker: Stock symbol, e.g. AAPL'. This provides meaningful guidance beyond the raw schema, though it could include more constraints like format.
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 is a Monte Carlo price simulation for the next ~10 trading days, estimating price range and odds of finishing higher. It is distinct 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 implies usage when one wants probabilistic price estimates over a short horizon, but it does not explicitly state when to use this tool versus alternatives or provide use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_option_pressureARead-onlyInspect
Option-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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to repeat safety. It adds value by describing the return content (pressure map with specific metrics) and the scope (nearest weekly/monthly expiry).
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, front-loading the main purpose and then listing the parameter. Every sentence provides necessary information without extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter, annotations are present, and there is no output schema, the description covers the key aspects: what it returns and the required input. It could mention whether it returns data for a single expiry or multiple, but overall it is adequate.
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%, so the description must compensate. It explains the single parameter 'ticker' as a stock symbol with an example, adding minimal but useful context beyond the schema's type and title.
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 an 'option-chain pressure map' for the nearest expiry, listing specific outputs like Max Pain, dealer Gamma Wall, etc. This distinguishes it from sibling tools like analyze_stock or get_iv_radar, which serve different 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 what the tool does but does not provide explicit guidance on when to use this tool versus alternatives. It implies usage for option pressure analysis, but lacks when-not-to-use or comparisons with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_pretrade_risk_scanARead-onlyInspect
Full 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 |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly and non-destructive behavior. The description adds useful context: pricing ($0.15/call via x402 for anonymous), plan limits for signed-in users, and output format (JSON). It does not cover error handling or rate limits, but complements annotations well.
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 appropriately sized, front-loading the purpose. Every sentence adds value (purpose, pricing, usage, parameter). Slight room for improvement by condensing pricing details, but overall 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?
Given the tool's simplicity (one parameter, output schema present, annotations cover safety), the description addresses purpose, parameter, pricing, and user context. It lacks mention of error handling or edge cases, but is largely complete for a straightforward read 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?
Schema description coverage is 0%, so the description must compensate. It provides an explicit Args section: 'symbol: Stock symbol, e.g. "NVDA".' This adds meaningful example and clarifies the parameter beyond the schema's minimal title.
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,' specifying the verb (get) and resource. While it distinguishes from some siblings by focusing on risk scan, it does not explicitly differentiate from nearby tools like get_iv_radar or get_option_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 provides pricing and user-type context but no guidance on when to use this tool versus alternatives. No 'when to use' or 'when not to use' statements are present, leaving the agent to infer usage from context.
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.
Discussions
No comments yet. Be the first to start the discussion!
Your Connectors
Sign in to create a connector for this server.