kwant
Server Details
Quant intelligence over MCP: backtest, signals, screens, scores & portfolios for US & TSX stocks.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.1/5 across 16 of 16 tools scored. Lowest: 2.7/5.
Most tools have distinct purposes, but compute_universe_scores and screen_with_scores both rank a universe by identical cross-sectional signals, creating confusion for an agent.
Tool names consistently follow a verb_noun pattern (e.g., compute_*, get_*, screen). The only minor deviation is 'screen_with_scores' using a preposition, but overall naming is predictable.
16 tools cover a broad domain of quantitative analysis. While slightly above the typical 3-15 range, each tool serves a distinct function, justifying the count.
The tool set covers the full quantitative finance workflow: data retrieval, technical analysis, stats, universe construction, screening, portfolio optimization, and backtesting. No obvious gaps are present.
Available Tools
16 toolsbacktestAInspect
Backtest a simple long-only technical strategy on daily price history. Strategies: sma_cross (golden/death cross of SMA 50/200), rsi_reversion (enter RSI<30, exit RSI>70), macd_cross (MACD line vs signal). No-lookahead: signals act on the next bar's close. Returns trades + performance metrics.
| Name | Required | Description | Default |
|---|---|---|---|
| range | No | ||
| params | No | ||
| ticker | Yes | ||
| strategy | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the no-lookahead behavior (signals act on next bar's close) and return types (trades + performance metrics). However, it does not mention authorization needs, destructive potential, or rate limits, which are gaps.
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: three sentences with zero filler. Every sentence adds value—purpose, strategies, behavioral note, and output. It is front-loaded with key 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 the complexity (4 params, no output schema), the description covers the main purpose, strategies, key behavioral constraint, and output summary. It falls short on explaining the params object and the range enum, but overall is sufficient for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description adds minimal parameter meaning. It lists strategies for the strategy parameter but does not explain ticker, range, or the params object (e.g., what keys it accepts for each strategy). This leaves significant ambiguity for the agent.
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 'backtest' and the resource 'simple long-only technical strategy' on daily price history. It lists specific strategies (sma_cross, rsi_reversion, macd_cross) and distinguishes from sibling tools like run_portfolio_backtest by emphasizing simplicity and single-ticker focus.
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 simple single-ticker backtests, contrasting with more complex portfolio backtests (run_portfolio_backtest). However, it does not explicitly state when not to use or name alternatives, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
build_monthly_universeAInspect
Rank a universe of tickers by monthly dollar volume with trailing returns. Resolves either a named universe (SP500, TSX) or an explicit tickers override, bulk-fetches daily OHLCV over range, resamples each to monthly bars (open=first, high=max, low=min, close=last, volume=sum), and per ticker computes trailing returns over 1/3/6/12 periods plus the latest monthly dollar volume (close * volume). Tickers are ranked by latest dollar volume (descending) and the top top_n are returned. Tickers that fail to fetch or lack enough monthly history are skipped and noted in warnings. range is the lookback (5d,1mo,3mo,6mo,1y,2y,5y,max; default 2y); use a multi-year window so the 12-month horizon is well-defined. values holds range, as_of (latest monthly date, YYYY-MM-DD), count, and results — a ranked list of {ticker, dollar_volume, returns: {1m,3m,6m,12m}, rank} where any horizon longer than the available history is null.
| Name | Required | Description | Default |
|---|---|---|---|
| range | No | ||
| top_n | No | ||
| tickers | No | ||
| resample | No | ||
| universe | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully discloses behavioral traits: it fetches daily OHLCV, resamples to monthly bars, computes trailing returns for 1/3/6/12 periods, ranks by dollar volume, and skips failed tickers with warnings. 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 somewhat lengthy but well-structured, starting with a clear purpose sentence followed by detailed logic. Every sentence adds value, though it could be slightly more concise without losing clarity.
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 no output schema, the description comprehensively explains the output structure (range, as_of, count, results) and each result's fields. The tool's complexity is fully addressed for selection and 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 description coverage is 0%, but the description explains all 5 parameters: range (enum with default and advice), top_n, tickers (explicit override), resample (enum), and universe. It adds meaningful usage guidance beyond the enum values.
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: 'Rank a universe of tickers by monthly dollar volume with trailing returns.' It identifies the specific verb (rank), resource (universe of tickers), and output criteria, distinguishing it from sibling tools like backtest or screen.
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 detailed usage context, including how to specify the universe (named or explicit tickers), the importance of a multi-year window for 12-month returns, and the resampling behavior. However, it does not explicitly exclude alternative tools or specify when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_tickersAInspect
Rank two or more tickers against each other by a single metric (total_return, volatility, sharpe, max_drawdown, last_price). Symbols that cannot be resolved (or lack enough history) are skipped and noted in warnings rather than failing the call. Returns a ranked list of {ticker, value, rank, currency} (rank 1 = best).
| Name | Required | Description | Default |
|---|---|---|---|
| range | No | 1y | |
| metric | No | total_return | |
| tickers | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must cover behavioral traits. It discloses that unresolved symbols are skipped and noted in warnings rather than causing failure, and describes the return format. However, it does not mention data freshness, rate limits, or side effects.
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, front-loaded with purpose, no redundant information. 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?
Given the tool's moderate complexity and lack of output schema, the description provides essential input validation behavior, output structure, and error handling. It is nearly complete but could mention range options explicitly.
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 description must compensate. It lists the possible values for metric and explains ticker handling, but does not describe the range parameter beyond default values. This adds partial meaning but leaves 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 tool ranks two or more tickers by a single metric, listing the available metrics. This distinguishes it from siblings like screen or compute_stats which have 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 it versus alternatives like screen_with_scores or backtest. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compute_correlation_matrixAInspect
Compute the pairwise return-correlation matrix for a list of tickers. Fetches each ticker's daily history over range, converts it to daily returns, and computes the pairwise Pearson correlation (aligned on shared dates). Requires at least two tickers; tickers that cannot be fetched are dropped and noted in warnings (at least two must survive). Returns the standard envelope; values holds range, the tickers used, and matrix — a nested dict {rowTicker: {colTicker: correlation}} with a 1.0 diagonal.
| Name | Required | Description | Default |
|---|---|---|---|
| range | No | ||
| tickers | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: fetching daily history, converting to returns, computing Pearson correlation on shared dates, dropping unfetchable tickers, and requiring at least two survivors. It also details the output envelope structure.
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 a single efficient paragraph, front-loaded with the main purpose. Every sentence adds necessary detail 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?
Given no output schema, the description thoroughly explains the return envelope, including structure for range, tickers, and matrix. It covers all relevant aspects for a tool of this 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?
Schema coverage is 0%, so the description compensates by explaining 'range' as daily history and 'tickers' as the list. However, it does not specify the default range when omitted, leaving a minor 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 it computes a pairwise return-correlation matrix for a list of tickers. It uses a specific verb ('Compute') and resource ('return-correlation matrix'), distinguishing it from siblings like 'compute_indicator' or 'compute_stats'.
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 computing correlation from ticker histories but does not explicitly state when not to use or provide alternatives. The context of sibling tools offers differentiation, but the description itself lacks exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compute_indicatorAInspect
Compute a technical indicator (RSI, MACD, SMA, EMA, BBANDS, ATR, ADX, STOCH) over a ticker's price history. Returns the warmup-aligned series plus the latest values and a one-line summary. Tune the window with length (SMA/EMA/RSI/ATR/ADX/BBANDS), fast/slow/signal (MACD), std (BBANDS), or k/d/smooth_k (STOCH) — pass them either as top-level fields OR nested under params; both work. window and period are accepted as aliases for length. NOTE: for a long window like SMA(200) you MUST set length=200 (the default is 20). The response echoes the effective params it used, and the summary shows the window, e.g. SMA(200). Ensure range spans at least length bars (e.g. range=2y for SMA(200)) or the series is all-warmup NaN.
| Name | Required | Description | Default |
|---|---|---|---|
| d | No | ||
| k | No | ||
| std | No | ||
| fast | No | ||
| slow | No | ||
| range | No | 1y | |
| length | No | ||
| params | No | ||
| period | No | ||
| signal | No | ||
| ticker | Yes | ||
| window | No | ||
| interval | No | 1d | |
| smooth_k | No | ||
| indicator | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses return components (series, latest values, summary), explains the warmup NaN scenario for insufficient range, and notes that effective params are echoed. This provides good behavioral insight beyond just the tool name.
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 moderately long but packs valuable information without redundancy. It starts with purpose, then parameter details, then important notes. Could be slightly tightened, but every sentence adds value. The structure is logical and 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 15 parameters (2 required), no output schema, and no annotations, the description covers the tool's usage comprehensively. It explains return format, edge cases (all NaN), parameter defaults, and indicator-specific tuning. This is sufficient for an agent to use the tool effectively.
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%, requiring full compensation from description. The description explains all key parameters (length, fast/slow/signal, std, k/d/smooth_k), their aliases (window/period), defaults (length=20, range=1y, interval=1d), and the dual-pass style (top-level or nested params). This exceeds what the schema alone provides.
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 computes technical indicators (RSI, MACD, etc.) over a ticker's price history, listing all supported indicator types. The verb 'compute' and resource 'technical indicator' are specific and the tool purpose is distinct from siblings like get_price_history or compute_stats.
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 usage context such as tuning parameters per indicator and ensuring range length, but does not explicitly state when not to use this tool or compare it to alternatives. It lacks direct guidance on choosing between compute_indicator and other computation tools in the sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compute_portfolio_statsAInspect
Compute portfolio-level statistics for a weighted basket of tickers. Given a {ticker: weight} mapping, fetches each ticker's daily history over range and returns the portfolio-level (not per-ticker) volatility, sharpe, max_drawdown and total_return of the weighted basket. weights need NOT sum to 1 (normalized internally). Tickers that cannot be fetched are dropped, a note is added to warnings, and the remaining weights are renormalized. risk_free_rate is an annual rate used only by Sharpe. Returns the standard envelope; values holds range, the normalized weights used, and the stats dict.
| Name | Required | Description | Default |
|---|---|---|---|
| range | No | ||
| weights | Yes | ||
| risk_free_rate | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden and discloses key behaviors: fetches daily history, normalizes weights internally, drops unfetchable tickers with warnings, and risk_free_rate used only for Sharpe. It does not cover auth needs, rate limits, or data source, but provides sufficient transparency for safe use.
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?
Description is concise but comprehensive, front-loading the main purpose and then detailing behaviors. Each sentence adds value, though slight verbosity in explaining normalization and warnings could be trimmed.
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 tool complexity (portfolio stats, error handling, normalization), description covers most aspects. It describes return structure (range, weights, stats dict) but does not specify exact keys or explain 'standard envelope'. Minor gaps but overall complete enough.
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 description must explain parameters. It describes weights as a mapping that need not sum to 1, range as a time period (though enum values not repeated), and risk_free_rate as annual rate for Sharpe. This adds meaning beyond schema, especially the normalization and error handling notes.
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 computes portfolio-level statistics for a weighted basket of tickers. It specifies outputs (volatility, sharpe, max_drawdown, total_return) and input structure (ticker: weight mapping), distinguishing it from sibling tools like compute_stats (single ticker) or compute_correlation_matrix.
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 tells when to use (portfolio-level stats from weighted basket) and provides usage details like weight normalization, error handling, and risk_free_rate purpose. It does not explicitly list when not to use, but the context of siblings implies alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compute_statsAInspect
Compute quantitative statistics (volatility, sharpe, max_drawdown, returns, beta, correlation) over a ticker's daily price history. Omit metrics to default to volatility/sharpe/max_drawdown/returns. beta and correlation require a benchmark ticker; risk_free_rate is used only by the Sharpe ratio.
| Name | Required | Description | Default |
|---|---|---|---|
| range | No | 1y | |
| ticker | Yes | ||
| metrics | No | ||
| benchmark | No | ||
| risk_free_rate | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the tool computes stats from daily price history, but does not mention rate limits, data freshness, error handling, or whether it is read-only. It is adequate but could be more transparent about behavior and 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?
Two sentences that efficiently convey purpose, default behavior, and parameter dependencies. No redundant or extraneous information 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 complexity (5 parameters, no output schema, no annotations), the description covers core functionality and dependencies. However, it does not mention output format, source of price data, or what happens on missing data. Most information needed for correct invocation is present.
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%, yet the description adds significant meaning: explains the metrics enum values, default behavior when metrics omitted, dependencies (beta/correlation need benchmark), and risk_free_rate only for Sharpe. This goes well beyond the schema's type definitions.
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 explicitly states the tool computes quantitative statistics (volatility, sharpe, max_drawdown, returns, beta, correlation) over a ticker's daily price history, which is a specific verb+resource. It distinguishes from siblings like compute_correlation_matrix by listing unique metrics and dependencies.
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 usage context: default metrics, conditions for beta/correlation (require benchmark), and risk_free_rate only for Sharpe. However, it lacks explicit guidance on when not to use this tool compared to alternatives like compute_correlation_matrix or compute_portfolio_stats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compute_universe_scoresAInspect
Score and rank a universe of tickers by a cross-sectional signal. Resolves either a named universe (SP500, TSX) or an explicit tickers override, bulk-fetches daily price history over range, computes a raw per-ticker score for the chosen signal, then converts those raw scores into cross-sectional z-scores and ranks them across the universe (rank 1 = highest z-score). Signals (Jegadeesh–Titman momentum is 12-month minus 1-month return on month-end resampled closes): jt_momentum (that JT 12-1 momentum), mean_reversion (negative trailing 1-month monthly return), rsi_filtered_momentum (JT momentum, names with a 14-day simple RSI > 70 excluded before z-scoring), trend_quality (JT momentum, names trading at or below their 200-day SMA excluded). Tickers with too little history or that fail to fetch are dropped and reported in warnings. range is the lookback (5d,1mo,3mo,6mo,1y,2y,5y,max; default 2y); top_n truncates the ranked output. values holds universe, signal, range, scored, and results (a list of {ticker, raw, zscore, rank} ordered by rank).
| Name | Required | Description | Default |
|---|---|---|---|
| range | No | ||
| top_n | No | ||
| signal | No | ||
| tickers | No | ||
| universe | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses key behaviors: bulk-fetches daily price history, computes raw scores, converts to z-scores/ranks, drops tickers with insufficient history, and reports warnings. Signal formulas are explained. The description does not mention potential side effects (e.g., rate limits), but for a compute-only tool this is acceptable.
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 packed with information but remains readable and front-loaded with the primary action. Every sentence adds value. However, it could be slightly more structured (e.g., listing parameters separately) to improve scanability for an AI agent.
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 fully explains the return structure ('values holds universe, signal, range, scored, and results'). It covers all parameters, behaviors, signal formulas, and output shape. The agent has sufficient information to invoke and interpret results.
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 description must compensate. It adds meaning: explains 'range' as lookback with enumerated values, 'top_n' truncation, and details four signal definitions. However, parameter descriptions are embedded in prose rather than structured per-parameter, missing explicit tie to each property like 'tickers' or 'universe'.
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: 'Score and rank a universe of tickers by a cross-sectional signal.' It specifies input options (universe or tickers), the process (fetch price history, compute scores, z-scores, ranks), and output structure. This verb-resource combination is specific and distinguishes it from sibling tools like 'screen' or 'compute_stats'.
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 cross-sectional scoring/ranking but does not explicitly specify when to use this tool vs alternatives like 'screen_with_scores' or 'compute_stats'. No when-not-to-use or alternative guidance is provided, leaving the agent to infer context from sibling names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
construct_portfolioAInspect
Turn a {ticker: score} mapping into long-only portfolio weights. Selects names and assigns non-negative weights that sum to 1.0 using the chosen method: top_n_weighted (weight by clipped score), equal_weight, risk_parity (inverse-volatility), concentrated_vol (highest-vol from a top-score pool), or sharpe_optimized (max-Sharpe long-only). The last three fetch daily history over range (5d,1mo,3mo,6mo,1y,2y,5y,max) and convert it to returns; tickers that fail to fetch are dropped with a warning. Returns the standard envelope; values holds method, top_n, a weights map, and n_holdings.
| Name | Required | Description | Default |
|---|---|---|---|
| range | No | ||
| top_n | No | ||
| method | No | ||
| scores | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: long-only constraint, non-negative weights summing to 1, history fetching for three methods, dropping of failed tickers with a warning, and return envelope contents. It does not mention any side effects or authorization needs, but the behavior is adequately described.
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 a single efficient paragraph that front-loads the core purpose and then details methods and returns. It is dense but not wasteful; however, it could be slightly more structured (e.g., bullet points) for easier parsing.
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 moderate complexity (4 params, methods, history fetching), the description covers inputs, behavior, and return values. It lacks details on error handling beyond failed fetch and does not clarify 'standard envelope', but overall suffices for selection and 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?
Despite 0% schema description coverage, the description compensates by explaining the 'scores' parameter as a mapping, listing method options with meanings, implying the 'range' parameter via history fetching context, and mentioning 'top_n' in method descriptions and return value. It adds meaning beyond the schema's raw enums and nested object.
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 converts a ticker-score mapping to long-only portfolio weights summing to 1.0, enumerates the five methods with brief explanations, and distinguishes it from sibling tools like backtest or compute_portfolio_stats by focusing on weight construction.
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 the tool is used when you have scores and want weights, but it does not explicitly state when to use it versus siblings or provide criteria for choosing among the methods. 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.
detect_signalsAInspect
Detect classic technical-analysis signals on a ticker's price history. Each requested signal is evaluated and reported as triggered/not-triggered with a date and human-readable detail under signal_summary. Signals (omit signals to check all six): golden_cross = SMA(50) crosses above SMA(200) within lookback; death_cross = SMA(50) crosses below SMA(200); macd_cross = MACD line crosses above its signal line (bullish); rsi_oversold = RSI(14) below 30 at the latest bar; rsi_overbought = RSI(14) above 70 at the latest bar; breakout = latest close exceeds the highest high of the prior 20 bars. A signal needing more history than is available is returned not-triggered with an insufficient-history detail and a warning — it never fails the call.
| Name | Required | Description | Default |
|---|---|---|---|
| range | No | ||
| ticker | Yes | ||
| signals | No | ||
| interval | No | ||
| lookback | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description thoroughly explains that signals are reported as triggered/not-triggered with date and detail under signal_summary, and that insufficient history returns a warning without failing. No annotations are provided, so the description fully carries the behavioral burden.
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, front-loading the purpose, then listing each signal with concise definitions. It is efficient but could be slightly more compact without losing clarity.
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 5 parameters, no output schema, and no annotations, the description covers the primary behavior and signal definitions well. However, it omits the effect of 'range' and 'interval' on signal computation, and does not detail the full output format beyond 'signal_summary'.
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 must compensate. It explains the 'signals' parameter and its default, and the 'lookback' parameter in the context of cross signals. However, it does not explain 'range', 'interval', or 'lookback' for non-cross signals, leaving gaps.
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 detects classic technical-analysis signals on a ticker's price history. It lists all six signals with specific definitions, distinguishing it from sibling tools like compute_indicator or screen.
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 how to request specific signals (or omit to check all six) and the behavior when history is insufficient. However, it does not explicitly contrast with alternatives like compute_indicator or screen, though the context is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_fundamentalsAInspect
Get fundamental data for a ticker (profile + key ratios). US symbols are bare (AAPL); TSX symbols use the Yahoo .TO form (RY.TO) or the TSX:RY form. Returns an envelope whose values holds available fundamentals: name, exchange, currency, sector, industry, market_cap, pe_ratio, forward_pe, eps, dividend_yield, beta, fifty_two_week_high, fifty_two_week_low, asof. Fields not covered by the provider are null.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It details the return structure, lists fields, and states null for uncovered fields. It does not mention read-only nature or rate limits, but the action implies read operation.
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 three sentences long, front-loaded with purpose, and every sentence adds value: purpose, ticker formatting, and output fields. 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 single-parameter tool with no output schema, the description covers the purpose, parameter usage, and return fields comprehensively. It lacks error handling but is sufficient for standard use.
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 explains the ticker parameter, including US and TSX forms. It adds meaningful context beyond the schema's type-only definition.
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 gets fundamental data for a ticker, specifying profile and key ratios. It distinguishes from siblings like get_quote and get_price_history by focusing on fundamentals. The verb 'Get' and resource 'fundamental data' 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?
Provides explicit instructions on ticker formatting for US and TSX symbols, which helps agents avoid common errors. However, it does not compare to alternatives or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_price_historyAInspect
Get historical OHLCV price bars for a ticker. US symbols are bare (AAPL, MSFT); TSX symbols use the Yahoo .TO form (RY.TO) or the TSX:RY form. interval is one of 1m,5m,15m,30m,1h,1d,1wk,1mo (default 1d); range is one of 5d,1mo,3mo,6mo,1y,2y,5y,max (default 1y). Returns an envelope whose values contains interval, range, currency, count, and bars (records with an ISO timestamp plus open, high, low, close, volume).
| Name | Required | Description | Default |
|---|---|---|---|
| range | No | ||
| ticker | Yes | ||
| interval | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavior. It describes the return envelope and bar structure, but does not explicitly state this is a read-only operation or mention side effects. The description is adequate but not comprehensive.
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 at two sentences, covering purpose, ticker formats, parameter defaults, and return structure. It could be slightly more structured (e.g., bullet points) but is 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 3 parameters, no output schema, and no annotations, the description is fairly complete: it explains inputs and output envelope fields. However, it could mention the tool is non-destructive and safe to use.
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 explain all parameters. It does so thoroughly: ticker format, interval enum values with default, range enum values with default. This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves historical OHLCV price bars for a ticker, differentiating it from siblings like get_quote (single point) or run_portfolio_backtest. It specifies verb 'Get' and resource 'historical OHLCV price bars'.
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 usage details such as ticker format (bare vs .TO/TSX:), default interval and range, but does not explicitly state when to use this tool over alternatives like get_quote or screen.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_quoteAInspect
Get the latest available quote for a ticker. US symbols are bare (AAPL); TSX symbols use the Yahoo .TO form (RY.TO) or the TSX:RY form. Returns an envelope whose values holds the quote fields (price, currency, previous_close, change, change_percent, volume, market_state, asof as an ISO string).
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It implies a read-only operation by stating 'Get' and describes the return envelope, but it does not explicitly confirm no side effects, authentication needs, or rate limits. The description is adequate but not fully transparent.
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 brief yet complete, consisting of two sentences. The first states the purpose, the second covers parameter format and return structure. No extraneous text, 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?
Given the tool's simplicity (single parameter, no output schema, no annotations), the description covers the essential aspects: purpose, ticker format, and return fields. It lacks information about error handling or market state details, but overall it is sufficient for correct usage.
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 one parameter 'ticker' with no description (0% coverage), but the tool description adds rich semantic information about acceptable formats (bare, .TO, TSX: prefix), which is critical for correct usage and fully compensates for the missing schema description.
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: 'Get the latest available quote for a ticker.' This is a specific verb+resource, and it distinguishes itself from siblings like get_price_history or get_fundamentals, which serve different data needs.
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 crucial formatting guidelines for ticker symbols (US bare, TSX .TO or TSX: form), which aids correct invocation, but it does not explicitly state when to use this tool versus alternatives or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
run_portfolio_backtestAInspect
Backtest a rebalanced, multi-ticker, long-only quant portfolio. Fetches daily history for every ticker over range, then runs a walk-forward simulation: at each period-end rebalance the chosen signal (jt_momentum, mean_reversion, rsi_filtered_momentum, trend_quality) scores each name using only data up to that date, and method turns those scores into long-only weights. Returns gross and net (after cost) performance. rebalance is M (monthly) or Q (quarterly); cost_bps is round-trip cost on turnover; benchmark drives the hit-rate metric and (with crash_filter) a regime filter holding cash when the benchmark trailing-12m return is negative. Returns the standard envelope; values holds equity_curve, rebalances, metrics, holdings and the echoed parameters.
| Name | Required | Description | Default |
|---|---|---|---|
| range | No | ||
| top_n | No | ||
| method | No | ||
| signal | No | ||
| tickers | Yes | ||
| cost_bps | No | ||
| benchmark | No | ||
| rebalance | No | ||
| crash_filter | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full disclosure burden. It explains the walk-forward simulation, rebalancing process, and returns structure. However, it does not explicitly state that no data is mutated, which is a minor gap for a compute-only tool.
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 efficient and front-loaded, but the middle section listing all signal and method enum values could be slightly more concise. Overall, 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?
Given the complexity (9 parameters, no output schema or annotations), the description covers the tool's purpose, process, inputs, and output envelope. It lacks error or edge-case explanations but is sufficient for a typical use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the schema for most parameters (e.g., explains cost_bps, benchmark, crash_filter behavior, lists enum values for signal and method). It omits explicit mention of 'range' options and 'top_n' but provides context for the core parameters.
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 begins with a specific verb and resource: 'Backtest a rebalanced, multi-ticker, long-only quant portfolio.' It clearly distinguishes from the sibling 'backtest' by specifying multi-ticker, signal-driven walk-forward simulation.
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 the intended use case (advanced quant backtesting with multiple tickers and signals) but does not explicitly state when to avoid it or contrast it with alternatives like the simpler 'backtest' sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
screenCInspect
Screen a stock universe for tickers matching quantitative filters (logical AND). Fields: price, rsi, sma_50, sma_200, volatility, sharpe, max_drawdown, total_return, dollar_volume, garman_klass_vol. Ops: lt, lte, gt, gte.
| Name | Required | Description | Default |
|---|---|---|---|
| range | No | 1y | |
| filters | Yes | ||
| sort_by | No | ||
| universe | Yes | ||
| max_tickers | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose behavioral traits like rate limits, authentication, or what happens with no results. Only states screening mechanism.
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?
One sentence plus lists. Efficient but could be better structured with separate lines for parameters and examples.
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?
5 parameters, no output schema, no annotations. Missing explanation of outputs, default sort, and filter combination logic beyond 'AND'.
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 0%. Description mentions fields and ops for filters but does not explain range, sort_by, max_tickers, or default behaviors. Incomplete compensation.
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?
Describes screening a universe with logical AND filters, listing fields and ops. Clear verb and resource, but does not distinguish from sibling 'screen_with_scores'.
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 screen_with_scores. No context on prerequisites or intended use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
screen_with_scoresBInspect
Rank a stock universe by a continuous cross-sectional signal score (rank 1 = highest z-score). Signals: jt_momentum, mean_reversion, rsi_filtered_momentum, trend_quality. Scores are relative to the scanned set.
| Name | Required | Description | Default |
|---|---|---|---|
| range | No | 2y | |
| top_n | No | ||
| signal | No | jt_momentum | |
| universe | Yes | ||
| max_tickers | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains scoring is relative and rank 1 is highest z-score, but lacks details about output format, handling of ties, or the effect of parameters like max_tickers.
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 two sentences, front-loaded with the action and resource, and includes essential details (signals, rank interpretation) without 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 the lack of output schema and 5 parameters with 0% coverage, the description is incomplete. It does not describe what the tool returns (e.g., a ranked list with scores), limiting an agent's ability to use 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?
Schema description coverage is 0%, and the description does not elaborate on any parameter meanings beyond what the schema provides (enums, defaults). For example, it doesn't explain that 'range' is a lookback period or that 'universe' is required.
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 ranks a stock universe by a continuous cross-sectional signal score, specifying the ranking criterion (z-score) and listing the available signals. This distinguishes it from siblings like 'screen' or 'compute_universe_scores'.
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 guidance is provided on when to use this tool over siblings such as 'screen' or 'compute_universe_scores'. There is no mention of use cases, prerequisites, or alternatives.
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!