Skip to main content
Glama

MangroveAI

by io.github.MangroveTechnologies
OverviewDiscussionsAdmin

update_strategy

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 Schema

NameRequiredDescriptionDefault
constraintsNoExecution values the person stated, e.g. {"max_risk_per_trade": 0.01}. Each is kept exactly as given rather than nudged.
strategy_idYesThe strategy's UUID.
exit_signalsNoThe signals that close one, same shape. A strategy may have none, and then it exits on risk rules alone.
entry_signalsNoThe signals that open a position. Exactly one must be a TRIGGER in the knowledge graph; the rest are FILTERs.
strategy_nameNoWhat 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 such as btc_strategy or bb_upper_breakout.
regime_overrideNoSave anyway when the regime check refuses. Only ever on the person's explicit say-so, after they have been told why.
regime_directionNoThe direction band from get_market_regime, e.g. bear. The signal searches filter by it and find_sweep_runs marks each row's regime_fit with it; save_strategy and update_strategy read the current band themselves, so their check runs without it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so well: signals are replaced wholesale rather than merged, constraints merge onto stored execution config, and backtested strategies cannot be edited in place. It also discloses payment and authentication behavior for access.

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

Conciseness5/5

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

The description is front-loaded with the core action and immediately follows with the most important constraints. Every sentence adds useful behavioral or access information, including the payment/auth note, with no wasted text.

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

Completeness5/5

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

For a complex mutation tool with no annotations and no output schema, the description covers the critical gaps: eligible strategy state, replacement versus merge semantics, the save_strategy alternative, and access/payment requirements. An agent has enough context to call it correctly and avoid common misuses.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds important semantics not captured by the schema: entry and exit signal lists replace stored signals rather than merging, while constraints merge into execution config. It does not add much for the remaining parameters, but the nested replacement behavior is a meaningful clarification.

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

Purpose5/5

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

The description states a specific verb and resource: change a DRAFT strategy in place, covering signals, parameters, and execution values. It clearly distinguishes this from save_strategy for strategies that have already been backtested.

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

Usage Guidelines5/5

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

It explicitly states when this tool can be used (only a draft that has never been backtested) and when not (after a backtest the rules are frozen). It also names the alternative, save_strategy, for creating a new strategy and explains a concrete use case: acting on verify_strategy warnings without creating a duplicate.

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

All MangroveAI toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources