Skip to main content
Glama

BotSpot: AI Trading, Backtests and Bots

Create plan

create_plan
Destructive

Creates a persisted, user-visible plan for substantial work in the current conversation. Use this for strategy builds, strategy edits, research, deployment setup, backtest analysis, broker investigation, and other multi-step tasks. Do not use this for greetings, small talk, simple answers, advice-only turns, critique-only turns, ordinary clarification, or no-op connectivity checks such as a current user message that is only 'test', 'ping', or 'testing'. Do not use this for preliminary discovery research whose purpose is deciding what to build, including broad outcome-only, vague profit, generic best-strategy, or underspecified make/build-something requests. Search first, summarize opportunities and risks, and ask concise build-choice questions without creating a plan or possible future build-step items. Forbidden sequence: broad/underspecified profitable or current-market build request -> web_search -> create_plan in the same turn. Your own recommendation after search is only a proposal; wait for the user's follow-up choice or acceptance before creating a plan. If you only need a user clarification before doing work, do not create a plan yet. If a plan already exists and user input is needed before continuing, use update_plan_item to mark the current item waiting with waitReason=waiting_for_user before asking the user. If an active plan already exists and replaceExisting is omitted, a valid creation request succeeds non-destructively by returning that active plan with reusedExisting=true. This is not an empty-items lookup: items still requires at least one actual item. Reuse the returned plan/id or call get_active_plan for readback; continue it with update_plan_item, add_plan_item, replace_plan_items, or complete_plan. A true replacement remains explicit: set replaceExisting=true, pass supersedesPlanId, and include replacementReason only when the existing plan is obsolete or the user changed the work. This does not create or modify strategies, backtests, deployments, trades, or tool access. Do not send a top-level rationale field. At the top level use only the documented plan fields; put item-specific rationale, evidence, status, and outcome inside the relevant items[] object. Every item must include the exact field completionCriteria with model-visible completion criteria so the agent has a concrete standard for marking it done. Domain-specific policy belongs in prompts and skills. This tool only persists the visible plan that the model provides. Plan items progress in visible order; outcome.status is plan-item satisfaction, not backtest.status or another external status. A partial or unsuccessful outcome does not by itself require a new row. Add a referenced follow-up only when genuinely new executable work is not already represented by a later plan item; otherwise keep limitations and fallback assumptions in the existing item's evidence and continue the existing plan. This is only the visible plan; after it is created, continue using the relevant domain tools instead of answering with only prose.

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": {
      "title": "<title>",
      "items": "<items>"
    },
    "name": "create_plan"
  }
}

Input Schema

NameRequiredDescriptionDefault
kindNo
itemsYesAt least one actual plan item is required, including a create/reuse request. To read or continue an existing plan, reuse its returned id or call get_active_plan; do not call create_plan with empty items as a lookup.
titleYes
conversationIdNoOptional conversation UUID. Omit this field to use the current MCP conversation context; never pass placeholders such as `current`.
replaceExistingNoSet true only when an existing active plan is obsolete or the user explicitly changed the work. Omit this for normal continuation.
supersedesPlanIdNoThe active plan UUID being replaced. Use get_active_plan first if you do not know it.
replacementReasonNoRequired when replaceExisting=true. Explain why the current active plan is being cancelled instead of updated.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / items / description
      Added value: +"At least one actual plan item is required, including a create/reuse request. To read or continue an existing plan, reuse its returned id or call get_active_plan; do not call create_plan with empty items as a lookup."
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, but the description adds concrete behavior beyond them: the non-destructive reuse path returning reusedExisting=true when replaceExisting is omitted, and the explicit replacement path requiring replaceExisting=true plus supersedesPlanId and replacementReason. It further bounds the blast radius by stating it does not create or modify strategies, backtests, deployments, trades, or tool access.

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?

The purpose and exclusions are front-loaded, but the description is a dense wall of policy text with restatement: 'This is only the visible plan', 'This tool only persists the visible plan that the model provides', and 'This does not create or modify strategies...' all circle the same point, and the empty-items rule repeats the schema's own description.

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 destructive, multi-parameter creation tool with no output schema, the description covers the safety profile, the reuse-versus-replace decision, the post-creation continuation path, and the field-placement rules. An agent has everything needed to call it correctly and to know what to do next.

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

Parameters5/5

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

Schema coverage is 71%, but the description adds meaning the schema does not: omit conversationId rather than passing a placeholder such as 'current', use replaceExisting only when the plan is obsolete or the work changed, do not send a top-level `rationale`, and put item-specific rationale/evidence/status inside items[]. It also clarifies that every item needs the exact field completionCriteria and that outcome.status is plan-item satisfaction rather than an external backtest or deployment status.

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 first sentence states a specific verb and resource with scope: 'Creates a persisted, user-visible plan for substantial work in the current conversation.' It also implicitly separates itself from the sibling plan tools by describing what it persists versus 'This is not an empty-items lookup' and the readback path via get_active_plan.

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 enumerates both when to use (strategy builds, research, deployment setup, backtests, multi-step tasks) and an explicit exclusion list (greetings, small talk, advice-only turns, 'ping'/'test' messages), plus a named 'forbidden sequence' involving web_search and a required wait for user acceptance before planning. It also routes continuing work to update_plan_item, add_plan_item, replace_plan_items, complete_plan, and get_active_plan, leaving little to inference.

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.