# MangroveAI (remote · api.mangrovedeveloper.ai) Backtest and paper-trade crypto strategies. Free API key or pay per call in USDC (x402). - Trust score: 62/100 (medium) - Registry status: active - Liveness: live - Owner verified: no - Last scored: 2026-10-23 ## Components - remote · `api.mangrovedeveloper.ai`: 62/100 (this document), [markdown](https://verifymcp.io/servers/mangrovetechnologies-mangroveai/api.md), [page](https://verifymcp.io/servers/mangrovetechnologies-mangroveai/api) ## Channel facts - Endpoint: `https://api.mangrovedeveloper.ai/mcp/` - Transports: `streamable-http` - Auth: `none` - Version: `1.0.0` ## Trust breakdown How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog) Scored 2026-10-23. - **Endpoint Security**: 63/100 - The endpoint's TLS certificate is valid, in date, and uses a strong key. - Authorisation not fully verified: no authorisation is required to call this server, and 75 tool(s) never declared a destructiveHint. The MCP spec treats an absent hint as destructive by default, so we cannot call this surface safe. - HTTPS is enforced; there's no plaintext access path. - The HSTS (Strict-Transport-Security) header is present. - DNSSEC check failed: this domain isn't protected by DNSSEC. - **Transport & Reachability**: 100/100 - Verified streamable-http transport via a live MCP handshake. - **Schema Quality & AI Usability**: 62/100 - AI-judged instruction clarity (excellent). - Context-footprint check failed: tool/resource definitions use about 16545 tokens (~217/item across 76 items; 76 tools + 0 resources), over budget; trim descriptions and params. - Usage-examples check failed: none of the tools include examples. - **Stability & Change Management**: 3/100 - Stability observed for 1 of 30 days with no destabilising changes; credit accrues until the full window elapses. - **Tool Coverage**: 98/100 - 100% of tools have a non-trivial description (not blank, and not just the tool's name). - 95% of tool parameters carry a description. - **Tool Safety**: 75/100 - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured. - 0 of 1 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation; "delete_strategy" implies "delete" and declares no destructiveHint at all, which the MCP spec reads as destructive by default. - An AI judge read all 76 captured unit(s) of tool text and found none that tries to manipulate the model reading it. - **Capabilities**: 60/100 - Spec-recency check failed: implements MCP spec 2025-06-18; the latest is 2026-07-28. ## Install ### How do I install the MangroveAI MCP server? MangroveAI is a hosted endpoint at https://api.mangrovedeveloper.ai/mcp/, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation. ### Claude ```bash claude mcp add --transport http mangrovetechnologies-mangroveai 'https://api.mangrovedeveloper.ai/mcp/' ``` ### Cursor ```json { "mcpServers": { "mangrovetechnologies-mangroveai": { "url": "https://api.mangrovedeveloper.ai/mcp/" } } } ``` ### VS Code ```json { "servers": { "mangrovetechnologies-mangroveai": { "type": "http", "url": "https://api.mangrovedeveloper.ai/mcp/" } } } ``` ### Codex ```toml [mcp_servers.mangrovetechnologies-mangroveai] url = "https://api.mangrovedeveloper.ai/mcp/" ``` ### opencode ```json { "$schema": "https://opencode.ai/config.json", "mcp": { "mangrovetechnologies-mangroveai": { "type": "remote", "url": "https://api.mangrovedeveloper.ai/mcp/", "enabled": true } } } ``` ### OpenClaw ```bash openclaw mcp add mangrovetechnologies-mangroveai --url 'https://api.mangrovedeveloper.ai/mcp/' --transport streamable-http ``` ### Hermes ```yaml mcp_servers: mangrovetechnologies-mangroveai: url: "https://api.mangrovedeveloper.ai/mcp/" ``` ### Netclaw ```json { "McpServers": { "mangrovetechnologies-mangroveai": { "Transport": "http", "Url": "https://api.mangrovedeveloper.ai/mcp/" } } } ``` ### Vellum ```bash assistant mcp add mangrovetechnologies-mangroveai -t streamable-http -u 'https://api.mangrovedeveloper.ai/mcp/' ``` ### Other ```json { "mcpServers": { "mangrovetechnologies-mangroveai": { "type": "http", "url": "https://api.mangrovedeveloper.ai/mcp/" } } } ``` The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs. ## Changelog Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims. ### 2026-10-23 (score 62, +1) - [functional improvement] Stability: unverified → 0.03 ### 2026-10-22 (score 61) First indexed and scored. ## MCP tools (76) ### `delete_strategy` (~48 tokens) 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. Input parameters: - `strategy_id` (string, required) ### `update_strategy_status` (~79 tokens) 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'). Input parameters: - `new_status` (string, required) - `strategy_id` (string, required) ### `get_trades_for_strategy` (~53 tokens) 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. Input parameters: - `limit` (integer) - `strategy_id` (string, required) ### `list_positions` (~80 tokens) 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. Input parameters: - `asset` (string) - `limit` (integer) - `open_only` (boolean) - `strategy_id` (string) ### `evaluate_strategy` (~89 tokens) 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. Input parameters: - `strategy_id` (string, required) ### `list_evaluations` (~113 tokens) 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'. Input parameters: - `limit` (integer) - `offset` (integer) - `strategy_id` (string, required) ### `build_strategy_for_regime` (~284 tokens) 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.] Input parameters: - `asset` (string, required): Asset symbol, e.g. BTC or ETH. - `candle_size` (string): Duration of one candle, e.g. 1h or 1d. ### `classify_market_segment` (~551 tokens) 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.] Input parameters: - `asset` (string): Asset symbol, e.g. BTC or ETH. - `candle_size` (string): Duration of one candle, e.g. 1h or 1d. - `end_date` (string): ISO end of the window. - `market_data_venue` (string): Exact venue of the requested market. - `provider` (string): Optional upstream override; omitted uses the existing server default. - `quote_token` (string): Quote currency of the requested market. - `start_date` (string): ISO start of the window, e.g. 2026-01-01. - `window_file` (string): A catalog window's file name, classified as it stands. Supply this or the asset with both dates, not both. ### `evaluate_multiple_signals_series` (~226 tokens) 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.] Input parameters: - `chart_timeframe` (string): Live chart timeframe; dataset mode uses its bundled timeframe - `dataset_key` (string): Bundled dataset key; replaces symbol and date range - `end_date` (string): Live-mode chart end timestamp; required unless dataset_key is provided - `market_data_venue` (string): Live-data exchange; supply with quote_token - `provider` (string): Explicit external history provider - `quote_token` (string): Live-data quote; supply with market_data_venue - `signals` (array): Up to 20 registered signals to evaluate - `start_date` (string): Live-mode chart start timestamp; required unless dataset_key is provided - `symbol` (string): Live-mode asset symbol; required unless dataset_key is provided ### `evaluate_signal` (~89 tokens) 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.] Input parameters: - `market_data` (array, required) - `parameters` (object) - `signal_name` (string, required): Signal name ### `find_sweep_runs` (~1299 tokens) 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 parameters: - `asset` (string): Asset symbol, e.g. BTC or ETH. - `atr_period` (integer): Only runs that used this ATR period. Needs experiment_id. - `beats_benchmarks` (boolean): Only runs that beat all three benchmarks over the same - `beats_crypto_benchmarks` (boolean): Only runs that beat the crypto benchmarks rather than only their own asset. - `candle_size` (string): Duration of one candle, e.g. 1h or 1d. - `cooldown_bars` (integer): Only runs that used this cooldown. Needs experiment_id. - `covering` (string): Only runs over windows covering this single date, as YYYY-MM-DD. A different question from a span. - `covering_from` (string): Only runs whose window OVERLAPS this date onwards. A run is relevant to 2024 if any of it happened in 2024. - `covering_to` (string): Only runs whose window overlaps up to this date. - `experiment_id` (string): The sweep, as create_sweep returned it. - `generation` (string): Only runs from this engine generation, so runs made under different engine behaviour are not compared as though alike. - `limit` (integer): Maximum results. - `market_direction` (string): Only 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 k… - `max_delta_vs_asset` (number): Only runs beating their own asset by at most this much. - `max_delta_vs_benchmark` (number): Only 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. - `max_irr` (number): Only runs at or below this annualised IRR. - `max_return` (number): Only runs at or below this total return. - `max_risk_per_trade` (number): Only runs that risked this fraction per trade. Needs experiment_id. - `max_sharpe` (number): Only runs at or below this Sharpe ratio. - `max_trades` (integer): Only runs at or below this trade count. Pairs with min_trades to ask for a band rather than a floor. - `max_win_rate` (number): Only runs at or below this win rate. - `min_delta_vs_asset` (number): Only runs beating buy-and-hold on their own asset by at least this much. - `min_delta_vs_benchmark` (number): Only runs that beat their benchmark by at least this much. A return in a rising market is not skill. - `min_irr` (number): Only runs at or above this annualised IRR. - `min_return` (number): Only runs at or above this total return. - `min_sharpe` (number): Only runs at or above this Sharpe ratio. - `min_trades` (integer): Drop runs with fewer trades than this. Metrics from a handful of trades are noise. - `min_win_rate` (number): Only runs at or above this win rate. - `offset` (integer): Pagination offset in the result units documented by the tool; zero starts the first page. - `order` (string): desc for best-first on that metric, asc for worst-first. - `regime_composite` (string): Only 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… - `regime_direction` (string): The 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… - `reward_factor` (number): Only runs that used this reward-to-risk setting. Execution filters need experiment_id; the cross-sweep surface does not serve them. - `run_index` (integer): Which run, as find_sweep_runs reported it. - `run_status` (string): Only runs with this outcome, e.g. no_trades for the ones that never opened a position. - `sort_by` (string, required): The 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. - `trend` (string): Only runs from windows of this trend character, e.g. clean or choppy; several comma-separated, any of them counts. - `trigger_name` (string): Only runs whose entry trigger is this signal. - `volatility` (string): Only runs from windows of this volatility band, e.g. low; several comma-separated, any of them counts. ### `get_asset` (~118 tokens) 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.] Input parameters: - `symbol` (string, required): Asset symbol, e.g. BTC or ETH. ### `get_backtest` (~136 tokens) 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.] Input parameters: - `backtest_id` (string, required): The run's UUID, as run_backtest returned it. ### `get_backtest_trades` (~190 tokens) 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.] Input parameters: - `backtest_id` (string, required): The run's UUID, as run_backtest returned it. - `limit` (integer): Maximum results. - `offset` (integer): Pagination offset in the result units documented by the tool; zero starts the first page. ### `get_benchmark` (~227 tokens) 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.] Input parameters: - `asset` (string, required): Asset symbol, e.g. BTC or ETH. - `base_token` (string): Canonical base token; supply with quote_token and market_data_venue. - `end_date` (string, required): ISO end of the window. - `market_data_venue` (string): Exact venue of the requested market. - `quote_token` (string): Quote currency of the requested market. - `start_date` (string, required): ISO start of the window, e.g. 2026-01-01. ### `get_chain_tvl` (~117 tokens) 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.] Input parameters: - `chain` (string, required): Chain name or slug, e.g. ethereum or base. ### `get_etf_flows` (~107 tokens) 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.] ### `get_execution_config_schema` (~132 tokens) 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.] ### `get_global_market` (~102 tokens) 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.] ### `get_influence_score` (~134 tokens) 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.] Input parameters: - `username` (string, required): X/Twitter handle, with or without the leading @. ### `get_lending_rates` (~107 tokens) 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.] ### `get_market_data` (~231 tokens) 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.] Input parameters: - `market_data_venue` (string): Exact venue of the requested market. - `provider` (string): Optional upstream override; omitted uses the existing server default. - `quote_token` (string): Quote currency of the requested market. - `symbol` (string, required): Asset symbol, e.g. BTC or ETH. ### `get_market_regime` (~495 tokens) 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.] Input parameters: - `asset` (string, required): Asset symbol, e.g. BTC or ETH. - `lookback_days` (integer): Number of days of history to request. - `market_data_venue` (string): Exact venue of the requested market. - `provider` (string): Optional upstream override; omitted uses the existing server default. - `quote_token` (string): Quote currency of the requested market. ### `get_marketplace_strategy` (~129 tokens) 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.] Input parameters: - `strategy_id` (string, required): The strategy's UUID. ### `get_ohlcv` (~226 tokens) 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.] Input parameters: - `lookback_days` (integer): Number of days of history to request. - `market_data_venue` (string): Exact venue of the requested market. - `provider` (string): Optional upstream override; omitted uses the existing server default. - `quote_token` (string): Quote currency of the requested market. - `symbol` (string, required): Asset symbol, e.g. BTC or ETH. ### `get_onchain_series` (~318 tokens) 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.] Input parameters: - `chain` (string): Chain name or slug, e.g. ethereum or base. - `date_from` (string): ISO date string for the start of the window. - `date_to` (string): ISO date string for the end of the window. - `interval` (string): Candle size, e.g. 15m, 1h, 4h, 1d. - `metrics` (array, required): Metric names to include in the series. - `provider` (string): Optional upstream override; omitted uses the existing server default. - `symbol` (string, required): Asset symbol, e.g. BTC or ETH. - `top_n` (integer): Return only the first this many. ### `get_perp_funding_rates` (~98 tokens) 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.] ### `get_playground_data` (~30 tokens) Return OHLCV chart data for a specific playground dataset. Input parameters: - `dataset_key` (string, required) ### `get_protocol_tvl` (~123 tokens) 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.] Input parameters: - `protocol_name` (string, required): Protocol slug or display name, e.g. aave or uniswap. ### `get_signal` (~74 tokens) 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.] Input parameters: - `signal_name` (string, required): Signal name ### `get_smart_money_dex_trades` (~185 tokens) 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.] Input parameters: - `chains` (array): Optional list of chains to include. - `filters` (object): Optional filter object passed through to the upstream provider. - `order_by` (array): Optional ordering list passed through to the upstream provider. - `page` (integer): Page number for pagination. - `per_page` (integer): Page size for pagination. ### `get_smart_money_flows` (~242 tokens) 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.] Input parameters: - `chain` (string): Chain name or slug, e.g. ethereum or base. - `symbol` (string, required): Asset symbol, e.g. BTC or ETH. - `timeframe` (string): Aggregation window, e.g. 24h, 7d. ### `get_smart_money_historical_holdings` (~213 tokens) 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.] Input parameters: - `chains` (array): Optional list of chains to include. - `date_from` (string): ISO date string for the start of the window. - `date_to` (string): ISO date string for the end of the window. - `filters` (object): Optional filter object passed through to the upstream provider. - `order_by` (array): Optional ordering list passed through to the upstream provider. - `page` (integer): Page number for pagination. - `per_page` (integer): Page size for pagination. ### `get_smart_money_holdings` (~150 tokens) 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.] Input parameters: - `chains` (array): Optional list of chains to include. - `include_labels` (array): Smart-money wallet labels; omitted uses Fund and Smart Trader. - `limit` (integer): Maximum results. - `min_value_usd` (number): Minimum USD value to include. ### `get_smart_money_netflows` (~167 tokens) 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.] Input parameters: - `chains` (array): Optional list of chains to include. - `include_labels` (array): Smart-money wallet labels; omitted uses Fund and Smart Trader. - `limit` (integer): Maximum results. - `timeframe` (string): Aggregation window, e.g. 24h, 7d. ### `get_smart_money_perp_trades` (~172 tokens) 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.] Input parameters: - `filters` (object): Optional filter object passed through to the upstream provider. - `order_by` (array): Optional ordering list passed through to the upstream provider. - `page` (integer): Page number for pagination. - `per_page` (integer): Page size for pagination. ### `get_smart_money_sentiment` (~167 tokens) 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.] Input parameters: - `chain` (string): Chain name or slug, e.g. ethereum or base. - `symbol` (string, required): Asset symbol, e.g. BTC or ETH. ### `get_social_mentions` (~151 tokens) 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.] Input parameters: - `hours_back` (integer): Lookback window in hours. - `limit` (integer): Maximum results. - `topic` (string, required): Asset symbol, project name or free-form topic. ### `get_social_sentiment` (~233 tokens) 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.] Input parameters: - `hours_back` (integer): Lookback window in hours. - `topic` (string, required): Asset symbol, project name or free-form topic. ### `get_stablecoin_metrics` (~100 tokens) 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.] ### `get_strategy` (~134 tokens) 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.] Input parameters: - `name` (string): Its name, if the id is unknown. - `strategy_id` (string): The strategy's UUID. ### `get_symbol_exchanges` (~113 tokens) 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.] Input parameters: - `symbol` (string, required): Asset symbol, e.g. BTC or ETH. ### `get_token_dex_trades` (~241 tokens) 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.] Input parameters: - `chain` (string): Chain name or slug, e.g. ethereum or base. - `date_from` (string): ISO date string for the start of the window. - `date_to` (string): ISO date string for the end of the window. - `filters` (object): Optional filter object passed through to the upstream provider. - `order_by` (array): Optional ordering list passed through to the upstream provider. - `page` (integer): Page number for pagination. - `per_page` (integer): Page size for pagination. - `symbol` (string, required): Asset symbol, e.g. BTC or ETH. ### `get_token_flows` (~296 tokens) 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.] Input parameters: - `chain` (string): Chain name or slug, e.g. ethereum or base. - `date_from` (string): ISO date string for the start of the window. - `date_to` (string): ISO date string for the end of the window. - `filters` (object): Optional filter object passed through to the upstream provider. - `label` (string): Wallet category: smart_money, exchange, whale, public_figure, or top_100_holders. - `order_by` (array): Optional ordering list passed through to the upstream provider. - `page` (integer): Page number for pagination. - `per_page` (integer): Page size for pagination. - `symbol` (string, required): Asset symbol, e.g. BTC or ETH. ### `get_token_holders` (~142 tokens) 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.] Input parameters: - `symbol` (string, required): Asset symbol, e.g. BTC or ETH. ### `get_token_unlocks` (~103 tokens) 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_treasuries` (~96 tokens) 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.] ### `get_trending` (~98 tokens) 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.] ### `kb_get_document` (~282 tokens) 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. Input parameters: - `full` (boolean): Explicit full content download; cannot combine with offset or max_chars. - `max_chars` (integer): Page size, default 6000, capped at 12000 and the response budget. - `offset` (integer): Pagination offset in the result units documented by the tool; zero starts the first page. - `section_anchor` (string): Exact anchor from overview or search, required only for section view. - `slug` (string, required): The document slug. - `view` (string): Use overview for a brief summary and headings; section for a specific topic; content for document pages. ### `kb_get_signal_quick_reference` (~253 tokens) 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. Input parameters: - `full` (boolean): Explicit full content download; cannot combine with offset or max_chars. - `max_chars` (integer): Page size, default 6000, capped at 12000 and the response budget. - `offset` (integer): Pagination offset in the result units documented by the tool; zero starts the first page. - `section_anchor` (string): Exact anchor from overview or search, required only for section view. - `view` (string): Use overview for a brief summary and headings; section for a specific topic; content for document pages. ### `kb_glossary_get` (~116 tokens) 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. Input parameters: - `term` (string, required): The term to look up, case-insensitive. ### `kb_list_documents` (~58 tokens) 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. ### `kb_search` (~226 tokens) 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. Input parameters: - `expand` (boolean): Whether to expand synonyms; ignored when tags are set. - `limit` (integer): Maximum results. - `q` (string, required): The search text, in ordinary words. - `tag` (string): Restrict to one tag category; disables synonym expansion. - `tags` (array): Restrict to any of these tag categories; cannot combine with tag. ### `list_approved_assets` (~118 tokens) 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.] Input parameters: - `top_n` (integer): Return only the first this many. ### `list_backtest_markets` (~103 tokens) 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. Input parameters: - `asset` (string, required): Asset symbol, e.g. BTC or ETH. ### `list_backtests` (~156 tokens) 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.] Input parameters: - `limit` (integer): Maximum results. - `strategy_id` (string): The strategy's UUID. ### `list_exchanges` (~97 tokens) 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.] ### `list_playground_datasets` (~20 tokens) Return metadata for all available playground CSV datasets. ### `list_signal_labels` (~26 tokens) Every signal's friendly name, display name and short description, keyed by code name. ### `list_signals` (~214 tokens) 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.] Input parameters: - `category` (string): Filter by category (momentum, trend, volume, volatility, patterns, onchain) - `limit` (integer): Page size: default 30, maximum 30. Larger requests are capped; use next_offset to continue. - `offset` (integer): Pagination offset - `regime_direction` (string): Filter to signals admissible for a regime band (mega_bull, super_bull, bull, neutral, bear, super_bear, mega_bear) - `role` (string): Filter by the part a signal plays in a strategy (TRIGGER or FILTER) ### `list_strategies` (~84 tokens) 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. Input parameters: - `limit` (integer): Maximum results. ### `list_trades` (~270 tokens) 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.] Input parameters: - `asset` (string): Asset symbol, e.g. BTC or ETH. - `limit` (integer): Maximum results. - `outcome` (string): Only "win" or only "loss". - `strategy_id` (string): The strategy's UUID. ### `load_skill` (~197 tokens) 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. Input parameters: - `resource` (string): One file the skill carries, by name, as `resources` lists them. - `section` (string): One section of it, by heading. Omit for the whole skill. - `skill` (string, required): Which skill, by the name the turn announced. ### `match_signals` (~144 tokens) 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.] Input parameters: - `description` (string, required): Natural language description of the desired signal/rule - `regime_direction` (string): Market regime band - `role` (string): Signal role - `similarity_threshold` (number): Minimum similarity score to include - `top_k` (integer): Number of matches to return - `user_intent` (object): Optional intent dict (e.g., from intent extractor) ### `query_knowledge` (~1237 tokens) 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: f… Input parameters: - `bounded` (boolean): outputs: only values with a fixed range. - `direction` (string): neighbors: in = what reads this, out = what this depends on. - `hops` (integer): ask: how far to walk from each match. 0 restricts it to retrieval. Capped at 3; a higher value raises ValueError naming the cap. - `kind` (string): The class: what a computation measures. - `limit` (integer): Maximum results. - `max_depth` (integer): path, paths: how long a route may be. path defaults to 6; paths defaults to 4 and is capped at 4 -- past that almost every extra route is a detour through a hub rather than an explanation. - `max_nodes` (integer): walk: stop expanding once this many nodes are collected. - `op` (string, required): Which question you are asking. - `param` (string): find: a parameter name -- every signal that takes it. - `primitive` (string): neighbors: keep only neighbours of this node primitive, e.g. Procedure or Concept. - `q` (string): The search text, in ordinary words. - `radius` (integer): walk: how many hops out the neighbourhood reaches. Capped at 3; for anything wider call neighbors or path instead of a bigger radius. - `relation` (string): neighbors: follow only this one relation. - `relation_category` (string): neighbors: follow only edges of this whole relation category (structural, descriptive, associative, meta) -- see stats for the list. - `relations` (array): path, paths, ask: follow only these relations. - `requires` (string): An input column it needs. - `role` (string): The part a signal plays in a strategy. - `seeds` (integer): ask: how many top matches to expand from before re-ranking. - `sibling_hops` (boolean): paths: include routes that pass through a shared parent (both nodes are, say, Signal) rather than a direct connection. Off by default -- those routes are usually not the explanation. - `status` (string): Whether the thing is current or withdrawn. - `to` (string): path, paths: the destination node. - `units` (string): The unit an output is measured in. - `why` (string): neighbors, walk, ask: keep only edges whose own stated reason matches these words -- the same relation can carry different claims. ### `query_signal_behavior` (~440 tokens) 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.] Input parameters: - `category` (string): find: restrict to one family, e.g. oscillator, volatility, momentum - `limit` (integer): Maximum results, 1-100 - `lookup` (string, required): describe: one signal -- parameter meanings, measured span, what its default measures. pick: settings of one signal that hit target_rate. find: which signals reach a rate band. gap_probability: share… - `max_gap_bars` (number): pick/find, TRIGGER only: median gap at most this many bars - `max_gap_range_bars` (number): gap_probability: high end of the gap range, inclusive (required) - `max_rate` (number): find: high end of the band, same units (required) - `max_run_bars` (number): pick/find, FILTER only: mean run at most this many bars - `min_gap_bars` (number): pick/find, TRIGGER only: median gap at least this many bars - `min_gap_range_bars` (number): gap_probability: low end of the gap range, inclusive (required) - `min_rate` (number): find: low end of the band, same units (required) - `min_run_bars` (number): pick/find, FILTER only: mean run at least this many bars - `signal` (string): Signal name, e.g. rsi_oversold. Required by describe, pick, gap_probability - `signal_type` (string): FILTER (an ongoing state) or TRIGGER (a one-bar event); measured separately - `target_rate` (number): pick: rate to aim for -- FILTER selectivity 0-1, TRIGGER firings per 1,000 bars. Omit to list the span ### `run_backtest` (~487 tokens) 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.] Input parameters: - `acknowledge_defaults` (boolean): Pass True to submit even though signal parameters are at their library defaults -- an explicit statement that the defaults were considered and stood by, never a way to skip considering them. - `end_date` (string, required): ISO end of the window. - `engine_generation` (integer): Only set when the person specifies an engine generation; omitted uses latest. - `market_data_venue` (string): Exact venue of the requested market. - `quote_token` (string): Quote currency of the requested market. - `start_date` (string, required): ISO start of the window, e.g. 2026-01-01. - `strategy_id` (string, required): The strategy's UUID. ### `save_strategy` (~772 tokens) 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.] Input parameters: - `asset` (string, required): Asset symbol, e.g. BTC or ETH. - `constraints` (object): Execution values the person stated, e.g. {"max_risk_per_trade": 0.01}. Each is kept exactly as given rather than nudged. - `entry_signals` (array): The signals that open a position. Exactly one must be a TRIGGER in the knowledge graph; the rest are FILTERs. - `exit_signals` (array): The signals that close one, same shape. A strategy may have none, and then it exits on risk rules alone. - `market_data_venue` (string): Exact venue of the requested market. - `quote_token` (string): Quote currency of the requested market. - `regime_direction` (string): The 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… - `regime_override` (boolean): Save anyway when the regime check refuses. Only ever on the person's explicit say-so, after they have been told why. - `source_config_hash` (string): The selected row's config_hash, as find_sweep_runs reported it. Pass it with the other two: a relaunched sweep can give one run_index to several runs, and without it such an index is refused. - `source_experiment_id` (string): For a sweep pick, its experiment ID. Supply with source_run_index. The stored run supplies the exact signals and execution settings. With no market given, it saves on the run's corpus market, or on t… - `source_run_index` (integer): The selected sweep row, including zero. - `strategy_name` (string, required): What to call it, in plain words a person reads -- the entry trigger's friendly_name from the knowledge graph, then the asset and timeframe, e.g. "Upside Range Breakout - BTC 1h". Never a code name su… ### `screen_candidates` (~293 tokens) 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.] Input parameters: - `asset` (string, required): Asset symbol, e.g. BTC or ETH. - `candidates` (array, required): Each {entry: [{name, params?, timeframe?}], exit: [...]}. ### `screen_smart_money` (~161 tokens) 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.] Input parameters: - `chains` (array): Optional list of chains to include. - `limit` (integer): Maximum results. - `timeframe` (string): Aggregation window, e.g. 24h, 7d. ### `search_marketplace` (~823 tokens) 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.] Input parameters: - `asset` (string): Asset symbol, e.g. BTC or ETH. - `asset_class` (array): Keep listings in these asset classes. Platform listings are all digital_assets; stocks, options and futures exist only as NexusTrade partner listings the chat cannot reach. - `backtest_direction` (string): Keep listings backtested in this market direction, e.g. bull, neutral or bear -- the band get_market_regime reports; or unclassified. - `backtest_trend` (string): Keep listings backtested in this trend character, e.g. clean, choppy; or unclassified. - `backtest_volatility` (string): Keep listings backtested in this volatility band, e.g. low, medium, high; or unclassified. - `beats_all_benchmarks` (boolean): Keep only listings whose return beat BTC, ETH and the S&P over their own window. - `candle_size` (string): Duration of one candle, e.g. 1h or 1d. - `free_only` (boolean): Keep only listings with no subscription price. - `limit` (integer): Maximum results. - `max_drawdown_pct` (number): Keep listings whose max drawdown is at or below this, in percent. - `min_calmar_ratio` (number): Keep listings at or above this Calmar ratio. - `min_gain_to_pain_ratio` (number): Keep listings at or above this gain-to-pain ratio. - `min_irr_pct` (number): Keep listings at or above this annualised IRR, in percent. - `min_sharpe_ratio` (number): Keep listings at or above this Sharpe ratio. - `min_sortino_ratio` (number): Keep listings at or above this Sortino ratio. - `min_total_return_pct` (number): Keep listings at or above this total return, in percent. - `min_total_trades` (integer): Keep listings with at least this many trades. - `min_trades_per_week` (number): Keep listings trading at least this often, per week. - `min_win_rate_pct` (number): Keep listings at or above this win rate, in percent. - `offset` (integer): Pagination offset in the result units documented by the tool; zero starts the first page. - `order` (string): desc for best-first on that metric, asc for worst-first. - `risk_level` (array): Keep listings at any of these risk levels, e.g. low, medium, high. - `search` (string): Free text matched against listing name, description and creator. - `sort` (string): The column to order by. Omitted, the marketplace's trending order. ### `search_signals` (~133 tokens) 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.] Input parameters: - `category` (string): Signal library module - `limit` (integer): Maximum results - `offset` (integer): Pagination offset - `query` (string, required): Search query string - `regime_direction` (string): Market regime band - `role` (string): Signal role - `search_type` (string): Type of search ### `update_strategy` (~439 tokens) 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.] Input parameters: - `constraints` (object): Execution values the person stated, e.g. {"max_risk_per_trade": 0.01}. Each is kept exactly as given rather than nudged. - `entry_signals` (array): The signals that open a position. Exactly one must be a TRIGGER in the knowledge graph; the rest are FILTERs. - `exit_signals` (array): The signals that close one, same shape. A strategy may have none, and then it exits on risk rules alone. - `regime_direction` (string): The 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… - `regime_override` (boolean): Save anyway when the regime check refuses. Only ever on the person's explicit say-so, after they have been told why. - `strategy_id` (string, required): The strategy's UUID. - `strategy_name` (string): What to call it, in plain words a person reads -- the entry trigger's friendly_name from the knowledge graph, then the asset and timeframe, e.g. "Upside Range Breakout - BTC 1h". Never a code name su… ### `validate_signal_params` (~78 tokens) 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.] Input parameters: - `parameters` (object) - `signal_name` (string, required): Signal name ### `verify_strategy` (~200 tokens) 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.] Input parameters: - `strategy_id` (string, required): The strategy's UUID. ### `discover_tools` (~110 tokens) 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. Input parameters: - `areas` (array): Functional area names returned by detail=areas. - `detail` (string): Output detail. The areas index takes no selectors. - `names` (array): One or any number of exact advertised tool names. ## Diagnostics Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/mangrovetechnologies-mangroveai/api#diagnostics ## Score history - 2026-10-23: 62 - 2026-10-22: 61 ## Common questions ### What is the MangroveAI MCP server? MangroveAI is an MCP server listed in the public MCP registry as io.github.MangroveTechnologies/mangroveai. Backtest and paper-trade crypto strategies. Free API key or pay per call in USDC (x402). This page covers its hosted endpoint (https://api.mangrovedeveloper.ai/mcp/). ### Is the MangroveAI MCP server safe to use? MangroveAI scores 62 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm. ### What tools does the MangroveAI MCP server expose? MangroveAI exposes 76 tools: delete_strategy, update_strategy_status, get_trades_for_strategy, list_positions, evaluate_strategy, and 71 more. Their descriptions and schemas cost roughly 16,545 tokens of context every time the server is loaded. ### Does the MangroveAI MCP server require authentication? No. We connected to MangroveAI without credentials and it answered, so anything it exposes is reachable by anyone who knows the address. ### Is the MangroveAI MCP server still maintained? MangroveAI is still listed as active in the MCP registry. We last reached this channel on 23 October 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced. ## Links - Remote endpoint: https://api.mangrovedeveloper.ai/mcp/ - Repository: https://github.com/MangroveTechnologies/mangrove-agent - Website: https://mangrove.ai/agents/ - Changelog RSS feed: https://verifymcp.io/servers/mangrovetechnologies-mangroveai/api.xml - Changelog JSON feed: https://verifymcp.io/servers/mangrovetechnologies-mangroveai/api.json - HTML version of this page: https://verifymcp.io/servers/mangrovetechnologies-mangroveai/api