Skip to main content
Glama

find_sweep_runs

Runs from one sweep, or from every sweep this person has, filtered and sorted by the engine. LEAVE experiment_id OUT to search them all, which is how a person asking whether they have already found something like this gets an answer without spending a new search on a question that already has one. A SWEEP HAS NO WINNER: which run matters depends entirely on what was being asked, so you choose sort_by for the question in front of you -- return, risk-adjusted return, drawdown, trade count -- and say which one you sorted by whenever you report an order. Never call the top row 'the best strategy'; it is the top row by the measure you picked. Filter before you sort: a run with a handful of trades has metrics that mean nothing, so min_trades is usually the first thing to set. Every numeric filter has BOTH bounds, so a band is one question: a delta against the benchmark between 3 and 8 is min and max together, not a page fetched and thinned by hand. Readable while the sweep is still running.

[Access: pay 0.005 USDC via x402 (PAYMENT-SIGNATURE header) OR authenticate with an API key. An x402-capable client will auto-pay; API-key clients pay nothing per call.]

Input Schema

NameRequiredDescriptionDefault
assetNoAsset symbol, e.g. BTC or ETH.
limitNoMaximum results.
orderNodesc for best-first on that metric, asc for worst-first.desc
trendNoOnly runs from windows of this trend character, e.g. clean or choppy; several comma-separated, any of them counts.
offsetNoPagination offset in the result units documented by the tool; zero starts the first page.
max_irrNoOnly runs at or below this annualised IRR.
min_irrNoOnly runs at or above this annualised IRR.
sort_byYesThe metric to order by, e.g. sharpe_ratio, sortino_ratio, irr_annualized, total_return, max_drawdown, total_trades. Required, because the choice IS the question being asked.
coveringNoOnly runs over windows covering this single date, as YYYY-MM-DD. A different question from a span.
run_indexNoWhich run, as find_sweep_runs reported it.
atr_periodNoOnly runs that used this ATR period. Needs experiment_id.
generationNoOnly runs from this engine generation, so runs made under different engine behaviour are not compared as though alike.
max_returnNoOnly runs at or below this total return.
max_sharpeNoOnly runs at or below this Sharpe ratio.
max_tradesNoOnly runs at or below this trade count. Pairs with min_trades to ask for a band rather than a floor.
min_returnNoOnly runs at or above this total return.
min_sharpeNoOnly runs at or above this Sharpe ratio.
min_tradesNoDrop runs with fewer trades than this. Metrics from a handful of trades are noise.
run_statusNoOnly runs with this outcome, e.g. no_trades for the ones that never opened a position.
volatilityNoOnly runs from windows of this volatility band, e.g. low; several comma-separated, any of them counts.
candle_sizeNoDuration of one candle, e.g. 1h or 1d.
covering_toNoOnly runs whose window overlaps up to this date.
max_win_rateNoOnly runs at or below this win rate.
min_win_rateNoOnly runs at or above this win rate.
trigger_nameNoOnly runs whose entry trigger is this signal.
cooldown_barsNoOnly runs that used this cooldown. Needs experiment_id.
covering_fromNoOnly runs whose window OVERLAPS this date onwards. A run is relevant to 2024 if any of it happened in 2024.
experiment_idNoThe sweep, as create_sweep returned it.
reward_factorNoOnly runs that used this reward-to-risk setting. Execution filters need experiment_id; the cross-sweep surface does not serve them.
beats_benchmarksNoOnly runs that beat all three benchmarks over the same
market_directionNoOnly runs from windows of this market character, e.g. bear or mega_bull. Several are one comma-separated string, e.g. "bull,super_bull", and a run matching any of them counts. What a run did in one kind of market says little about another.
regime_compositeNoOnly runs from windows with this full regime label, e.g. mega_bull_high_clean, when the three parts together matter; several comma-separated, any of them counts. Across different regime filters every one must hold.
regime_directionNoThe direction band from get_market_regime, e.g. bear. The signal searches filter by it and find_sweep_runs marks each row's regime_fit with it; save_strategy and update_strategy read the current band themselves, so their check runs without it.
max_delta_vs_assetNoOnly runs beating their own asset by at most this much.
max_risk_per_tradeNoOnly runs that risked this fraction per trade. Needs experiment_id.
min_delta_vs_assetNoOnly runs beating buy-and-hold on their own asset by at least this much.
max_delta_vs_benchmarkNoOnly runs beating their benchmark by at most this much, so "between 3 and 8" is one question rather than a page fetched and thrown away.
min_delta_vs_benchmarkNoOnly runs that beat their benchmark by at least this much. A return in a rising market is not skill.
beats_crypto_benchmarksNoOnly runs that beat the crypto benchmarks rather than only their own asset.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description carries the full burden, and it does disclose non-obvious traits: the tool is readable while a sweep is still running, results are ranked by a caller-chosen metric with no inherent winner, and calls cost 0.005 USDC via x402 unless an API key is used. Gaps remain on pagination behavior and what a returned run row actually contains, beyond the passing mention of regime_fit.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with scope, then sorting discipline, then filtering discipline, then access/cost. Most sentences earn their place, but the band-filter point is made in the prose and again restated in the schema for max_delta_vs_benchmark, and the anti-'best strategy' lecture runs slightly long.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 39-parameter tool with no output schema and no annotations, the description supplies the decision framework (sort choice is the question, filter before sort, bounds are bands) and the operational facts (running-sweep readability, payment model). It stops short of describing row shape or pagination semantics for offset/limit, which an agent paging results would want.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: sort_by is framed as the question being asked, order as best-first vs worst-first, min/max pairs as a single band query, and matches the schema's note that execution filters require experiment_id. It reinforces rather than replaces the per-parameter docs, so it does not reach 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a concrete scope statement: runs from one sweep, or from every sweep the caller owns, filtered and sorted by the engine. The scoped-vs-cross-sweep distinction is made explicit ('LEAVE experiment_id OUT to search them all'). It does not name a sibling tool it is an alternative to, so it falls short of the 5 bar for sibling differentiation, but the resource and action are unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit operating instructions: omit experiment_id to search across sweeps, always set min_trades before sorting, filter before sorting, set bounds as a band rather than paging and thinning, and state which metric you sorted by when reporting. The 'A SWEEP HAS NO WINNER' warning and the ban on calling the top row 'the best strategy' preempt the most likely misuse.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.