MangroveAI

Run the Strategy Engine route in one call. Use it FIRST whenever someone asks to build or make a strategy and names no signals -- 'build me a strategy', 'build me a BTC strategy on 1h', 'make me something for ETH'. Give the asset, and the candle size only when they named one. The server reads the 180-day regime, searches the engine's completed runs once with the agreed floors (more than 10 trades, Sharpe at least 1, IRR at least 10%, beats benchmarks) in that regime, keeps the runs whose entry the regime admits, picks one at random, saves it from its own run and backtests it on the last 90 days (30 for 5m). Do not pass filters, a regime or dates: they are fixed. When nothing fits it saves and spends nothing, and you move straight to a fresh build. It does not search the marketplace. [Access: pay 0.10 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.]

Classify one stretch of market: a date range, or a catalog window by file name. Explicit date ranges require daily (1d) candles; catalog windows retain their stored interval. Returns its direction band, volatility band, trend character and the three features behind them, using the same labels the sweep catalog carries. Use it for a period the person names, or to see what a window a sweep selected contains. For an asset's current conditions use get_market_regime instead. Volatility reads `unscored` when no fitted band covers the stretch's length; the bands come back with it. For an exact crypto market, supply quote_token and market_data_venue together. A date range covers crypto and the stocks, ETFs, commodities and bonds in Oracle's regime catalog: SPY, QQQ, DIA, IWM, AAPL, AMD, AMZN, COST, GOOGL, HD, JNJ, JPM, META, MSFT, NFLX, NVDA, PG, TSLA, UNH, WMT, XOM, GLD, SLV, USO, GOLD (gold futures), CRUDE (crude oil futures) and TLT. Without explicit source arguments, those tickers are read from their exchange-session daily series, even where a crypto token shares one (DIA and META are the ETF and the stock here); any other ticker is read as crypto, so a stock not named here cannot be read. Explicit market or provider arguments select the crypto history path. `venue` says which feed was read. A listed ticker needs at least 15 sessions with a close, about three weeks; anything shorter is refused as too little history. [Access: pay 0.02 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.]

Permanently delete a strategy by its ID. Use this only when the user explicitly asks to delete a strategy. Always confirm the strategy name and ID before deleting.

Discover Mangrove managed tools without executing them. Free, public read. Use detail=areas for the functional area index; summary (default) returns only names and descriptions; schema returns full live tool definitions. Select any areas and/or tool names; combined selectors form a union.

Evaluate chart data and optional signal triggers over a specific range. [Access: pay 0.05 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.]

Evaluate a signal against provided market data and parameters. [Access: pay 0.02 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.]

Evaluate a strategy against current live market data to check if entry or exit signals are active — read-only signal check, does NOT place any orders. Returns the current asset price and any order intents the signals would produce. Use this when the user asks whether a strategy should be entering or exiting right now, or wants to know the live signal state for a specific strategy.

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.]

Full metadata and risk profile for one crypto asset on the Mangrove platform: approval status, risk score breakdown, regulatory status and identifiers. Use it when the user asks about a specific asset's approval or risk detail rather than a live price. [Access: pay 0.001 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.]

Fetch a backtest that already ran, by id, with the execution config it used. Use it instead of run_backtest whenever the user refers to a previous result, or to compare two runs -- re-running costs them a unit of their allowance and a stored run is the record of what actually happened. [Access: pay 0.001 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.]

The individual trades a backtest made -- entry and exit prices and times, profit or loss, and why each one closed. Use it when the user asks what a backtest actually traded; get_backtest has the summary metrics. THESE ARE SIMULATED TRADES from a backtest, not real ones -- list_trades has those. A long run is paged: pass offset to read on. [Access: pay 0.001 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.]

Buy-and-hold return for an asset between two dates, as a percentage. Use it whenever you state what a strategy returned: a return with nothing to compare it against does not answer whether the strategy was worth running. run_backtest already includes this for its own window, so call this for a different asset or a different period. [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.]

Total Value Locked for a whole blockchain such as Ethereum, Base or Solana. Returns USD TVL and the top protocols on that chain. Use it when the user asks about a chain's overall DeFi footprint. [Access: pay 0.01 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.]

Crypto ETF net flows -- institutional inflows and outflows for spot BTC and ETH ETFs. Persistent net inflows are a bullish tape signal; heavy outflows bearish. Use it when the user asks about ETF flows, institutional demand or spot ETF activity. [Access: pay 0.01 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.]

Every execution-config parameter a strategy can carry: the platform default, what it does, the effect of raising or lowering it, its legal bounds, and whether it is a strategy-character knob, an account guardrail, gated behind another flag, or retained but unused. Call it before discussing or overriding any risk parameter, so you describe the knob that exists rather than one you remember. [Access: pay 0.001 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.]

Global crypto market snapshot -- total market cap, BTC dominance, total 24h volume and the 24h change. Use it when the user asks about overall market conditions or wants a macro view rather than a per-asset reading. [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.]

Influence score for a single X/Twitter account: a 0-100 score and follower count. Use it when the user asks about a specific influencer or KOL, or wants to know how much weight an account carries in crypto conversation. It is a per-account snapshot, not a topic aggregate. [Access: pay 0.02 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.]

Per-pool borrow rates across DeFi lending protocols such as Aave, Compound and Morpho. Useful for rate-spread arbitrage screens and stablecoin yield analysis. Use it when the user asks about lending rates, borrow costs or DeFi yield. [Access: pay 0.01 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.]

Latest trade price for a selected market, plus aggregate market cap and 24h volume. Pass quote_token and market_data_venue together to honor a requested exchange. When omitted, selects a supported market and returns its quote and venue. Report the returned venue and quote; disclose price_as_of and price_stale. Use it when the user asks what an asset is doing now, or when a live price is needed to ground a recommendation. It is a spot reading from an external API and is rate limited, so call it once per asset and reuse the answer. [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.]

Classify an asset's regime using a lookback of 1-365 days of daily closes: the return and a bull/neutral/bear band over 90, 180 and 365 days, plus annualised volatility as a percentage, a bucket, and a z-score against the asset's own baseline; and the whole lookback in the sweep catalog's labels (direction, low/medium/high volatility for its asset class and length, and a clean/mixed/choppy trend). Use it before recommending a strategy style, because a mean-reversion design and a trend-following design suit opposite regimes. Covers crypto and the stocks, ETFs, commodities and bonds in Oracle's regime catalog: SPY, QQQ, DIA, IWM, AAPL, AMD, AMZN, COST, GOOGL, HD, JNJ, JPM, META, MSFT, NFLX, NVDA, PG, TSLA, UNH, WMT, XOM, GLD, SLV, USO, GOLD (gold futures), CRUDE (crude oil futures) and TLT. Without explicit source arguments, those tickers are read from their exchange-session daily series, even where a crypto token shares one (DIA and META are the ETF and the stock here); any other ticker is read as crypto, so a stock not named here cannot be read. Explicit market or provider arguments select the crypto history path. `venue` says which feed was read. A listed ticker needs at least 15 sessions with a close, about three weeks; anything shorter is refused as too little history. For a listed ticker the lookback is calendar days, so 365 reads about 250 sessions. For an exact crypto market, supply quote_token and market_data_venue together. [Access: pay 0.02 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.]

One marketplace listing in full: its metrics, the signals it is built from (names only; the creator's tuning is never exposed), its backtest summary, and whether it is already in this account. Use it before describing or offering a specific listing, so what you say is what the marketplace holds. [Access: pay 0.001 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.]

Daily OHLCV (open, high, low, close, volume) history for one crypto asset over the requested lookback (1-3650 days). Use it when the user asks for price history, chart data, or wants to reason about past price movement rather than the current spot. Supply quote_token and market_data_venue together to select an exact market, or provider for an external source; omit these overrides to select a Mangrove market. [Access: pay 0.01 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.]

Per-bar on-chain metric time series for a token. One request returns a bar-indexed series with any combination of SmartMoneyNetflow, SmartMoneyHoldings, ExchangeNetflow, WhaleNetInflow and HolderConcentration. Interval is 1h, 4h, 1d or 1w; top_n is how many top holders HolderConcentration sums; the only provider is nansen. Native ETH is read as WETH, and the token must be deployed on the chain asked for. Prefer this over firing many point queries when the user wants a historical or trailing-window view. [Access: pay 0.05 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.]

Aggregated DeFi perpetual funding rates across venues. Positive funding means longs are paying to hold; negative means shorts are. Use it when the user asks about perp funding, crowded positioning or leverage bias. [Access: pay 0.01 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.]

Return OHLCV chart data for a specific playground dataset.

Total Value Locked for a single DeFi protocol such as Aave, Uniswap or Curve. Returns USD TVL and a per-chain breakdown. Use it when the user asks how much capital is locked in a specific protocol. [Access: pay 0.01 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.]

Get complete metadata for an exact registered signal name. [Access: pay 0.001 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.]

Recent DEX trades from smart-money wallets across chains. Returns a paginated list of executed trades with token, side, size and wallet metadata. Use it when the user asks what smart money is trading on DEXs, or wants a raw feed of smart-money swap activity. [Access: pay 0.02 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.]

One-token flow intelligence snapshot: returns net USD flows and wallet counts for smart traders, whales, exchanges, fresh wallets and public figures together in ONE response. Use for a trailing-window category summary, including the past 24 hours (timeframe=1d). Do not fetch a separate token-flows page for each category to construct this summary. Timeframe is 5m, 1h, 6h, 12h, 1d or 7d. For explicit start/end dates or paginated flow records use get_token_flows. Native ETH is read as WETH; the token must exist on the requested chain. [Access: pay 0.02 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.]

Historical snapshots of what smart-money wallets held on specific dates. Returns per-wallet-category holdings with USD values. Use it when the user wants to see how smart-money positioning has changed over time, or wants historical on-chain portfolio data for a date range. [Access: pay 0.02 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.]

Current smart-money holdings: what funds and smart traders are holding right now, sorted by USD value. Use it when the user asks what smart money currently owns or has positions in. [Access: pay 0.02 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.]

Aggregated smart-money netflows across all tokens market-wide: which tokens funds and smart traders are accumulating or distributing. Use it when the user asks what smart money is buying or selling, or wants to see market-wide on-chain trends. [Access: pay 0.02 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.]

Perpetual futures trades from smart-money wallets on Hyperliquid. Shows leveraged directional bets by sophisticated traders. Use it when the user asks about smart-money perp positions, what high-conviction traders are doing with leverage, or wants to see Hyperliquid smart-money activity. [Access: pay 0.02 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.]

On-chain sentiment read for a token derived from smart-money wallet net flows. Returns a sentiment label (bullish, bearish or neutral) and net USD flow direction. Use it when the user asks what smart-money sentiment is for an asset, or wants a quick bullish or bearish read from on-chain flow data. For X or Twitter social sentiment use get_social_sentiment instead. [Access: pay 0.02 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.]

Recent X/Twitter posts about a crypto asset or topic: post text, id and time, at most 10 posts, plus how many posts the search matched. Use it when the user wants to see what is actually being said, or wants raw posts rather than an aggregated sentiment score. [Access: pay 0.02 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.]

Keyword-polarity sentiment for a crypto cashtag on X/Twitter. It fetches recent posts for $TOPIC and counts how many contain a positive and how many a negative keyword; the 0-100 score is the positive share of those polar posts. Returns the score, a bullish (70 or more), neutral or bearish (30 or less) label, and the number of posts read. When no post carried a sentiment keyword the score is null and the label is insufficient_signal: report that, not a neutral reading. Always state how many posts the reading was built from. Use it when the user asks about market mood or social sentiment for a token. The call is metered, so ask once per topic and reuse. [Access: pay 0.02 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.]

Global stablecoin metrics -- total supply, per-chain breakdown and the top stablecoins by market cap. Use it when the user asks about stablecoin supply, USDC or USDT dominance, or overall market liquidity. [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.]

Fetch one saved strategy in full -- its entry and exit signals, asset, timeframe and status. Accepts either strategy_id or name. Use it before discussing or changing a specific strategy so you describe what is actually stored rather than what was said earlier in the conversation. [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.]

The exchanges that list one specific token, with per-venue metadata. Use it when the user asks where a token trades or which venues carry it, rather than for a price on any one of them. [Access: pay 0.001 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.]

DEX trades for a specific token across all participants in a date window. Returns raw swap events with wallet, size and pool metadata; useful for post-hoc flow analysis on a single token. Native ETH is read as WETH, and the token must be deployed on the chain asked for. [Access: pay 0.02 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.]

Paginated historical flow records for one non-stablecoin token between explicit start and end dates, optionally filtered by one wallet label. Use for date-range records or pagination. For a trailing-window summary of net USD flows AND wallet counts across categories, use get_smart_money_flows, which returns the categories together in one call. Not available for stablecoins. Native ETH is read as WETH; the token must exist on the requested chain. [Access: pay 0.02 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.]

On-chain token holder distribution for a token: total on-chain holder count, top-10 concentration percentage and a concentration score. Nansen aggregates across chains, so pass the symbol only and do not pass a chain argument. Use it when the user asks how many wallets hold a token, about holder count, holder concentration, whale ownership or distribution risk. [Access: pay 0.02 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.]

Token unlock schedules and supply metrics -- upcoming vesting cliffs and total supply movement per token. Heavy near-term unlocks are a supply-shock signal. Use it when the user asks about unlocks, vesting or supply overhang. [Access: pay 0.01 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.]

Get trade records for a specific strategy by its ID. Use this when the user asks about trades or performance for a particular named strategy.

DeFi protocol treasury holdings -- how much a protocol holds in its own treasury and what tokens it owns. Use it when the user asks about protocol treasuries, DAO holdings or protocol-owned liquidity. [Access: pay 0.01 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.]

The crypto assets trending right now by 24h search volume. Use it when the user asks what is popular, what the market is paying attention to, or wants a discovery view rather than a specific asset lookup. [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.]

Read a requested KB guide or a known source section by slug. Use directly when the user requests the document itself; no preliminary graph call is required. For a general explanation use query_knowledge op=ask, not a document-reading sequence. If a needed slug is unknown, locate it with kb_search or kb_list_documents. Use view=overview for a guide summary; view=section with a returned section_anchor for a specific passage. Content defaults to 6000 characters; offset and next_offset count characters within the selected body. Continue only when the requested material is missing, not merely because has_more is true. full=True is for explicit full-document requests. A document excerpt is educational material; executable signal identities and parameters come from the runtime registry.

Read the Signals Quick Reference guide when the user asks for that guide or its documented entries. This is the document-reading shortcut for kb_get_document slug=10-signals-quick-reference, not an additional validation step. Use view=overview for its outline or view=section with a known anchor for a passage. Content defaults to 6000 characters; offset and next_offset count characters within the selected body. Continue only for requested missing text. Reserve full=True for explicit downloads. For conceptual signal combinations use query_knowledge op=ask. For executable signal names and parameters needed to construct a strategy use the runtime catalogue, not this educational guide.

Return the KB glossary entry for an explicitly requested glossary definition or exact glossary term. No preliminary graph call is required for a glossary request. For a general question such as what RSI means, why it behaves that way, or which indicators complement it, start with query_knowledge op=ask. Exact lookup is case-insensitive and may return partial matches. Answer from the returned definition when sufficient; do not routinely follow it with graph or document searches.

Reads the Mangrove Knowledge Base package: every document's slug, title and summary. For a keyword search instead of browsing use kb_search. Use this when the user wants to browse the KB or you need a slug before calling kb_get_document.

Locate KB articles or source sections using short topic keywords. Use when the user asks to find written material, or an explanation is missing a specific fact that requires a source passage. For general definitions, explanations, comparisons and combination/caution questions, start with query_knowledge op=ask instead. This returns snippets and section anchors, not full articles. All query terms must match; do not send a full question or split it into speculative keyword searches. A tag restricts the category and disables synonym expansion. If the snippets or attached graph evidence answer the request, answer directly. Read one returned section with kb_get_document only if a required fact is still missing. Do not automatically search again or read every result.

List assets approved by Mangrove, including supported stablecoins and tokens. Approval is independent of risk assessment. Unassessed risk scores are null; do not interpret them as zero or infer regulatory approval. Returns available market metadata and risk scores. [Access: pay 0.001 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.]

List available execution venue and quote-token choices for a backtest. Use when the user wants alternatives or market details are missing. A complete supplied or recorded market is already the default: do not force a selection step. If missing details must be matched, suggest an available match and obtain confirmation before saving or running. Availability here does not guarantee historical coverage; submission checks the chosen window.

The user's recent backtest runs, newest first, optionally just the ones for one strategy. Use it when they ask what they have run, or refer to an earlier result without giving an id -- then fetch the one you need with get_backtest. It is how you avoid re-running something that already has an answer. Results are newest first; pass strategy_id to see only one strategy's runs. [Access: pay 0.001 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.]

Bar-by-bar decision log for a strategy — every time the agent checked signals for this strategy. Returns per-evaluation market snapshot, signal decisions, order intents generated, and whether the evaluation succeeded or errored. Use this when the user asks 'what did the agent decide', 'why did it not trade', 'show me the agent evaluation history', or 'when did the agent last check this strategy'.

Every exchange the Mangrove platform tracks, with per-exchange tier and 24h volume. Use it when the user asks what exchanges are supported or wants to browse the exchange universe rather than a single venue. [Access: pay 0.001 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.]

Return metadata for all available playground CSV datasets.

List open (or all) positions for the current user. Optionally filter by strategy ID or asset. Use this when the user asks about their current positions, open trades, or what they are currently holding.

Every signal's friendly name, display name and short description, keyed by code name.

List available trading signals: names, types (TRIGGER or FILTER) and short descriptions. Use it to browse the catalogue, or narrow it by regime band, role or library category. [Access: pay 0.001 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.]

List the strategy definitions saved HERE, in this service -- drafts and backtested strategies authored through chat. This store never knows deployment state: for what the user is actually running (live or paper deployments, balances, PnL), use list_platform_strategies instead. Returns id, name, asset and status for each.

The trades a person's strategies have closed -- what was made or lost on each, why it exited, and what the fees and slippage cost. For a platform account overview and last-trade times use list_platform_strategies; platform detail requires strategy_id. Use this for what actually happened: 'how am I doing', 'what did it trade', 'why did it sell', 'has it made money'. Pass strategy_id for one strategy's record. THESE ARE REAL TRADES, not a backtest -- never mix them with backtest metrics in one number, and say which you are quoting. Every trade carries fee_cost, slippage_cost and gas_cost; a profit or loss quoted without them reads as though trading were free. Passing strategy_id takes precedence -- asset and outcome are not applied alongside it. [Access: pay 0.001 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.]

Load one of your skills: the full instructions for doing something, which the turn only announced by name. Do it BEFORE working in a skill's area rather than after -- the announcement says what a skill is for, and the skill itself says how, including which calls to make and what not to do. Pass a section name to load only part of it. A skill may also carry FILES it tells you to read -- a lookup table, a mapping -- and `resources` names them; pass one as `resource` to be given it. Asking for a skill, a section or a resource that does not exist returns the ones that do.

Match a trading description to ranked signals. [Access: pay 0.01 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.]

Explain trading concepts, definitions, relationships, comparisons and when signals work or fail using Michael's knowledge graph. This is the first tool for a general knowledge question, including which indicators complement RSI and when to avoid combining them. Start with op=ask, the complete question in q, hops=1 and limit=5. Keep related clauses together; do not run a search for each clause. Read the summaries and edge reasons before deciding on another call. Answer once the requested explanation and cautions are supported. A follow-up must address a specific missing fact: get an already-returned node for its details, or read one relevant KB section. Do not gather extra context, enumerate neighbors, check the signal catalogue or measure signals merely to expand a conceptual answer. If evidence remains insufficient, say what is unknown instead of repeatedly rephrasing searches. This guidance does not replace validation required for an actual strategy or a requested graph exploration. Explicit glossary, document and browsing requests go directly to the corresponding KB tool without a preliminary graph call. Runtime signal selection belongs to the signal catalogue; measured firing rates and durations belong to query_signal_behavior; current market regime belongs to get_market_regime. These are separate user intents, not mandatory steps for an explanation. Mangrove product policy belongs to query_product_facts. Reuse evidence and node IDs already returned in this conversation. Ops: stats (the counts and the complete vocabulary every filter accepts -- call it when you do not already know the filter values), find (search BY WORDS, optionally by kind/role/status/requires/param -- param finds every signal taking a parameter of that name), ask (search BY MEANING -- give it the question in ordinary words; use this when you would otherwise answer from memory, e.g. 'how far should the stop go', 'what works in a sideways market'; hops is capped at 3), get (one node in full: formula, inputs, params, outputs, warmup), neighbors (one hop: what reads this, or what this depends on; filter by relation, relation_category, primitive or why), walk (the whole neighbourhood out to a radius, as nodes plus edges -- for 'everything around X' rather than one hop at a time), outputs (search the VALUES: which are bounded, which are in given units, what produces an output called X), path (the one shortest route between two nodes), paths (every simple route between two nodes -- use when the shortest route is not the explanatory one), ancestors (the classes a node belongs to, transitively), descendants (everything under a class, transitively), under (everything contained in a node by subject, whatever primitive it is -- e.g. a whole knowledge-base chapter). NEVER GUESS a node id or name for get/neighbors/outputs/path/walk/paths/ancestors/descendants/under: call find (or ask) only if you do not already have an ID from a tool result -- ids look like 'procedure:signal-rsi-bullish-divergence', not 'rsi_divergence'. A get that misses returns candidates; fetch one only if it is relevant to a fact still needed for the answer. Signal rows carry signal_type from the catalog: TRIGGER is an occurrence, FILTER is a condition that can remain true across bars. A boolean output does not make a signal a TRIGGER; read its signal_type rather than infer its role from its name or output. Class and role are different questions: kind='momentum' is what a computation measures, role='trigger' is the part it plays.

Query measured signal behaviour: describe, pick, find or gap_probability. [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.]

Start a backtest of one saved strategy over a window of history. Takes a strategy_id -- it reads the stored strategy's own rules, asset, timeframe and risk parameters. The recorded market is the default; pass quote_token and/or market_data_venue when the person chooses another quote or execution venue. An omitted choice keeps its recorded value. Check and report the selected market; never silently substitute a feed. IT RETURNS A SUBMISSION, NOT A RESULT: a real backtest takes minutes, so this hands back the run's id and the config it will use, and the metrics arrive on their own once the engine finishes. Tell the person it is running; do not call this again for the same question, and do not wait. It consumes a unit of the user's monthly backtest allowance at submission -- so it CHECKS THE STRATEGY FIRST, and a refusal costs nothing: a problem (verify_strategy's problems) always refuses, and a signal parameter still at its library default refuses until you either save chosen values or pass acknowledge_defaults=true to stand by the defaults deliberately. One (strategy, window) is ONE measurement: submitting the same strategy over the same dates again is refused and the existing run named -- read that with get_backtest instead. Both start_date and end_date are required: name the days, so the same question asked next week gives the same answer. Every message carries the current time, so work them out from that. [Access: pay 0.10 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.]

To promote a sweep pick, pass source_experiment_id and source_run_index; the service loads its authorized configuration and checks coverage before saving. Its recorded venue and quote token are defaults: pass market_data_venue and/or quote_token only when the person chooses a different market. Otherwise compose and save a trading strategy from signals in the library. Give it a strategy_name, an asset, and the entry and exit signals you chose -- each one {name, params?, timeframe?}, with params defaulting from the library when omitted. DO NOT pass a signal's role: TRIGGER and FILTER are read from the library, and an entry must resolve to exactly one TRIGGER plus any number of FILTERs. Find real signal names with query_knowledge first; never invent one. The server checks the entry against the current market regime itself -- a strategy composed against the wrong regime is refused, and telling the person why is a better answer than saving it anyway. Pass constraints ONLY for values the person actually stated: they are kept exactly as given, while everything else comes from canon. Saving the same strategy twice returns the first one rather than making a duplicate, and says so in created. What you save is a DRAFT: not tradeable until a backtest of it meets the platform's threshold spec, and it leaves draft on its own when one does. [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.]

Rank several candidate strategies by how likely each is to trade at all, before spending backtests on them. Give it one asset and up to 99 candidates, each {entry: [...], exit: [...]} with signals from the library -- the roles come from the library, so do not pass signal_type. IT PREDICTS WHETHER A STRATEGY WILL PLACE TRADES, AND NOTHING ABOUT WHETHER IT WILL MAKE MONEY: only a backtest answers that. Use it to choose which of many candidates to backtest first, never as a verdict on a single strategy -- a probability on its own says little, and the ranking is the answer. A HIGH score is real support for spending a backtest. A LOW score is weak evidence and is NOT a finding that the strategy will not trade: measured against runs that did trade, a 0.5 cutoff recovers under half of them. Never tell someone their strategy will not trade because this scored it low; back it and find out. [Access: pay 0.02 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.]

Screen the market for tokens that smart-money wallets are currently accumulating or distributing. Returns a ranked list of tokens with high smart-money activity across the specified chains. Use it when the user asks what smart money is currently buying, which tokens are being accumulated, or wants to discover high-conviction smart-money plays. [Access: pay 0.02 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.]

Search the public strategy marketplace -- the platform's own listings, which are digital-asset strategies on crypto pairs -- over every dimension the marketplace page filters on: free text, asset, timeframe, risk level, floors on return, IRR, Sharpe, Sortino, Calmar, gain-to-pain, win rate, trade count and trades per week, a drawdown ceiling, free-only, beats-benchmarks, the market regime the listing was backtested in, and any sort key. Every filter is applied by the platform; do not fetch a page and filter it yourself. Counts cover the platform's own listings; the marketplace page also merges NexusTrade partner listings, which are not searchable or adoptable here -- say so plainly when a total is compared with the page, never guess at caching or filters. Use it whenever the person wants strategies to try, compare, or adopt -- 'find me a', 'what is on the marketplace', 'best Sharpe on ETH'. To adopt one, call propose_adopt with its strategy_id; never tell the person a strategy is theirs off the back of a search. [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.]

Search signal names, parameters or description keywords. [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.]

Change a DRAFT strategy in place: its signals, their parameters, or a stated execution value. Pass the COMPLETE entry and exit signal lists when changing signals -- what you pass replaces what was stored, it is not merged, while constraints merge onto the stored execution config. Only a draft that has never been backtested can change: once a backtest has measured it, its rules are frozen so the results stay attached to the rules they ran, and a change means saving a NEW strategy with save_strategy. Use this to act on verify_strategy's warnings without creating a duplicate. [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.]

Update the status of a strategy. Valid statuses: draft, inactive, paper, live, archived. Use this when the user wants to activate, pause, archive, or promote a strategy (e.g. 'pause my BTC strategy', 'archive the old ETH strategy').

Validate parameters for a signal. [Access: pay 0.001 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.]

Check a saved strategy against everything that has to be true for it to run: the signal names and their parameter keys, the roles composing, a timeframe on every signal, and a timeframe on the strategy. Call it after saving and BEFORE backtesting -- a backtest spends the person's allowance the moment it is submitted, whether or not it runs, and these are the faults that make it fail at setup with nothing measured. It reads what is STORED, so it answers for the strategy as it exists rather than as it was described. `warnings` are judgements it cannot make for you -- a parameter still at its library default -- and do not stop a run. [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.]