OpenInvest

set_allocations

Idempotent

Set a strategy's target stock/cash ratio and per-asset weights, plus price alerts, with atomic validation to keep allocations accurate and prevent corrupt files.

Instructions

Update the strategy's target allocation: the stock/cash ratio and/or the per-asset target weights that rebalance_plan reads, and/or the per-asset alert lines the price sentinel watches. The stock and cash values must sum to ≈1.0, and the per-asset weights must sum to at most the stock target; schema validation rejects and rolls back any write that would corrupt the strategy file. Everything in one call is validated and written atomically — to lower the stock target below the current sum of per-asset weights, pass the new weights in the same call.

Use when the user says e.g. "set my target to 70% stock / 30% cash" or "put 30% in 510300.SS and 20% in gold".

Args: target_allocation_stock: Stock weight in [0, 1], e.g. 0.7 (with cash). target_allocation_cash: Cash weight in [0, 1], e.g. 0.3 (with stock). target_pcts: {symbol: weight in [0, 1]} per tracked asset; null clears. alerts: {symbol: {rule: value}} alert lines per tracked asset; null clears a rule (or, for a whole symbol, all its rules).

Returns: The updated allocation and target assets, or {"status": "error", "error": ...}.

Input Schema

Name	Required	Description
`alerts`	No	Per-asset alert lines as {symbol: {rule: value}}, rule in price_above / price_below / day_drop_pct / day_rise_pct / drawdown_from_cost_pct, e.g. {'GC=F': {'price_below': 900, 'day_drop_pct': 2}}. Rules you name overwrite, a null rule value clears just that rule, rules you don't mention stay; a null for the whole symbol clears all its alerts. Symbols must already be tracked. *_pct values are percentage points (3 = 3%), unlike target_pct. Alerts are only delivered when INVEST_EVENT_ALERT=1 is set on the server.
`target_pcts`	No	Per-asset target weights as {symbol: fraction of total assets in [0, 1]}, e.g. {'510300.SS': 0.3, 'GC=F': 0.2}. Symbols must already be tracked (see track_asset). A null value clears that asset's target (back to an equal split). The weights must sum to <= target_allocation_stock (the new one if you pass it in the same call).
`target_allocation_cash`	No	Cash weight in [0, 1], e.g. 0.3. Pass together with target_allocation_stock; omit both to leave the split unchanged.
`target_allocation_stock`	No	Stock weight in [0, 1], e.g. 0.7. Pass together with target_allocation_cash (they must sum to ~1.0); omit both to leave the stock/cash split unchanged.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed15 schema fields changedv0.45.1Oct 19, 2026

addedInput schema / properties / alerts

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": {
+        "anyOf": [
+          {
+            "additionalProperties": {
+              "anyOf": [
+                {
+                  "type": "number"
+                },
+                {
+                  "type": "null"
+                }
+              ]
+            },
+            "type": "object"
+          },
+          {
+            "type": "null"
+          }
+        ]
+      },
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Per-asset alert lines as {symbol: {rule: value}}, rule in price_above / price_below / day_drop_pct / day_rise_pct / drawdown_from_cost_pct, e.g. {'GC=F': {'price_below': 900, 'day_drop_pct': 2}}. Rules you name overwrite, a null rule value clears just that rule, rules you don't mention stay; a null for the whole symbol clears all its alerts. Symbols must already be tracked. *_pct values are percentage points (3 = 3%), unlike target_pct. Alerts are only delivered when INVEST_EVENT_ALERT=1 is set on the server.",
+  "title": "Alerts"
+}

addedInput schema / properties / target_allocation_cash / anyOf

Added value: +[
+  {
+    "maximum": 1,
+    "minimum": 0,
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / target_allocation_cash / default
```
Added value: +null
```

changedInput schema / properties / target_allocation_cash / description

Previous value: -"Cash weight in [0, 1], e.g. 0.3. Must sum to ~1.0 with stock."New value: +"Cash weight in [0, 1], e.g. 0.3. Pass together with target_allocation_stock; omit both to leave the split unchanged."

removedInput schema / properties / target_allocation_cash / maximum
```
Removed value: -1
```
removedInput schema / properties / target_allocation_cash / minimum
```
Removed value: -0
```
removedInput schema / properties / target_allocation_cash / type
```
Removed value: -"number"
```

addedInput schema / properties / target_allocation_stock / anyOf

Added value: +[
+  {
+    "maximum": 1,
+    "minimum": 0,
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / target_allocation_stock / default
```
Added value: +null
```

changedInput schema / properties / target_allocation_stock / description

Previous value: -"Stock weight in [0, 1], e.g. 0.7. Must sum to ~1.0 with cash."New value: +"Stock weight in [0, 1], e.g. 0.7. Pass together with target_allocation_cash (they must sum to ~1.0); omit both to leave the stock/cash split unchanged."

removedInput schema / properties / target_allocation_stock / maximum
```
Removed value: -1
```
removedInput schema / properties / target_allocation_stock / minimum
```
Removed value: -0
```
removedInput schema / properties / target_allocation_stock / type
```
Removed value: -"number"
```

addedInput schema / properties / target_pcts

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": {
+        "anyOf": [
+          {
+            "type": "number"
+          },
+          {
+            "type": "null"
+          }
+        ]
+      },
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Per-asset target weights as {symbol: fraction of total assets in [0, 1]}, e.g. {'510300.SS': 0.3, 'GC=F': 0.2}. Symbols must already be tracked (see track_asset). A null value clears that asset's target (back to an equal split). The weights must sum to <= target_allocation_stock (the new one if you pass it in the same call).",
+  "title": "Target Pcts"
+}

removedInput schema / required

Removed value: -[
-  "target_allocation_stock",
-  "target_allocation_cash"
-]

Addedv0.31.7Jul 18, 2026
Removedv0.31.5Jul 17, 2026
Changed6 schema fields changedv0.31.4Jul 17, 2026
- addedInput schema / properties / target_allocation_cash / description
```
Added value: +"Cash weight in [0, 1], e.g. 0.3. Must sum to ~1.0 with stock."
```
- addedInput schema / properties / target_allocation_cash / maximum
```
Added value: +1
```
- addedInput schema / properties / target_allocation_cash / minimum
```
Added value: +0
```
- addedInput schema / properties / target_allocation_stock / description
```
Added value: +"Stock weight in [0, 1], e.g. 0.7. Must sum to ~1.0 with cash."
```
- addedInput schema / properties / target_allocation_stock / maximum
```
Added value: +1
```
- addedInput schema / properties / target_allocation_stock / minimum
```
Added value: +0
```
First observedv0.31.0Jul 16, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already declare mutation (`readOnlyHint: false`), idempotency, and non-destructiveness, but the description adds substantial behavioral context: writes are validated and atomic, invalid writes roll back, clearing semantics differ for rules vs whole symbols, and alerts are only delivered when `INVEST_EVENT_ALERT=1` is set.

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

Conciseness4/5

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

The description is front-loaded with purpose and usage, then organized into Args and Returns. Some Args content duplicates the already rich schema descriptions, but the structure remains clear and the extra detail is not harmful.

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?

Given a mutation tool with four optional parameters, rich annotations, an output schema, and nested alert/target maps, the description supplies the remaining operational context: atomic validation, rollback behavior, sum constraints, and alert delivery prerequisites. Nothing critical appears missing for correct invocation.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents each parameter thoroughly, including examples, clearing behavior, and percentage-point semantics for alerts. The description's Args section largely restates those constraints rather than adding new parameter-level meaning.

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?

States a specific verb (update) and resource (strategy target allocation) with the exact fields affected: stock/cash ratio, per-asset target weights, and alert lines. It also names related consumers (`rebalance_plan` and the price sentinel), making the tool distinguishable from siblings.

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

Usage Guidelines4/5

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

Gives concrete user-utterance examples such as 'set my target to 70% stock / 30% cash' and 'put 30% in 510300.SS and 20% in gold'. It also explains a key conditional workflow: lowering the stock target below current per-asset weights requires passing new weights in the same call. It does not provide explicit when-not-to-use guidance or name sibling alternatives for adjacent tasks.

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