Create plan
create_planCreates 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, this call succeeds non-destructively by returning that active plan with reusedExisting=true; 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.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | ||
| items | Yes | ||
| title | Yes | ||
| conversationId | No | Optional conversation UUID. Omit this field to use the current MCP conversation context; never pass placeholders such as `current`. | |
| replaceExisting | No | Set true only when an existing active plan is obsolete or the user explicitly changed the work. Omit this for normal continuation. | |
| supersedesPlanId | No | The active plan UUID being replaced. Use get_active_plan first if you do not know it. | |
| replacementReason | No | Required when replaceExisting=true. Explain why the current active plan is being cancelled instead of updated. |