Crypto backtesting tools: real backtests with robustness verdicts, daily signals and market data.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.2/5 across 11 of 11 tools scored.
Each tool has a clearly distinct purpose: statistical checks, strategy comparison, historical returns, live signals, DCA, overfitting index, strategy listing, dataset query, backtesting, Q&A search, and glossary. No overlap in functionality.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., check_overfitting, run_backtest, search_glossary). No mixing of conventions.
11 tools is well-scoped for a crypto backtesting server, covering the full workflow from strategy selection, backtesting, overfitting analysis, to educational queries without excess or deficiency.
The tool set covers core backtesting, overfitting diagnostics, data retrieval, and knowledge base searches. Minor gaps like strategy modification or saving results are present, but the main lifecycle is complete.
check_overfittingACompute the Deflated Sharpe Ratio (Bailey & Lopez de Prado 2014) for YOUR OWN backtest: given its annualised Sharpe, length, and how many strategy variants you tried before selecting it, returns the probability the result is real skill rather than selection luck, the luck bar it must clear, and a plain verdict. Works on any backtest, not just ours.
| Name | Required | Description | Default |
|---|---|---|---|
| skew | No | Skewness of the return series (default 0). | |
| sharpe | Yes | Annualised Sharpe ratio of the selected backtest. | |
| kurtosis | No | Non-excess kurtosis of returns (Gaussian = 3, the default). | |
| n_trials | Yes | How many strategy/parameter variants were tried before picking this one. | |
| timeframe | No | Bar timeframe of the returns (default 1d). | |
| length_days | Yes | Length of the backtest in calendar days. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true; description adds what it returns (probability, luck bar, verdict) and the statistical method used. 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?
Two sentences, front-loaded with the metric name and purpose, then scope. Every word 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?
Explains input, output, and scope. With 6 parameters fully described in schema, the description adds sufficient context. Missing details like probability range and verdict format are minor given the tool's statistical nature.
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 100% with descriptions for each parameter. The description mainly reinforces that information (annualised Sharpe, length, trials) without adding new parameter-level detail, so baseline 3 is appropriate.
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 the Deflated Sharpe Ratio for a backtest, returning probability of skill vs luck and a verdict. Distinguishes from siblings by emphasizing it works on any backtest and quantifying selection bias.
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?
Explicitly says 'for YOUR OWN backtest' and 'works on any backtest', implying when to use it. Does not explicitly state when not to use or list alternatives, but the context makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_strategiesAHead-to-head comparison of two strategy templates from real monthly engine runs across ~50 coins: per-coin win count, median out-of-sample Sharpe, survival counts, median return and drawdown. Use strategy names from list_strategies (e.g. 'super_trend', 'ema_crossover').
| Name | Required | Description | Default |
|---|---|---|---|
| strategy_a | Yes | First strategy name, e.g. super_trend | |
| strategy_b | Yes | Second strategy name, e.g. ema_crossover |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description doesn't need to re-state safety. It adds valuable context about the data source (real monthly engine runs) and output metrics, enhancing transparency beyond the 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 concise sentences: first states the purpose and scope, second lists the metrics. No wasted words or redundant 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?
The description covers the tool's function, data source, and output metrics. Given no output schema, listing the metrics is sufficient. It does not explain aggregation details, but overall completeness is adequate for a comparison 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 coverage is 100%, providing a baseline of 3. The description adds value by giving concrete examples ('super_trend', 'ema_crossover') and directing users to list_strategies for valid names, which significantly aids parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs head-to-head comparisons of strategy templates, specifying the data source (real monthly engine runs across ~50 coins) and the exact metrics computed (win count, Sharpe, survival counts, return, drawdown). It distinguishes itself from siblings like list_strategies by referencing it as the input source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using strategy names from list_strategies, providing clear context for input selection. While it doesn't explicitly state when to avoid using this tool or suggest alternatives, the reference to a sibling tool gives implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_buy_holdAWhat a $1,000 buy of a coin on Jan 1 of each available year would be worth today — ROI, peak value and date, and the maximum drawdown endured along the way. Real Binance data, refreshed daily.
| Name | Required | Description | Default |
|---|---|---|---|
| coin | Yes | Lower-case ticker, e.g. btc, eth, sol. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds that data is 'Real Binance data, refreshed daily,' which goes beyond the readOnlyHint annotation by indicating the data source and freshness. However, it does not disclose any limitations or additional behavioral traits like rate limits or error conditions.
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 the key outcome (what a $1,000 buy would be worth today) and additional details. Every sentence serves a purpose, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description adequately explains the return values (ROI, peak, max drawdown) and data source. No missing information for effective 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 100%, and the description does not add new meaning to the coin parameter beyond the schema's 'Lower-case ticker' description. Baseline 3 is appropriate as the description adds no extra semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool computes buy-and-hold performance for a $1,000 investment on Jan 1 each year, including ROI, peak, and max drawdown. This is specific to the resource and verb, and distinct from sibling tools like get_dca or run_backtest.
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 versus siblings such as get_dca or compare_strategies. The description implies a specific use case (buy-and-hold analysis) but does not provide context for alternative tools or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_coin_signalsAToday's daily-bar indicator readings for crypto coins, computed by a real backtesting engine from Binance closes: price, RSI-14, MACD state, SMA 50/200 posture, SuperTrend, Bollinger position, ATR volatility, 52-week range. Pass a coin ticker (e.g. 'btc') for one coin, or omit for the whole 50-coin board.
| Name | Required | Description | Default |
|---|---|---|---|
| coin | No | Lower-case ticker, e.g. btc, eth, sol. Omit for all coins. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description adds value by detailing the computation origin (real backtesting engine from Binance closes) and listing all indicators, providing context beyond the annotation.
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 concise sentences front-load the primary purpose and immediately provide actionable usage details, with no redundant 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?
Despite no output schema, the description fully conveys the returned data (a list of indicators for one or many coins), which is sufficient for a simple data retrieval tool with one optional parameter.
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 100% with a single parameter; the description adds practical examples ('e.g. btc') and clarifies the behavior when the parameter is omitted, exceeding the schema's 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 explicitly states the tool provides 'Today's daily-bar indicator readings for crypto coins' and lists specific indicators, clearly distinguishing it from sibling tools like backtesting and strategy tools.
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 tells when to pass a coin ticker or omit it for all coins, but lacks explicit guidance on when not to use this tool or alternatives given sibling tools are mostly backtesting-related.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_dcaADollar-cost-averaging outcome for a coin: what buying a fixed dollar amount on a schedule (weekly or monthly) since a start date would be worth today — total invested, units, average cost, current value and ROI — plus the lump-sum comparison and the worst drawdown endured. Real Binance closes, refreshed daily.
| Name | Required | Description | Default |
|---|---|---|---|
| coin | Yes | Lower-case ticker, e.g. btc, eth, sol. | |
| amount | No | USD invested per purchase (default 100). | |
| frequency | No | Purchase cadence (default weekly). | |
| start_date | No | ISO date to start buying from, e.g. 2021-01-01 (optional; default = full history). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true (safe read). Description adds value by specifying data source ('Real Binance closes, refreshed daily') and confirming the tool only reports historical outcomes. No destructive behavior.
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 efficiently cover purpose, inputs, outputs, and data freshness. Front-loaded with key action and result set. No unnecessary 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?
No output schema exists, so description must fully document return values. It explicitly lists all returned metrics: total invested, units, average cost, current value, ROI, lump-sum comparison, worst drawdown. This is thorough for the tool's 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 description coverage is 100%, so baseline is 3. Description adds no extra semantics beyond what schema already provides (e.g., 'lower-case ticker' matches schema). Adequate but not enhanced.
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 specifies verb ('get'), resource ('DCA outcome for a coin'), and key parameters (fixed dollar amount, schedule, start date). It lists all output metrics including lump-sum comparison and drawdown, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs siblings like 'get_buy_hold' or 'compare_strategies'. Usage is implied by the DCA focus, but the agent receives no help with tool selection decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_overfitting_indexAThe Crypto Overfitting Index: the monthly share (%) of default-parameter strategy configurations (10 templates × 50 coins) whose out-of-sample Sharpe turned negative — how much of what backtests promise fails on unseen data. Returns the current reading and full history.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare read-only and open-world false. Description adds context on metric calculation and return value (current reading and history), beyond annotations. No behavioral 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?
Two sentences that are front-loaded with key information: what the metric is, methodology, and return value. No 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 no parameters, read-only annotations, and no output schema, the description sufficiently explains the tool's purpose and output (current reading and full history) with methodological context. Complete for this simple 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?
No parameters in schema; schema coverage is 100%. Baseline 4 applies as description adds meaning by explaining what the tool returns without needing parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the monthly share of default-parameter strategy configurations with negative out-of-sample Sharpe, specifying methodology (10 templates × 50 coins). It distinguishes from sibling 'check_overfitting' by focusing on a specific index.
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 'check_overfitting' or other siblings. The description implies usage for checking overfitting but lacks when-not or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_strategiesAList the strategy templates available for backtesting and comparison (name, title, one-line description). Use the returned name value as the strategy identifier in other tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already include readOnlyHint=true, so the description's mention of listing is consistent but adds minimal new behavioral insight beyond the return fields.
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 long, front-loaded with the main purpose, and includes a usage hint. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the key information: what the tool does and what it returns. For a simple read-only tool with no parameters and no output schema, this is nearly complete. Could mention ordering or rate limits, but not essential.
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 zero parameters, so no parameter documentation is needed. The description adds no parameter info, but the baseline for zero parameters is 4, which is appropriate here.
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 lists strategy templates available for backtesting and comparison, specifying what fields are returned (name, title, one-line description). This differentiates it from sibling tools like run_backtest and compare_strategies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to use the returned 'name' value as the strategy identifier in other tools, providing clear context for usage. No exclusions are given, but the tool's purpose is straightforward.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
query_datasetAQuery our open 11,440-run curve-fitting study (10 strategy templates x 20 coins, 70/30 in-sample/out-of-sample split). Returns the headline overfitting stats and the tuned picks matching an optional template and/or coin filter — each with in-sample vs out-of-sample Sharpe, the Sharpe haircut, and the in-sample-to-out-of-sample parameter rank correlation.
| Name | Required | Description | Default |
|---|---|---|---|
| coin | No | Ticker, e.g. btc (optional). Omit for all coins. | |
| template | No | Strategy name, e.g. super_trend (optional). Omit for all templates. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the read-only nature is known. The description adds valuable context beyond annotations: it explains the study design (11,440 runs, 10 templates, 20 coins, 70/30 split) and the specific metrics returned (in-sample vs out-of-sample Sharpe, haircut, rank correlation). This is comprehensive and consistent.
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 long: the first sets the context (study size and design), the second lists the output (headline stats and picks with specific metrics). Every sentence is necessary and informative, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only two optional simple parameters and no output schema, the description fully covers the return value structure (headline stats, tuned picks, Sharpe metrics, rank correlation). No additional context is needed for an agent to understand what will be returned.
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 100% and each parameter has a description. The description supplements the schema by providing concrete examples (e.g., 'btc' for coin, 'super_trend' for template) and clarifying that omitting either parameter returns all values. This adds practical value 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 queries a specific open curve-fitting study with 11,440 runs, returns overfitting stats and tuned picks, and can filter by optional template and/or coin. This directly distinguishes it from sibling tools like check_overfitting (which likely checks a single strategy) or compare_strategies.
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 retrieving overfitting stats and filtered picks but does not explicitly state when to use this tool versus alternatives (e.g., when to use check_overfitting instead). The context of 'query our open study' suggests it's for data retrieval, but no when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
run_backtestAInspectRun a real backtest of a strategy template on BTC/USDT from a start date (public what-if engine; may take up to a minute on a cache miss; rate-limited). Returns net return, max drawdown, trade count, a robustness score with an overfitting verdict, and a shareable result URL.
| Name | Required | Description | Default |
|---|---|---|---|
| strategy | Yes | Strategy name from list_strategies, e.g. super_trend | |
| start_date | Yes | ISO date, e.g. 2022-01-01 (2020-01-01 or later) | |
| starting_cash | No | Starting balance in USD (default 10000, max 1000000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral details beyond annotations: cache miss latency (up to a minute), rate limiting, and the nature of a 'public what-if engine'. It does not contradict annotations (readOnlyHint=false is consistent with a non-destructive execution that may produce results). However, it does not fully detail side effects or authentication needs.
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 well-structured sentence with a parenthetical for additional context. It is front-loaded with the main action and includes essential behavioral notes (cache, rate limit) and return value summary. No unnecessary 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 no output schema, the description fully enumerates the return fields (net return, max drawdown, trade count, robustness score, overfitting verdict, shareable URL). It also covers latency, rate limits, and the fixed trading pair. The tool's complexity is well-addressed for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, baseline is 3. The description adds value by specifying that the strategy comes from list_strategies, that the trading pair is BTC/USDT, and that the backtest is a 'real' execution on a public engine. These details augment the schema descriptions without redundancy.
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 'Run a real backtest', specifies the resource 'strategy template on BTC/USDT', and includes the action scope (start date). It distinguishes itself from siblings like check_overfitting or compare_strategies by being the dedicated backtesting tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implicit usage context (expected latency, rate limits) but does not explicitly state when to use this tool versus alternatives. There is no exclusion guidance or direct mention of sibling tools, requiring the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_answersASearch Noon Barbari's Q&A knowledge base of direct, data-grounded answers about backtesting, overfitting, validation, indicators, risk management and crypto markets. Returns the top matching questions with their full answers.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Free-text query, e.g. 'why do backtests fail' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds that it returns top matching questions with full answers but does not disclose details like result ordering, count limits, or pagination. Adequate but not rich.
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, no repetition or fluff. First sentence defines scope, second states return. Perfectly concise 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?
For a simple search tool with one parameter and no output schema, the description is nearly complete. It covers purpose and return value. Minor gaps: no mention of result count or ordering, but not critical.
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 covers the single parameter 'query' with full description. The description provides an example ('why do backtests fail') but does not add significant meaning beyond the schema. Baseline 3 due to high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches a specific Q&A knowledge base and returns top matching questions with answers. It uses specific verbs ('Search') and resources ('Noon Barbari's Q&A knowledge base'), distinguishing it from sibling tools like search_glossary or query_dataset.
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 questions about backtesting, overfitting, etc., but does not explicitly state when to use this tool vs alternatives or provide when-not guidance. Sibling tools exist but are not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_glossaryASearch Noon Barbari's trading glossary for a plain-language definition of an indicator, metric or concept (RSI, MACD, Sharpe ratio, drawdown, walk-forward, overfitting, and 60+ more). Returns the top matching terms with a short definition, the full explanation, and a link.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | A term or question, e.g. 'deflated sharpe' or 'what is RSI'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavioral context beyond annotations: returns top matching terms, short + full definitions, and link. Mentions glossary size (60+ terms). 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?
Two sentences with no redundant information. Front-loaded purpose, then returns format. Every word 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?
For a simple search tool with 1 parameter and no output schema, description fully covers purpose, scope, return structure, and examples. Complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and parameter description is clear. Description does not add new info about the parameter beyond the schema, but baseline 3 is appropriate.
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 uses specific verb 'Search' and resource 'glossary', provides examples (RSI, MACD, Sharpe ratio) and scope (plain-language definitions). Clearly distinguishes from siblings like search_answers and run_backtest.
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 usage for glossary definitions of trading terms but doesn't explicitly state when to use vs alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!