Skip to main content
Glama

BotSpot: AI Trading, Backtests and Bots

Inspect action authorization or revoke trading permission

get_deployment_action_status
DestructiveIdempotent

Returns the status of a pending or completed deployment authorization request created by start_deployment, stop_deployment, update_deployment_revision, run_deployment_once, or place_trade. Includes the active, expired or revoked trading window when present. Omit operation or use status for reads. Use operation=revoke_trade_window with the source actionId to revoke further-trade authority; requires place_trade scope. Revocation is idempotent and prevents new claims, but does not cancel submitted or in-flight orders, stop bots or alter other accounts. Use this after the user approves or denies the website authorization URL. Copy the actual actionId returned by the action tool; never guess an authorization request id. A deploymentId, botId or revisionId is not an actionId. If no action request has been created or returned, prepare the requested action first. Do not poll a known unapproved request merely to confirm that approval is still pending. 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": {
      "actionId": "<actionId>"
    },
    "name": "get_deployment_action_status"
  }
}

Input Schema

NameRequiredDescriptionDefault
actionIdYes
operationNoOmit for status. revoke_trade_window revokes further trades authorized by this source action; requires place_trade scope and does not cancel submitted orders.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / operation
      Added value: +{
      +  "description": "Omit for status. revoke_trade_window revokes further trades authorized by this source action; requires place_trade scope and does not cancel submitted orders.",
      +  "enum": [
      +    "status",
      +    "revoke_trade_window"
      +  ],
      +  "type": "string"
      +}
  2. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already flag destructiveHint=true and idempotentHint=true, but the description adds real behavioral context beyond them: revocation is idempotent, prevents new claims, does not cancel submitted or in-flight orders, does not stop bots or touch other accounts, and requires place_trade scope. It also discloses the meaning of each executionResult status (launched, skipped, already_recorded, failed/unconfirmed) and warns that a balance or holdings report does not verify iteration completion — none of which is in structured fields.

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?

The core is front-loaded, but the block runs far past what a tool description needs, mixing tool semantics with client-specific reply formatting ('For Codex, Claude, Cursor... return the exact authorizationUrl as a clickable Markdown link') and with advice about how to phrase answers to the user ('Do not lead with Yes and then qualify it'). Several cautions are restated two or three times (pending is not execution, approval is unverified), so length is not compensated by density.

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 two-operation tool with no output schema and an ambiguous result space, the description covers the semantics an agent needs: what each executionResult value implies, that a pending status means no iteration started, and that revocation does not cancel in-flight orders. It does not describe the overall response shape beyond the metadata.executionResult.status field, which is the remaining gap given there is no output schema.

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

Parameters3/5

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

Schema coverage is 50% and the enum description already documents that operation controls status vs. revocation. The description's one genuine addition is the actionId caveat — it must be the real id returned by the action tool, and a deploymentId/botId/revisionId is not an actionId — but the revoke scope note largely restates the schema's enum text. Useful, though not a rich expansion of both parameters.

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 gives a specific verb and resource — returns status of a deployment authorization request created by named sibling tools (start_deployment, stop_deployment, place_trade, etc.) — and the second capability (operation=revoke_trade_window revokes trading authority) is named explicitly. An agent can distinguish this from get_single_trade_status or list_deployment_runs 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 says when to use it (after the user approves or denies the URL, or to revoke trade authority), when not to (do not poll a known unapproved request, do not use a deploymentId/botId/revisionId as actionId, prepare the request first if none exists), and how to choose between the two operations ('Omit operation or use status for reads'). Exclusions and alternatives are explicit rather than implied.

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.