Skip to main content
Glama

BotSpot: AI Trading, Backtests and Bots

Run an existing scheduled bot once

run_deployment_once
Destructive

HIGH RISK: request owner approval for one immediate iteration of an existing scheduled bot. Use this for run once, an extra run, or retrying a missed iteration. It can place live trades. Preserves the saved revision, broker, variables, recurring schedule, history and state. Current balance and holdings reports are not prerequisites; use the exact saved deployment and broker connection status. Preparation reads the saved connection status and mode and refuses an approval unless that status is connected and the mode matches the deployment. A returned pending approval means that saved-state check passed at preparation; it is not a fresh broker RPC, an executed run, or a guarantee of later execution. Do not request another reconnect from an old skipped run alone; require a current structured reconnect-required result. Does not stop, restart, replace or update the bot. Refuses overlapping runs. An explicit restart uses update_deployment_revision, including a request to restart and run immediately. If unavailable, explain the limitation; never substitute start_deployment or update_deployment_revision. For run_deployment_once, the authorization status describes approval and dispatch, not the strategy iteration. Pending approval means no strategy iteration has started. A completed action with metadata.executionResult.status=launched means launch accepted; completion and trades remain unverified. A skipped result started no new iteration. An already_recorded result is a duplicate dispatch; inspect its run_id, last_run_status and run history. A failed or unconfirmed dispatch without terminal run evidence leaves the iteration outcome unknown. Inspect run history before any new request; do not automatically retry or infer that the run failed or finished. A balance or holdings report does not verify iteration completion. Answer questions about whether the RUN finished from iteration evidence: launched means completion is unverified. Do not lead with Yes and then qualify it when only the approval completed or launch was accepted.For Codex, Claude, Cursor, and other clients without BotSpot native confirmation cards, return the exact authorizationUrl as a clickable Markdown link in your reply. Do not say a card or button was created unless the client actually rendered it. BotSpot clients may render structuredContent as a native confirmation, but a button name alone is not an approval link. A pending request is not execution; only the signed-in user may approve on the website. Report expiry and check get_deployment_action_status after approval.

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": {
      "deploymentId": "<deploymentId>"
    },
    "name": "run_deployment_once"
  }
}

Input Schema

NameRequiredDescriptionDefault
deploymentIdYes
idempotencyKeyNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations already flag destructive/openWorld/not-idempotent, and the description goes well beyond them: approval-by-owner, live trades, saved revision/broker/schedule preservation, overlap refusal, and the meaning of pending/launched/skipped/already_recorded/failed outcomes. It also clarifies that completion is unverified after launch and that balance reports are not evidence. The only shortfall is that this is delivered as an undifferentiated wall of prose rather than layered disclosure.

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

Conciseness2/5

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

It is front-loaded with the HIGH RISK warning and use cases, which is good, but the body is a long run-on block that repeats the same point several times ('pending approval means no strategy iteration has started', 'a pending request is not execution', 'balance or holdings report does not verify iteration completion' vs. the earlier non-prerequisite line). Multiple sentences restate rather than earn their place.

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 high-risk approval-gated mutation with no output schema, the description supplies result-state semantics, the follow-up tool (get_deployment_action_status), expiry handling, and client-specific authorizationUrl rendering guidance. The remaining gap is the unexplained idempotencyKey, which is the one piece of the two-parameter contract an agent could plausibly get wrong.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must carry parameter meaning. 'Use the exact saved deployment' gives partial context for deploymentId, but idempotencyKey is never mentioned at all, despite the description discussing duplicate dispatch and 'already_recorded' results — precisely where the key's semantics matter. The compensation for the coverage gap is therefore incomplete.

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 description states a specific verb and scope: 'request owner approval for one immediate iteration of an existing scheduled bot', and immediately names concrete use cases ('run once, an extra run, or retrying a missed iteration'). It explicitly distinguishes itself from siblings by naming stop/restart behaviors, update_deployment_revision, and start_deployment, so an agent can route correctly 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?

It gives explicit when-to-use triggers (run once, extra run, retrying a missed iteration) and explicit when-nots ('Does not stop, restart, replace or update the bot', 'Refuses overlapping runs'). Alternatives are named with the condition that selects them: an explicit restart uses update_deployment_revision, and the description forbids substituting start_deployment or update_deployment_revision.

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.