MangroveAI

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: f…

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