BotSpot: AI Trading, Backtests and Bots

Preview a schedule or save a schedule draft

manage_schedule

Destructive

Read existing schedules and their backend status, preview a proposed schedule, or save a detached schedule draft that no bot uses yet. The list and status actions are read-only. A running bot's schedule can never be changed here: a bot and its schedule are one thing. To run a bot at a different time, stop it with stop_deployment and start a new one with start_deployment and the schedule you want; the owner approves both.

Set "action" to choose the operation. Only send the fields listed for that action.

action="preview": Preview a schedule policy

Required fields: scheduleMetadata. Preview how BotSpot would route a proposed scheduleMetadata object. This does not start a bot. Use this before starting a scheduled bot with start_deployment.

action="create": Save a schedule draft

Required fields: strategyId, scheduleMetadata. Saves a detached schedule draft that no bot uses yet, for example to show the owner a proposed schedule. It never touches a running bot. Initial schedules use start_deployment. To change an existing bot schedule, use update_deployment_revision with the requested scheduled mode and exact schedule. The owner reviews one Update approval on the website before replacement.

action="list": List schedules

No other fields required. Lists intended schedule policies and current Bot Manager backend truth for the signed-in user, including runtime drift.

action="status": Get schedule status

Required fields: schedulePolicyId. Returns one intended schedule policy plus its current backend schedules, expressions, timezone, enabled state, policy hash, and drift.

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": {
      "action": "<action>"
    },
    "name": "manage_schedule"
  }
}

Input Schema

Name	Required	Description	Default
`action`	Yes	Which operation to run: "preview", "create", "list", "status". See the tool description for each one.
`source`	No	Used with action="create".	user_instruction
`revisionId`	No	Used with action="create".
`strategyId`	No	Used with action="create". Required for action="create".
`deploymentMode`	No	Used with action="preview".	auto
`idempotencyKey`	No	Used with action="create".
`scheduleMetadata`	No	Used with action="preview", action="create". Required for action="preview", action="create".
`schedulePolicyId`	No	Used with action="status". Required for action="status".

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations declare destructiveHint=true and readOnlyHint=false, and the description adds real nuance the annotations cannot express: list/status are read-only, create "never touches a running bot", and changes to a live bot require an owner-approved stop/start or Update approval. It does not address idempotency (annotations say idempotentHint=false) or what a create call returns, so not a 5, but there is no contradiction with the annotations.

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?

Front-loaded summary followed by clearly headed per-action sections keyed to the action enum values, which is the right structure for a four-action tool with a deeply nested schema. Minor waste: "This does not start a bot" and "It never touches a running bot" restate the same non-mutation point.

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 complex branching tool with a large nested scheduleMetadata schema and no output schema, the description covers purpose, routing, and required fields per action well. The gap is return semantics: list and status are described, but what preview returns (a routing verdict? normalized cadence?) and what create returns (a draft ID?) is left unspecified.

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 adds per-action field grouping (scheduleMetadata for preview, strategyId+scheduleMetadata for create, schedulePolicyId for status) plus the contract "Only send the fields listed for that action." That grouping is a genuine constraint beyond the flat schema, though the individual field meanings remain in the schema.

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 opening sentence names three concrete capabilities (read/list schedules and backend status, preview a proposed schedule, save a detached draft) and each action section states a specific verb+resource ("Preview how BotSpot would route...", "Saves a detached schedule draft", "Lists intended schedule policies"). It also explicitly distinguishes this tool from start_deployment and update_deployment_revision, so an agent can tell it apart from siblings without reading schemas.

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?

Guidance is unusually explicit: "Use this before starting a scheduled bot with start_deployment", "Initial schedules use start_deployment. To change an existing bot schedule, use update_deployment_revision...", and the exclusion "A running bot's schedule can never be changed here." Each action names its use case plus the alternative tool that handles the case this one does not.

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

All BotSpot: AI Trading, Backtests and Bots tools Inspect

Try in Browser