The alpha-forge-mcp server exposes the AlphaForge quantitative trading CLI to AI agents via the Model Context Protocol (MCP), enabling a full quant strategy development pipeline from data fetching to TradingView export.
Strategy Management
List, retrieve, and register trading strategies using their JSON definitions (list_strategies, get_strategy, save_strategy)
Apply optimization results to create optimized strategy variants (apply_optimization)
Backtesting & Results
Fetch and cache historical OHLCV market data (fetch_data)
Run backtests on historical data (run_backtest)
List and retrieve saved backtest results with metrics and trade data (list_results, get_result)
Optimization & Validation
Optimize strategy parameters using Optuna TPE for metrics like Sharpe, Sortino, Calmar, Win Rate, etc. (run_optimize)
Run walk-forward optimization for out-of-sample robustness (run_walk_forward)
Run Monte Carlo simulations to assess ruin probability, equity percentiles, and drawdown distribution (run_monte_carlo)
Export & Diagnostics
Generate TradingView Pine Script v6 from strategies (generate_pinescript)
Check system readiness and authentication status (forge_status)
Get metadata for technical indicators like RSI, MACD (get_indicator)
Journals & Exploration
Review strategy development history via journals (list_journals, get_journal)
View the optimization coverage map of explored vs. untried parameter combinations (exploration_status)
Key Design Features
All tools return a uniform error envelope ({ok, data, error}) for predictable error handling
Read-only tools are also exposed as MCP resources (forge://... URIs) for @-mention access
Long-running tools (backtesting, optimization, data fetching) report progress notifications
Built-in MCP prompts (backtest_and_review, optimize_and_verify) for guided workflows
Generates Pine Script v6 source code from AlphaForge strategies for use on TradingView.
Exports AlphaForge strategies to TradingView Pine v6 format for charting and automated trading.
The MCP server for AlphaForge — the agent-native quant CLI: write strategies in JSON, optimize with Optuna TPE, validate with walk-forward, export to TradingView Pine v6. This server lets your AI agent drive the whole pipeline over MCP. → Try AlphaForge free
A Model Context Protocol (MCP) server that exposes the
AlphaForge alpha-forge CLI to AI coding agents — Claude Code, Cursor, Codex, and any
MCP-capable client — over stdio.
It is a thin open-source wrapper: it shells out to the (commercial, closed-source)
alpha-forge binary with --json and returns the parsed result. The MCP server itself
contains no core logic — alpha-forge plus a valid license are required for anything to
actually run.
Tool | What it does | Underlying command |
| List registered strategies |
|
| Full JSON of one strategy |
|
| List saved backtest results |
|
| Metrics of one result (heavy arrays folded into counts by default; |
|
| Run a backtest ( |
|
| Optimize parameters (Optuna) |
|
| Apply an optimization result file to a strategy |
|
| Walk-forward (out-of-sample) optimization |
|
| Monte Carlo from a saved result |
|
| Fetch & cache historical OHLCV (prereq for |
|
| Register a strategy from its JSON body |
|
| Generate Pine Script v6 source |
|
| Report capabilities/prerequisites (doctor + version) |
|
| List strategies that have a journal |
|
| Full journal (snapshots, runs, tags, notes) of one strategy |
|
| Strategy-exploration coverage map (explored vs. untried) |
|
| Metadata for one technical indicator |
|
save_strategy takes the strategy-definition JSON body as a string (not a file path,
which is more agent-friendly); it is written to a temp file before strategy save.
fetch_data exposes only period because the CLI has no --start/--end. forge_status
is read-only and never fails when the binary is missing — it returns binary_found: false
so a client can triage prerequisites before doing anything else.
run_optimize saves the result by default (save=true) so its saved_path can be passed
to apply_optimization, which applies the optimized parameters and saves
<strategy_id>_optimized (it runs non-interactively with --yes). get_indicator returns
indicator metadata only (description, parameters, output) — the CLI has no
compute-over-symbol command, so it does not calculate the indicator on price data.
journal/explore reads are exposed read-first; write-oriented and ml/pairs commands are not
exposed yet.
The metric argument of run_optimize / run_walk_forward is a constrained enum
(sharpe_ratio (default), sortino_ratio, calmar_ratio, total_return_pct, cagr_pct,
profit_factor, win_rate_pct, expectancy_pct, omega_ratio) so clients can pick a
valid optimization target without guessing. This enum is intentionally narrower than the
alpha-forge CLI's --metric, which accepts a wider set — it is curated to the
bigger-is-better metrics that make sense as an optimization objective. trials defaults to
200 (the optimizer default). Each tool's description states its prerequisite (e.g.
run_backtest needs fetch_data first; apply_optimization needs a run_optimize(save=true)
result) and its follow-up.
Every argument also carries an inputSchema description, plus examples and
constraints where they help: symbol shows exchange notation (AAPL, ^VIX, CL=F,
USDJPY=X, BTC-USD), start / end advertise the YYYY-MM-DD pattern (format: date),
trials / windows / simulations carry minimum: 1, and save_strategy(json_body) /
apply_optimization(result_file) spell out "JSON body, not a path" vs "path, not inline
JSON". Malformed arguments are rejected at the MCP boundary by schema validation.
The text-only (non---json) CLI wrappers return structured fields rather than only
prose: apply_optimization adds applied_strategy_id (<strategy_id>_optimized, ready to
pass to generate_pinescript), save_strategy returns the registered strategy_id, and
fetch_data returns the fetched row count as rows (the raw output text is always kept).
The server advertises instructions (surfaced in the MCP initialize response) describing
the end-to-end workflow — forge_status → fetch_data → run_backtest → run_optimize
→ run_walk_forward → apply_optimization → generate_pinescript — so an agent knows
which tools to call and in what order.
The run/fetch/save/apply tools are long-running (run_backtest up to 300 s, run_optimize
/ run_walk_forward up to 600 s, others bounded by the default timeout — stated in each
tool's description). They report progress to capable clients via MCP progress
notifications (a start → complete bracket; the underlying alpha-forge subprocess does
not expose intermediate progress) and run the blocking call off the event loop so the
server stays responsive. The timeout is enforced by alpha-forge; on expiry the tool
returns the timeout error code, which is safe to retry.
All tools carry MCP tool annotations (readOnlyHint for the read tools — the list/
get lookups, generate_pinescript, forge_status, list_journals, get_journal,
exploration_status, and get_indicator; openWorldHint for the run/write tools —
run_backtest / run_optimize / run_walk_forward / run_monte_carlo, plus
fetch_data (fetches external market data), save_strategy and apply_optimization
(write to the DB)) and return structured output — structuredContent with an object
outputSchema — alongside the text result.
Every tool returns a uniform error envelope as its (always-successful) result rather than raising, so an agent can branch on the failure category mechanically instead of parsing free text:
Success: {"ok": true, "data": { ...alpha-forge JSON... }, "error": null}
Failure: {"ok": false, "data": null, "error": {"code": "<category>", "message": "<summary>", "detail": "<raw context>"}}
error.code is the machine-readable failure category — e.g. forge_not_found (binary
missing → guide setup), authentication_required (run alpha-forge system auth login),
freemium_blocked (premium-only feature → stop), strategy_not_found, timeout (safe to
retry), bad_output, execution_failed. error.message is a one-line summary; error.detail
carries the raw context (forge stderr or the de-decorated freemium panel body, including the
upgrade URL) when there is any, otherwise null. The outputSchema reflects this ok /
data / error shape.
Related MCP server: flox-mcp
Read-only data is also exposed as MCP resources, so clients such as Claude Code can
reference them by @-mention without an explicit tool call. They delegate to the same
alpha-forge commands as the read tools and return application/json.
Resource URI | Payload |
| All registered strategies |
| One strategy definition |
| All saved backtest results |
| Metrics & trades of one result |
| All strategies that have a journal |
| Full journal (snapshots, runs, tags, notes) of one strategy |
| Strategy-exploration coverage map (default goal) |
| Metadata for one technical indicator |
These mirror the read tools list_journals / get_journal / exploration_status /
get_indicator. There is no forge://indicators collection resource because the CLI's
indicator list is not wrapped as a tool/client method yet (only get_indicator is).
Reusable workflows are exposed as MCP prompts (surfaced as
/mcp__alpha-forge__<name> slash commands in Claude Code):
Prompt | Arguments | What it does |
|
| Run a backtest, then review the key metrics and red flags |
|
| Optimize with Optuna, then check the result for overfitting |
Streamable HTTP transport, RBAC, rate limiting, and audit logging are planned for a later release.
The alpha-forge binary must be installed and on your PATH (or set ALPHA_FORGE_BIN).
You must be authenticated: run alpha-forge system auth login once.
Python 3.11+ (only needed if not using uvx).
The recommended way is via uvx — no manual install needed;
your IDE launches it on demand.
uvx alpha-forge-mcp # starts the stdio MCP serverOr install explicitly:
pip install alpha-forge-mcp
alpha-forge-mcpThe easiest way is the claude mcp add command (user scope — available in every project):
claude mcp add --scope user alpha-forge -- uvx alpha-forge-mcpAlternatively, add the server to a project-scoped .mcp.json at the repository root
(checked in and shared with your team):
{
"mcpServers": {
"alpha-forge": { "command": "uvx", "args": ["alpha-forge-mcp"] }
}
}Note: Claude Code does not read
~/.claude/mcp.json. User-scoped servers are stored in~/.claude.json(managed byclaude mcp add); project-scoped servers live in.mcp.jsonat the project root.
Use the same command / args in the client's MCP server configuration:
{
"mcpServers": {
"alpha-forge": { "command": "uvx", "args": ["alpha-forge-mcp"] }
}
}If alpha-forge is installed at a non-standard location, pass it via env:
{
"mcpServers": {
"alpha-forge": {
"command": "uvx",
"args": ["alpha-forge-mcp"],
"env": { "ALPHA_FORGE_BIN": "/path/to/alpha-forge" }
}
}
}forge_not_found — ensure alpha-forge (or legacy forge) is on PATH, or set
ALPHA_FORGE_BIN=/path/to/alpha-forge.
authentication_required — run alpha-forge system auth login. The MCP server does
not store credentials; it relies on alpha-forge's own auth.
uv sync --extra dev
uv run pytest
uv run ruff check .Forge binary discovery order: ALPHA_FORGE_BIN → PATH (forge, alpha-forge) → OS
default install paths.
Apply an optimization result file to a strategy, saving <strategy_id>_optimized.
Prerequisite: run_optimize(save=true) — result_file is its `saved_path`. Runs
non-interactively (--yes). Returns {result_file, strategy_id, output}. Follow up by
generating Pine Script for `<strategy_id>_optimized`. Reports progress to capable
clients; has an execution timeout.
| Name | Required | Description | Default |
|---|---|---|---|
| result_file | Yes | ||
| strategy_id | Yes |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| data | Yes | |
| error | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate mutating but not destructive. The description adds important context: non-interactive (--yes), return shape {result_file, strategy_id, output}, progress reporting, execution timeout. 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?
Four sentences, front-loaded with purpose, no wasted words. Each sentence adds unique value: prerequisite, execution mode, return, follow-up.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 params and an output schema (mentioned return fields), the description covers prerequisites, execution behavior, and follow-up. No gaps given the simplicity.
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 0% description coverage, but the description fully explains both params: result_file is the saved_path from run_optimize, and strategy_id is implied from the prerequisite. This adds meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Apply an optimization result file to a strategy', specifies the naming convention for the output ('saves `<strategy_id>_optimized`'), and distinguishes this tool from siblings like run_optimize which produce the result file.
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?
Prerequisite is explicitly given: 'run_optimize(save=true) — result_file is its saved_path'. It also notes non-interactive execution and suggests follow-up with generating Pine Script. No explicit when-not-to-use, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the strategy-exploration coverage map (explored vs. untried combos).
Optional `goal` filters by exploration goal; defaults to the "default" goal.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | No |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| data | Yes | |
| error | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the agent knows this is a safe, repeatable read. The description adds that it returns a coverage map and that goal defaults to 'default'. This is adequate but does not disclose further behavioral traits (e.g., performance, auth limits) 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 front-loaded with the main action. No redundant words. Efficient use of text.
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 low complexity (1 optional param, no required params, output schema exists), the description is complete. It covers purpose, parameter behavior, and default. No critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains that 'goal' filters by exploration goal and defaults to 'default'. This adds meaning beyond the schema's type-only definition. However, it could be more specific (e.g., possible values, effect of null).
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: 'Show the strategy-exploration coverage map (explored vs. untried combos).' This is a specific verb-resource pair that distinguishes it from sibling tools like run_optimize or fetch_data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the optional goal parameter and its default, but does not provide explicit when-to-use guidance or comparisons with sibling tools. The context signals indicate many sibling tools, but the description offers no direction on when to choose exploration_status over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch & cache historical OHLCV for symbol (prerequisite for run_backtest).
period is e.g. 1y / 5y / 6m / 30d / max (defaults to 1y). Returns {symbol, period,
output}. The CLI has no --start/--end, so only period is exposed. Run this before
run_backtest. Reports progress to capable clients; has an execution timeout.
| Name | Required | Description | Default |
|---|---|---|---|
| period | No | ||
| symbol | Yes |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| data | Yes | |
| error | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavioral context beyond annotations: mentions caching, progress reporting, and execution timeout. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with main purpose, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, prerequisite, param details, behavioral notes; output schema exists so return format is sufficiently described.
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?
Provides specific examples and default for period, and clarifies no start/end parameters, adding significant value over the schema which has no descriptions and 0% 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?
Clearly states fetching and caching historical OHLCV for a symbol, and positions it as a prerequisite for run_backtest, distinguishing it from sibling 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?
Explicitly says to run this before run_backtest and explains that CLI has no start/end dates, but does not discuss explicit 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.
Report alpha-forge capabilities/prerequisites before use (doctor + version).
Read-only triage: returns {binary_found, version, authenticated, plan, doctor, error}.
Never fails when the binary is missing — returns binary_found=false instead.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| data | Yes | |
| error | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds the important behavioral detail that the tool never fails on missing binary, returning binary_found=false instead. It also outlines the return fields, enhancing transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two short paragraphs. Every sentence adds value: purpose, return structure, and edge-case behavior. 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?
With no parameters, a comprehensive description of behavior, failure mode, and return structure, plus relevant annotations, the description is fully adequate for an agent to correctly invoke and interpret the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema coverage is 100% (trivially). The description does not need to add parameter info, and it doesn't. Baseline is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: report alpha-forge capabilities and prerequisites before use. It specifies reading version and doctor status, and distinguishes itself from siblings by being a triage tool for pre-check.
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 advises using the tool 'before use' of alpha-forge, providing clear context. However, it does not explicitly mention when not to use it or compare with alternatives among siblings, which would make it a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate TradingView Pine Script v6 for a strategy. Returns {strategy_id, pinescript}.
| Name | Required | Description | Default |
|---|---|---|---|
| strategy_id | Yes | ||
| with_webhook | No |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| data | Yes | |
| error | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly and idempotent. Description confirms generation with no mutation, but adds no new behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with clear verb and output format. Could be slightly more structured but remains 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?
Basic overview is provided, but missing parameter explanations and usage context. Output schema exists but description doesn't detail return structure fully.
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 description does not explain parameters (e.g., what 'with_webhook' does). It only mentions strategy_id in output, not input semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates Pine Script v6 for a strategy and returns the script, distinguishing it from sibling tools like run_backtest or run_optimize.
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 on when to use this tool versus alternatives (e.g., for script generation before backtesting). No exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get metadata for a technical indicator (description, parameters, output, example).
`indicator` is the indicator name (e.g. RSI, MACD). This is metadata only — the CLI
has no compute-over-symbol command — so it does not run a calculation on price data.
| Name | Required | Description | Default |
|---|---|---|---|
| indicator | Yes |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| data | Yes | |
| error | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly and idempotent behavior. The description adds that the tool returns metadata (description, parameters, output, example) and does not run calculations. 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 core purpose, and no extraneous 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?
With an output schema present and a single parameter, the description covers what the tool returns and the input format. It fully addresses the tool's scope for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has no description for the 'indicator' parameter (0% coverage). The description adds meaning by stating it is the indicator name and gives examples (RSI, MACD), which is helpful for selecting the correct value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves metadata for a technical indicator, specifies the resource, and provides examples (RSI, MACD). It also explicitly clarifies what it does not do (compute calculations), leaving no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that this tool is only for metadata and does not compute, helping agents decide when not to use it. However, it does not explicitly name sibling tools as alternatives, though the context makes the distinction clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full journal (snapshots, runs, tags, notes) for a strategy_id.
| Name | Required | Description | Default |
|---|---|---|---|
| strategy_id | Yes |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| data | Yes | |
| error | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds value by specifying the contents (snapshots, runs, tags, notes) beyond what annotations provide. However, it does not disclose limitations 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?
Single sentence of 14 words, front-loaded with the main purpose. No extraneous information; every part is essential.
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 (1 parameter, no nested objects, output schema exists), the description is mostly complete. It lists the journal components, though it omits prerequisite conditions (e.g., strategy must exist) and does not clarify if the output is paginated.
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 one parameter (strategy_id) with 0% description coverage. The description merely restates that it is 'for a strategy_id' without explaining its format, source, or constraints, leaving the agent with insufficient semantic information.
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 action ('Get'), the resource ('full journal'), and the qualifier ('for a strategy_id'). It lists included components (snapshots, runs, tags, notes), distinguishing it from siblings like list_journals which likely provide a summary.
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 alternatives. While the description implies it is for detailed retrieval of a single strategy's journal, it does not mention exclusions or alternatives like list_journals or get_strategy.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get metrics and trades for a saved backtest result (result_id = strategy_id or run_id).
| Name | Required | Description | Default |
|---|---|---|---|
| result_id | Yes |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| data | Yes | |
| error | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, idempotentHint=true, and openWorldHint=false. The description adds context by specifying that the tool returns metrics and trades, which is beyond the annotations. It does not contradict 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?
A single, front-loaded sentence efficiently conveys the tool's purpose and the key parameter nuance. No superfluous 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 one parameter and an output schema (not shown), the description is minimal but sufficient for a simple retrieval tool. However, it lacks guidance on how this tool differs from siblings like get_strategy or list_results, which may be needed for correct selection.
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 carries the burden. It adds that result_id can be a strategy_id or run_id, providing some meaning beyond the schema. However, it does not specify format, constraints, or example values, leaving ambiguity.
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 'metrics and trades' for a saved backtest result, distinguishing it from sibling tools like get_strategy or list_results by specifying the resource and action. The parenthetical on result_id clarifies the valid identifier types.
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 that result_id can be a strategy_id or run_id, but does not explicitly state when to use this tool over alternatives like get_strategy or list_results. No exclusions or contextual cues for selection are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full JSON definition of a registered strategy by its strategy_id.
| Name | Required | Description | Default |
|---|---|---|---|
| strategy_id | Yes |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| data | Yes | |
| error | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds 'full JSON definition' but does not elaborate on behavior beyond that. It is consistent with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 11 words with no redundancy. It is appropriately concise for a simple get-by-ID operation.
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 presence of an output schema and the tool's simplicity (one parameter, no errors or prerequisites mentioned), the description is mostly sufficient. However, it could mention that the strategy must exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It only repeats the parameter name ('strategy_id') without adding format, source, or validation 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 action ('Get'), the resource ('full JSON definition of a registered strategy'), and the identifier ('by its strategy_id'). This distinguishes it from siblings like list_strategies and get_indicator.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a specific strategy's full definition is needed, but it provides no explicit guidance on when not to use it or how it compares to alternatives like list_strategies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List strategies that have a journal (history of snapshots and runs).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| data | Yes | |
| error | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description need not repeat. The description adds no extra behavioral details but is 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?
Single sentence, no unnecessary words, perfectly front-loaded. 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?
For a simple list tool with no parameters and an output schema, the description is complete. It states the input (none) and output (list of strategies with journals).
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 exist, so schema coverage is 100%. The description adds meaning by specifying what is listed (strategies with journals). Baseline for 0 params is 4, but the clarity elevates it.
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 lists strategies that have a journal, distinguishing it from siblings like list_strategies (all strategies) and get_journal (individual journal).
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 alternatives like list_strategies or get_journal, though the purpose implies selection. Usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List saved backtest results, optionally filtered by strategy_id.
| Name | Required | Description | Default |
|---|---|---|---|
| strategy_id | No |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| data | Yes | |
| error | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds that results are 'saved backtest results' and optional filtering, but does not disclose additional behavioral traits beyond annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It could be improved by adding a bit more detail without becoming verbose, but it is 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?
With an output schema present, the description doesn't need to explain return values. However, for a tool with many siblings, the description is minimal and could clarify what 'results' refer to (e.g., backtest summary metrics). Adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only mentions 'optionally filtered by strategy_id' without explaining what strategy_id represents or providing format/syntax details. This adds minimal 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 lists saved backtest results with optional filtering by strategy_id. It uses specific verb 'list' and resource 'saved backtest results', differentiating from 'get_result' (single) and 'list_strategies' (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 mentions optional filtering but provides no explicit guidance on when to use this tool versus alternatives like 'get_result'. Context implies listing multiple results, but no when-not or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all registered AlphaForge strategies (strategy_id, name, version, timeframe).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| data | Yes | |
| error | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description adds marginal value by listing returned fields. No behavioral traits beyond annotations are disclosed.
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?
Single sentence, front-loaded with action, no redundancy. 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?
Given no parameters, annotations cover safety, and there is an output schema, the description is complete. It tells what the tool returns, sufficient for an agent.
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 exist, and schema coverage is 100%. Baseline 4 is appropriate as description does not need to add parameter info.
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 'List', the resource 'registered AlphaForge strategies', and the specific fields returned. It distinguishes from sibling 'get_strategy' which presumably returns a single strategy's details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining an overview of all strategies. No explicit alternatives or when-not-to-use, but given the simplicity and no parameters, it's adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a backtest for symbol with a registered strategy. Optional dates are YYYY-MM-DD.
Prerequisite: call `fetch_data` for the symbol first so the OHLCV cache exists.
Long-running: up to a 300-second timeout; reports progress to capable clients.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | ||
| start | No | ||
| symbol | Yes | ||
| strategy_id | Yes |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| data | Yes | |
| error | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds useful behavioral info beyond annotations: mentions 300-second timeout and progress reporting. No contradiction with annotations (readOnlyHint=false, destructiveHint=false are consistent with run action).
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?
Three sentences, each adding distinct value: purpose, prerequisite, performance details. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers key aspects: required prerequisites, runtime behavior, and hints at return (via output schema). Missing details about error states or what happens if cache is missing, but generally sufficient.
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 adds some value (date format YYYY-MM-DD, lists required params) but does not fully explain each parameter's meaning or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it runs a backtest for a symbol with a registered strategy. However, does not distinguish from siblings like run_optimize or run_monte_carlo, which are different backtest variants.
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 a prerequisite (call fetch_data first) and mentions long-running behavior with timeout. But lacks guidance on when to use this vs. other backtest-related sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a Monte Carlo simulation from a saved backtest result (resamples its trades).
Prerequisite: a saved result (run_backtest/run_optimize with save) — result_id =
strategy_id or run_id. simulations defaults to 1000. Returns ruin probability, equity
percentiles, and drawdown distribution for risk assessment.
Long-running: reports progress to capable clients; has an execution timeout.
| Name | Required | Description | Default |
|---|---|---|---|
| result_id | Yes | ||
| simulations | No |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| data | Yes | |
| error | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavioral information beyond annotations: long-running, progress reporting, execution timeout. Annotations indicate non-readOnly and non-destructive, which the description complements without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, front-loaded purpose, then prerequisite, defaults, output, and behavioral notes. No extraneous words; each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, prerequisites, parameters, output metrics, and runtime behavior. With an output schema existing, the description provides sufficient context for the agent to understand and use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Compensates for 0% schema description coverage by explaining result_id as strategy_id/run_id and simulations defaulting to 1000. This fully clarifies both 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?
Clearly states the tool runs a Monte Carlo simulation from a saved backtest result, resamples trades, and provides risk metrics. Distinguishes from siblings like run_backtest and run_optimize by requiring their saved output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly specifies prerequisite (saved result from run_backtest/run_optimize) and default simulation count. Does not mention exclusions or alternatives but provides clear context for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Optimize strategy parameters with Optuna for symbol. metric defaults to sharpe_ratio.
save defaults to true so the result JSON is persisted (with `saved_path` in the
response) and can be fed to `apply_optimization`; pass save=false to skip saving.
Long-running: up to a 600-second timeout; reports progress to capable clients.
| Name | Required | Description | Default |
|---|---|---|---|
| save | No | ||
| metric | No | ||
| symbol | Yes | ||
| trials | No | ||
| strategy_id | Yes |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| data | Yes | |
| error | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behavioral traits not covered by annotations: it is long-running (up to 600s), reports progress to capable clients, and has a save option that persists data (implies writing). Annotations indicate non-read-only and non-destructive, which aligns, but the description adds specific details about execution duration and progress reporting.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences, each adding value. It front-loads the core purpose, then explains save behavior and runtime characteristics. 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 the tool has 5 parameters with no schema descriptions, the description covers main functionality, save parameter details, and runtime behavior. It doesn't explain return values (output schema exists) or 'trials' parameter, but overall it provides sufficient context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning for 'metric' (default sharpe_ratio) and 'save' (purpose and default), but provides no extra guidance for 'strategy_id', 'trials', or 'symbol' beyond their names. This partial compensation yields a score of 3.
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 action ('optimize strategy parameters with Optuna'), the resource (strategy parameters for a given symbol), and the default metric. It differentiates from sibling 'apply_optimization' by implying that this tool generates the optimization result which can then be applied.
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 the save parameter's role and how it relates to 'apply_optimization', providing context on when to persist results. It also mentions the long-running nature and timeout, hinting at appropriate usage. However, it lacks explicit guidance on when not to use this tool or contrasts with other backtesting siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run walk-forward optimization for symbol (out-of-sample robustness check).
windows defaults to 5, metric to sharpe_ratio. Run it after run_optimize to compare
in-sample vs out-of-sample behaviour (the optimize_and_verify workflow).
Long-running: up to a 600-second timeout; reports progress to capable clients.
| Name | Required | Description | Default |
|---|---|---|---|
| metric | No | ||
| symbol | Yes | ||
| windows | No | ||
| strategy_id | Yes |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| data | Yes | |
| error | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavioral details beyond annotations: 'Long-running: up to a 600-second timeout; reports progress to capable clients'. Annotations are neutral (readOnlyHint=false, destructiveHint=false), and description does not contradict them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three efficient sentences: purpose, defaults/workflow, runtime. 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?
Output schema exists, so return values need not be described. Description covers runtime and workflow context. Minor gap: lacks mention of prerequisites like having run optimization first (though implied by workflow).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, description only provides defaults for two optional parameters ('windows defaults to 5, metric to sharpe_ratio'). No explanation of required parameters symbol and strategy_id. Insufficient compensation for schema 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?
Description clearly states verb 'Run' and resource 'walk-forward optimization for symbol', with explicit purpose 'out-of-sample robustness check'. Distinguishes from siblings like run_backtest and run_optimize.
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 states when to use: 'Run it after run_optimize to compare in-sample vs out-of-sample behaviour (the optimize_and_verify workflow)'. Provides clear usage context, though does not list all when-not scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Register a strategy from its JSON body (not a file path; agent-friendly).
Pass the full strategy-definition JSON as a string; it is validated as a JSON object
and written to a temp file before `strategy save`. Returns {output}. A registered
strategy is the prerequisite for run_backtest/run_optimize. Reports progress to
capable clients; has an execution timeout.
| Name | Required | Description | Default |
|---|---|---|---|
| json_body | Yes |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| data | Yes | |
| error | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavioral context beyond annotations: internal steps (validated, written to temp file), progress reporting, and execution timeout. No contradiction with annotations; they are consistent with a non-read-only, non-idempotent write 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?
Description is concise with two main sentences plus a brief note. Every sentence adds value: first states action and clarification, second details processing, third adds context on prerequisite, progress, and timeout. No unnecessary 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 an output schema exists, the description need not detail returns. It covers validation, file writing, prerequisite for other tools, progress, and timeout. Could be more complete by mentioning error handling or size limits, but adequate for an AI agent.
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 explains json_body as a full strategy-definition JSON string, and describes what happens to it (validated, written to file). Does not detail required fields within the JSON, but provides sufficient meaning for an agent to understand the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Register' and the resource 'a strategy', and distinguishes itself by noting it takes JSON body, not a file path. It also mentions it's a prerequisite for run_backtest/run_optimize, setting it apart from sibling 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?
Provides explicit guidance on when to use (to register a strategy for backtesting) and what to pass (full JSON string). Implicitly tells when not to use (if already registered). Mentions validation and prerequisite, but lacks direct comparison to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0apply_optimizationexploration_statusfetch_dataforge_statusgenerate_pinescriptget_indicatorget_journalget_resultget_strategylist_journalslist_resultslist_strategiesrun_backtestrun_monte_carlorun_optimizerun_walk_forwardsave_strategyMost tools have distinct purposes. run_optimize and run_walk_forward both optimize but are differentiated by description (single vs. walk-forward). get_result, get_strategy, and get_journal serve different retrieval needs. Minor overlap but clear descriptions guide selection.
Tools predominantly follow verb_noun pattern with underscores (e.g., run_backtest, get_strategy). One tool, exploration_status, uses noun_noun, breaking the pattern slightly. Overall consistent and readable.
17 tools are well-scoped for a quantitative backtesting platform, covering data fetching, strategy management, backtesting, optimization, Monte Carlo, walk-forward, and results. Each tool has a clear role without bloat.
The tool surface covers the full lifecycle from data fetch to strategy registration, backtesting, optimization, and result analysis. Minor gaps like missing delete/update tools for strategies or results, but core workflows are intact.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for OpenMM — exposes market data, account, trading, and strategy tools to AI agents
MCP server exposing the Backtest360 engine API as tools for AI agents.
Research-only MCP server: turn your AI into a quant research desk — backtests, no trades.
MCP server for Gainium — manage trading bots, deals, and balances via AI assistants
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/alforge-labs/alpha-forge-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
