Skip to main content
Glama

BotSpot: AI Trading, Backtests and Bots

Update plan items

update_plan_items
DestructiveIdempotent

Applies multiple user-visible plan item updates atomically in the listed order. Use this for handoffs between existing rows and multi-row reconciliation: first resolve the current item, then start the next existing item in the same ordered updates array. Preserve completed attempts; use unresolved rows or new linked follow-up work instead of reopening them. Each update target is required and must be {type:"id", itemId} or {type:"position", position}; each update has a patch object. Do not update the same target item twice in one update_plan_items call. If a validation attempt is unsuccessful, one update may mark that current item completed with outcome.status="unsuccessful" or "partial" and evidence; follow-up work references the attempt. This tool cannot create a new plan item or future position; use add_plan_item with a nested item object, or replace_plan_items when you need to resolve existing rows and add a new row in one visible plan mutation. Do not use this tool to target a future validation position before or after a domain tool returns an external id. After that tool returns, either update only the existing item here and then call add_plan_item, or use replace_plan_items for the whole visible list. When working in the current conversation, omit planId unless you already have the actual plan UUID; never pass a plan item id as planId. The final visible plan must still be ordered and must have at most one in_progress item. This is a normal model-owned plan mutation tool, not hidden backend reconciliation. It does not perform domain work, hide tools, or change backtests, deployments, trades, files, or strategy state.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "updates": "<updates>"
    },
    "name": "update_plan_items"
  }
}

Input Schema

NameRequiredDescriptionDefault
planIdNoOptional plan UUID. In the current conversation, omit planId unless you already have the actual plan id from get_active_plan or a wake message. Never pass a plan item id here; target plan items through target.itemId or target.position.
updatesYesOrdered item patches to apply atomically. Use this instead of multiple parallel update_plan_item calls.
conversationIdNoOptional conversation UUID. Omit this field to use the current MCP conversation context; never pass placeholders such as `current`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare destructive=true and idempotent=true, but the description adds real behavioral context beyond them: atomic all-or-nothing application in listed order, prohibition on duplicate targets, preservation of completed attempts, and the invariant that the final visible plan stays ordered with at most one in_progress item. It also scopes side effects ('does not perform domain work... or change backtests, deployments, trades, files, or strategy state'), though it does not say what happens to an item whose patch sets status='removed', which is the most consequential destructive path.

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

Conciseness3/5

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

Front-loaded with the core operation and constraint set, but it runs long and repeats itself — replace_plan_items and add_plan_item are each introduced twice, and the planId warning duplicates the schema's own wording. The closing 'normal model-owned plan mutation tool' sentence is defensiveness that could be compressed into one clause.

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

Completeness4/5

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

For a destructive, atomic, multi-target mutation with no output schema, the description covers the ordering, target constraints, invariant enforcement, and escape hatches an agent needs before calling. The remaining gap is failure and return semantics: it never says whether a rejected update aborts the whole array (implied by 'atomically') or what the response contains.

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; the description still earns credit by stating the two legal target shapes explicitly and adding a rule the schema cannot express ('Do not update the same target item twice in one call'). The planId caution ('omit unless you already have the actual plan UUID; never pass a plan item id as planId') largely restates the schema field description, and the many patch subfields (parentItemId, dependsOnItemIds, revisionId) are never mentioned in prose.

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?

Opens with a specific verb, resource, and scope: 'Applies multiple user-visible plan item updates atomically in the listed order.' It also names the singular and plural siblings (update_plan_item, add_plan_item, replace_plan_items) so an agent can distinguish row-level vs multi-row vs create-and-replace intent without opening a schema.

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?

Explicit when-to-use ('handoffs between existing rows', 'multi-row reconciliation'), explicit when-not ('cannot create a new plan item or future position'), and explicit alternatives with the condition that selects each (add_plan_item for new items, replace_plan_items when resolving rows and adding a row in one visible mutation). It even covers the sequencing rule around domain tools returning an external id.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.