Skip to main content
Glama

BotSpot: AI Trading, Backtests and Bots

Run an existing scheduled bot once

run_deployment_once

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.

Input Schema

NameRequiredDescriptionDefault
deploymentIdYes
idempotencyKeyNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: HIGH RISK, can place live trades, preserves saved revision/broker/variables/schedule/history/state, refuses overlapping runs, preparation reads connection status and mode and refuses unless connected and matching. It enumerates every result state (pending approval, launched, skipped, already_recorded, failed/unconfirmed) and states that pending approval is not execution and launched means completion is unverified.

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 highest-value content (HIGH RISK, approval-not-execution, alternative tools) is front-loaded, which is good. But the prose is a dense, repetitive run-on: pending-approval-is-not-execution is restated in several places, and client-rendering caveats for Codex/Claude/Cursor consume substantial space that could be condensed into one sentence.

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?

A high-complexity, irreversible action with no annotations and no output schema, and the description covers safety profile, preconditions, result-state interpretation, how approval is granted, expiry, and the required follow-up tool (get_deployment_action_status). Only the parameter-level meaning is missing.

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% for two parameters, so the description must compensate, but it never names deploymentId or idempotencyKey. The phrases 'use the exact saved deployment' and 'an already_recorded result is a duplicate dispatch' hint at deployment binding and idempotency but never state that idempotencyKey is what prevents duplicate dispatch or what format deploymentId expects.

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?

States a specific verb and resource with scope: requests owner approval for one immediate iteration of an existing scheduled bot, and explicitly says it does not stop, restart, replace or update the bot. It names the sibling tools that handle the adjacent cases (update_deployment_revision, start_deployment), so an agent can separate it from them 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?

Gives explicit triggers (run once, an extra run, retrying a missed iteration), explicit exclusions (does not stop/restart/replace/update; refuses overlapping runs), and names the correct alternative for restart-and-run-immediately plus a fallback instruction if unavailable. It also warns against a specific misuse: do not request another reconnect from an old skipped run alone.

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.